Отказоустойчивый двухузловой кластер

[donvictorio]

как при таком типичном кластере при выходе из строя мастера, на время переключения одного из слейвов на мастер не потерять транзакции и не получить отказ в обслуживании? в двух словах

Спойлер

 

[vgrey]

При таком - никак. Но что Вам мешает сделать кольцо на основе репликации?

Спойлер

Тогда при выходе со строя любого из серверов, достаточно будет замкнуть цепочку репликации.

 

[donvictorio]

тоесть можно сделать так, чтобы слейв одновременно был мастером для другого слейва? я об этом не знал.
я так понимаю, нужно все сервера поднимать как слейвы до момента окончания формировки кольца?
есть где внятная информация для курения?

 

[vgrey]

тоесть можно сделать так, чтобы слейв одновременно был мастером для другого слейва? я об этом не знал.
я так понимаю, нужно все сервера поднимать как слейвы до момента окончания формировки кольца?

Думаю, поднимать все сервера как слейвы до момента окончания формирования кольца, надобности нет, все много проще.

есть где внятная информация для курения?

Очень рекомендую книгу Бэрон Шварц, Петр Зайцев и др. "MySQL Оптимизация производительности. Второе издание". Там целый раздел о репликации, подробно о достоинствах и проблемах, много схем и т.п.

 

[aladar]

Мне ездить без ручного вмешательства в конфиги с автоскалированием нод при повышении нагрузки в облаке.
Сейчас используем мультимастеринг на базе Percona, но везде надо контролировать руками. Поэтому и ищем выход.