Вопрос про репликацию Mysql

mariadb galera cluster

А зачем тут вообще репликация? Ресурсов не хватает, переезжаешь на сервер по мощнее, всё. Откуда вылезла репликация.

Потому что узкое место - mysql . И хотелось бы не переезжать куда либо ,а просто добавлять ресурсы под то чего нехватает . Масштабируемость так называемая..

Ресурсов не хватает, переезжаешь на сервер по мощнее, всё.

суть™ современных пхп (да и не только) макак

Окей , это мастер-мастер репликация . А что касается - 2,3 пунктов ?

Учитывая что решение об аренде выделенного сервера уже принято, пункты «оптимизировать код» и тому подобные можно пропустить.

Хорошо-бы сразу упомянуть что оно сильно замедляет запись в базу.

Ну ОК, вынеси MySQL на новый сервер. Зачем без нужды усложнять схему добавляя репликацию? Особенно учитывая что, судя по вопросам, опыта в этом деле у тебя мало.

Более того: если сервер значительно производительнее VPS (как оно обычно и бывает) то я не вижу причин оставлять в схеме VPS.
Чем проще тем лучше.

Ну давай теперь скажи, каким макаром «и тому подобные» ты будешь синхрить одно приложение на разных хостах.

Вы не поняли, мне нужно не вынести , а разделить нагрузку между серверами . А я спрашиваю как лучше .Если я просто вынесу mysql на другой сервер , то на старом сервере останутся не задействованные ресурсы . Читайте внимательно .

Мы похоже о разных вещах говорим.
Я вообще предлагаю не разъезжаться без нужды на несколько хостов.
А под «и тому подобные» я подразумевал в основном оптимизацию мускуля.

Если текущий сервер сильно слабее нового то я вообще не вижу смысл сохранять текущий. Выгоды от использования его ресурсов не покроют проблемы которые создаст распределённая система. А если VPS совсем слабы то возможно даже не покроет издержек на репликацию.

Сервера одинаковые .

Кароч я бы вот что запилил. Вынес бы мускуль на новый сервак. Приложение оставил на старом. Ну или наоборот в зависимости от мощности старого-нового. Так вот. В приложении, для расширяемости на будущее должна быть такая шляпа, что, если в конфиге БД указан только один коннект, то вне зависимости от запрашиваемого (мастер или слейв) к использованию возвращаться должен этот единственный коннект. По мере роста нагрузки на мускуль докупишь еще сервак, повесишь туда слейв-реплику, оставишь тот старый мастером. Теперь в конфиге приложения будет два коннекта, и возвращаться будет запрошенный мастер или слейв. Когда слейвов будет больше одного — пусть приложение например с round-robin выбирает какой слейв тебе подать. Кароч я бы нацелился на схему «один мастер + слейвы» — этого должно хватить.

1 Какой тип репликации лучше всего использовать при условии что большая часть запросы - SELECT.

Самый обычный master-slave.

2 Если использовать любой из типов репликации , то имеет ли смысл по дробить физический сервер на 3 виртуалки с 3 master/slave репликами . Или же цельный сервер в этом случае лучше?

Почему на 3, а не на 2 или 7?

3. В моем случае при схеме master-slave ,лучше master выносить из первого сервера ( где все в одном ) в отдельную виртуалку? Или оставить mysql-master рядом с php-fpm ?

Вынести базу полностью на физический сервер без всяких виртуалок и репликаций.

При этом один виртуальный, а другой физический?

я примерно к такой схеме и клонил , просто сервера по ресурсам примерно одинаковые . В данный момент все приложение с mysql работает на одной виртуалке , под которую выделена львиная доля ресурсов сервера . Поэтому и спрашиваю . Допустим под приложение php + nginx выделить виртуалку с 10 % ресурсов, а под mysql мастер - 80% , а под слейв - один цельный физический сервера ? Или лучше наоборот , под мастер - целый сервер , а слейв на виртуалку ?

ну под виртуалку выделено сейчас 90 % ресурсов

Почему на 3, а не на 2 или 7?

спрашивая , я надеюсь на ответ .

Вынести базу полностью на физический сервер без всяких виртуалок и репликаций.

куда девать оставшиеся ресурсы на первом сервере

Да ну. Если в локалке по гигабитному каналу, то и не очень сильно.

glusterfs?

Пых и нгинкс сами по себе не особо много потребляют. Мускул перед разделением надо до края оптимизировать (например, ssd поставить под базу, на оракле у нас один отчёт стал с 40 минут делаться 40 секунд благодаря этому). Если же в основном select, наверное, проще master-slave, но всё тоже зависит от целей, которые ты перед собой ставишь. Ну и завсит ещё от того какая доступность сервиса должна быть. То бишь просчитать случаи падения серверов. Физический сервер под 3 виртуалки имеет смысл дробить только если для каждой виртуалки под базу будет отдельный физический диск. Иначе у тебя всё в диск упрётся. Посмотри свои текущие Disk Utilization в мунине.

У галеры в подобном варианте запись просаживается раза в два.

Это на сколько серверов кластер?

На сколько я помню — три, но может быть и два.

Три - это минимальное количество серверов в галера кластере. Ну и далее 5, 7, чтобы кворум был. А просадка инсертов в два раза при скольки серверах наблюдается?

При двух вроде тоже стартует и работает. Но таки да, нужен кворум, поэтому я рассматриваю три как ноды как минимальный вариант. Но в том случае я мог немного забить на консистентность и обойтись двумя нодами.
Больше трёх я не делал. Так-что либо три либо две, скорее три.

Нужно учитывать что дело было давно и не правда так что точных цифра ждать не стоит.

Ясно. ОК. При двух оно работает до выпадания одного из серверов из сети. Тогда они сплитятся и друг друга признавать не хотят. :)