кластер mysql+pacemaker+corosync

подскажите в какую сторону копать

В сторону postgres.
Хотя в mysql есть логи транзакций, там давно можно сделать кластер/репликацию, но я бы не стал. Если действительно сильно надо гугли mysql replication

mysql replication

Благодарю. То, что надо, называлось «master-master replication».

Мастер-мастер это обычно очень больно и с массой спецэффектов. Ты на 146% уверен что оно тебе надо? Может проще master-slave и плавающий адрес? У тебя же и так судя по тексту active-passive

А ты прямо бессмертный, чтобы с такими вещами связываться…

Может я чего-то не понимаю, но мне требовалось, чтобы на какой бы машине не происходила запись в SQL, оно бы сразу же дублировалось на вторую. Чтобы обе базы были по возможности всегда идентичны «искаропки» без разделяемых сторейджей, синхронизации по крону и подобных «костылей для костылей».

Попробовал, FreePBX с моим мастер-мастер так и работает, в одном месте создал экстеншен - он сразу появился на втором. Плавающий IP переезжает там только для доступа к «активной» станции извне, внутри у обеих всё поддерживается идентичным по статическим ip.

Альтернатива, я так понимаю, это оно начинает перевозить данные на слейв когда уже что-то грохнулось. Как это предлагается делать, когда между тачками тупо легла сеть (провод выдернули, свитч сгорел) - я искренне не понимаю.

оно бы сразу же дублировалось на вторую

«Сразу же» понятие относительное, по крайней мере в этой физической вселенной. Потому «оно начинает перевозить данные на слейв когда уже что-то грохнулось» - вполне обычная ситуация

Основная разница - на какую из баз ты пишешь. Если на одну - проще мастер-слейв, в разы меньше граблей. Если в обе - ну, тут да, но я б дважды подумал надо ли оно такое

Если в обе - ну, тут да, но я б дважды подумал надо ли оно такое

Если в обе, то двухфазный комит спасет отца русской демократии.

Да по факту вариантов когда вот прям кровь из носу надо писать в две базы крайне мало. Тем более в реальном времени. Между цодами ещё можно понять, но там всегда асинхронно. А так чтоб соседние серваки - ну хз

Как это будет работать, если нет какой-то третьей машины со сторейджем. Строго две ноды и между нодами упала сеть.

Я так вижу, чтобы вторая нода могла «продолжить с того же места», на ней уже к моменту падения должна быть всегда идентичная первой база. А если на второй успеют записать в базу, когда первая подымется обратно руками/костылями синкать? Я понимаю, мастер-мастер страшно звучит, но как тут другим способом выкрутиться, чтобы ещё и костылей не больше было?

В теории да, но в теории у нас и базы все имеют 100500-ю нормальную форму :) На практике запись в несколько баз совсем не редкость, когда у вас чуть больше чем одна ИС крутиться это нормальное явление.

Я имею ввиду мастер-мастер репликацию. Несколько баз - да, сплошь и рядом, но так чтоб прямо было нужно писать в две реплики одной и той же базы - такое редко бывает

Погоди. Если у тебя всего две ноды, то про любой кластер в целом можно забыть, иначе будет сплит и будет прям очень больно. Мастер-мастер модель только усугубит последствия, между прочим. Если нет денег на полноценную третью ноду - можно поставить миниатюрный tiebreaker без данных, но нод в кластере при нормальной работе должно быть минимум 3.

По поводу идентичности и прочего - ты сейчас почти дословно описал мастер-слейв, с поправкой на потерю незакоммиченных данных, но от этого никуда не деться. Если данные начинают идти только когда одна нода сдохла - проблемы с конфигом, но не с режимом репликации. При нормальной работе каждая реплика держит полную копию того шарда, на который она смотрит. Суть мастер-мастер режима - возможность одновременно писать на обе реплики, оно не связано с failover при падении сети.

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

Ну и мастер-мастер репликация (я только про определение мастер-мастер, а не конкретную реализацию) так же очень не редки. Вполне нормальное явление когда у вас много отдельно расположенных объектов.

Всё-таки, как «прямо» решать проблему с потерей того, что успели записать в реплику? Ну допустим там магазин какой-то, надо хранить заявки клиентов и подобное, независимо от того, какая нода фактически сейчас работает. Я могу понять такой подход, если ресурс по сути read-only.

В реплику нельзя писать, в этом вся суть. Максимум читать.

Я тут порыл маны по пцмк - слушай, а можешь плз описать всю систему как ты её видишь? А то там в манах drbd в 2022 году, да ещё и на «кластере» из двух нод. Это прям рецепт боли и унижений. При том ушедший в сплит дрбд ты даже реанимировать не сможешь, только с бэкапа.

По идее это обычно делается (в 2022 году) на 3 нодах со своими хардами, из которых одна мастер rw, а остальные реплики ro. На мастер смотрит виртуальный адрес, который в случае жопы перекидывается на нового мастера, которого выбрал кворум. Судя по манам мускуля он это в последних версиях умеет, нужно курить disaster recovery и automatic failover

Вот, принёс на почитать. В целом все вплоть до DR Site вполне применимо в твоём случае

https://www.percona.com/blog/2021/04/14/percona-distribution-for-mysql-high-availability-with-group-replication-solution/

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

Вопрос от того что репликации в мускуле весьма шлачная в плане DR, а пцмк это как бы легаси (тут можно спорить, но это далеко не самое простое решение в любом случае).

Если нужно с нуля, просто и быстро - берёшь кубы, хелм и чарт от перконы, ставится за два часа из которых полтора ты раздупляешь что есть PV/PVC. auto-DR идёт в комплекте. Сразу решит проблемы и с плавающим адресом, и с DR, и с масштабированием. Плюс пачка тулов типа online schema change

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

Задача сделать две ноды freepbx абсолютно заменяемые с использованием pacemaker именно. Причём трюк с мастер-мастер неожиданно заработал сразу, ну только потом на «ожившей» ноде не забывать генерить из SQL актуальные конфиги астера и применять их - это как раз я быстро и просто сделал. Сейчас упёрся в сам pacemaker. Ответ на вопрос я нашёл, но он блин на платной поддержке редхата лежит и разумеется просто так сам ответ не показывается :(

Делал такое в 2013 кажется году. А что, фри научился asterisk rt делать? Или ты хочешь конфиг синкать? Потому что там одним конфигом сыт не будешь. В такой связке емнип мускул это прям последняя из возможных проблем

Чтоб оно реально работало в active-active нужен rt для настроек (что значит минус фри, он rt не умеет) и сип-свитч типа kamailio чтоб отрабатывать регистрацию, иначе каждая станция будет думать что номер на ней и между станциями звонить будет больно. Плюс будут тупить очереди и ринг-группы, по факту все это придётся нести на гейт.

Если тебе нужен active-passive, а не active-active - я б лучше взял два образа фс с файлами астера и мускуля и монтировал бы их к активной ноде, на пцмк можно взять drbd, если монтировать только к одной ноде то в целом должно жить. Ну либо глистер какой. Все равно риск есть, но кмк это прям в разы проще чем м-м на мускуле. Сейчас использую почти такую же схему на freeswitch, только с ceph rbd и докером

Ну, клиентам перерегаться придётся, это да. Пока упёрся только в звук, для которого и надо floating src. Сам floating ip переходит, клиенты регаются заново на другой ноде, вызов совершить можно, конфиг синкается в обе стороны.

Если таки active-passive и переподключение ок - точно нет желания просто влепить глистер на /etc/asterisk и /var/lib/mysql и монтировать его на активную ноду? Отдать команду mount через пцмк не сложно, запустить процессы тоже. Будет небольшой даунтайм в пределах старта базы, но это меньше минуты.

Хотя хз конечно, глист напару с мускулем могут фс побить при резком падении, хз. Но просто любая система со словами master-master в названии это всегда бдсм.