Mysql мастер - мастер репликация.

Там как таковой мастер-мастер нет, насколько я помню делается 2 раза мастер-слейв + опции auto_increment_increment, auto_increment_offset либо ndb cluster.

Лучше забудь об этом.

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

Лучше забудь об этом.

+1

Лучше забудь об этом.

Тогда придумай, как мне синхать между собой две mysql базы, ок :)

Придумал: надо переделать приложение :). Серьёзно, ты идёшь по пути страшных костылей. Тем более если приложение не адаптировано к асинхронной мастер-мастер репликации и не знает что могут быть, например, коллизии.

обычно делается так:

автоинкременты задаются на одной базе нечетные, на другой - четные и шаг 2
и далее настраивается репликация

но вообще, мастер-мастер - штука опасная в случае MySQL

а зачем тебе писать сразу в 2 базы? сделай Master-Slave, читай из одной без локов, пиши в другую. Обычно mysql совсем не такая медленная, как принято считать и вполне успешно справляется с довольно высокими нагрузками.

Ну и само собой, MySQL замени на Percona

http://support.atmail.com/display/A7DOCS/Repairing MySQL replication
http://support.atmail.com/pages/viewpage.action?pageId=3539463

Чувачки аппы предлагают это делать вот таким образом.

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

Меня не нагрузка волнует, она пустяковая будет. Меня волнует в первую очередь failover.

Так репликация же для масштабирования а не для failover. Для этого есть pacemaker'ы всякие.

Для этого есть pacemaker'ы всякие.

Он рулит только инстансами, а данные то как синхать между базами при этом? :)

Более того насколько я понимаю для failover репликация должна быть как минимум синхронной, иначе потери данных неизбежны. Mysql не поддерживает синхронную репликацию. Видел еще есть Galera Cluster for MySQL более подходящее решение должно быть для failover.

Делается мастер-слейв при наступлении файловера pacemaker переводит слейв в режим мастера.

Делается мастер-слейв при наступлении файловера pacemaker переводит слейв в режим мастера.

О, это то что нужно походу.
Спасибо.

http://www.rackspace.com/knowledge_center/article/mysql-master-master-replica...
http://initialize.ru/mysql-master-master-replikaciya
http://www.itnotes.org.ua/administration/mysql/master_master_replication_db.html

Ну и само собой, MySQL замени на Percona

Зайцев, перелогинься

кинь каку, говорю тебе как человек, который с атмейлом сношался три года

кинь каку, говорю тебе как человек, который с атмейлом сношался три года

Подскажи аналог? :)
И в чем какость тоже расскажи, пожалуйста, а то я серьезно его рассматриваю.

в 5.6 запилили GTID, с ними master-master должна стать более вменяемой

Меня волнует в первую очередь failover.

требуется одно, а спрашивают совсем другое :)

аналог для каких задач? какость... ну при 70к юзерах оно нещадно тормозило рандомом и временами теряло почту

ну при 70к юзерах оно нещадно тормозило

У меня их ~250. Что именно тормозило?

временами теряло почту

Как это выглядело? Ты дебажил скрипты?

аналог для каких задач?

Драсте, почти для всех, что они предлагают :)
Почтовичок с внятной админкой, вебмордой и апи, поддержка календариков на ифоны из коробки и тд.

У меня их ~250.

к? или просто 250? тогда ок

Что именно тормозило?

все ) бэкенд, например, любил жрать cpu

Как это выглядело?

в логах delivery successful, в веб-морде пустота

Ты дебажил скрипты?

вестимо, нет )

Почтовичок с внятной админкой, вебмордой и апи, поддержка календариков на ифоны из коробки и тд.

зимбра? Впрочем, ты делай скидку на то, что мой опыт устарел на 6 лет - за это время многое могло измениться

просто 250

Да.

все ) бэкенд, например, любил жрать cpu

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

в логах delivery successful, в веб-морде пустота

Хм, посмотрим, что скажет тестирование. Хотя за 6 лет многое поменялось, лол. Да и их саппорт никто не отменял.

вестимо, нет )

Зря :) При такой нагрузке как у тебя надо было.

зимбра?

Не нравится ява :(
Я не смогу в случае чего сделать быстрофикс, например. Плюс даже установка зимбры на deb вызывает у меня приступы ужаса, куча непонятных сервисов, которые делают непонятно что.
Плюс зимбра точно части фич не умеет, не скажу навскидку каких правда.

А там бинари их собственные какие-то были?

там был какой-то нечитаемый трэш на перле

Удачи, расскажешь потом, как оно нынче

https://kb.askmonty.org/en/what-is-mariadb-galera-cluster/
hidden_4003, true_admin, a_andry.
А про эту радость что скажете, господа?

Удачи, расскажешь потом, как оно нынче

Если не забуду :) Спасибо.

Лучше не надо. Тред не читал.

Лучше не надо. Тред не читал.

Прочитай. Тут интересно.

Не пробовал, но раз она синхронная то почему бы и нет.

Я ещё баловался с каким-то mysql proxy с lua внутри. Оно тоже держало мастер-мастер репликацию (путём отправки апдейтов на оба хоста сразу). Но оно было настолько глюкаво что даже близко не работало.

Но, в общем, мне как-то это кажется в теории более надёжным чем самопальные галеры со своим протоколом. А так пока не попробуешь - не узнаешь. И самое сложное это не настроить всё, а протестировать и понаступать на все грабли заранее. Чтобы потом локти не кусать.

В каждом решении претендующем на true multimaster всегда пишут о уникальной технологии, бесконечной масштабируемости и надежности. Но почему то старательно ухотят от вопросов блокировок и обеспечения целостности данных. Galera -не исключение. На деле _надежный_ мультимастер реализуется только на уровне приложения. Все остальное не может гарантировать вам что однажды вы не получите два сервера с кашей вместо данных. Мультимастер - это не только запись данных на несколько серверов сразу, а и охват блокировками данных на обоих серверах сразу.

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

Синхронная то она синхронная только она же не избавляет от логических конфликтов. Т.е. было у нас например 5 пончиков, оно рассыпалось, на мастер А взяли 2 и на мастер Б взяли 4, связь появилась и... лучше бы она не появлялась. Избежать этого можно но задача уже нетривиальная.

При обрыве связи прокси больше не будет работать с отвалившейся базой. Он пометит её как «требующую ручного вмешательства». Вопрос что будет если в сети два независимых прокси...

Да, что-то я не подумал и проигнорировал слово кластер в названии. Тогда вопрос снят.

Galera foremost goal is data consistency across the nodes and it simply won't allow any modifications to the database if it may compromise consistency.

Т.е. при потере кворума все превращается в тыкву readonly.

вот именно, в тыкву. Наверно это не то что хочет получить ТС :).

ээ, с оговоркой, что я не спец по мускулю, но наблюдал массу стараний наших мускулистов обеспечить хот-фейловер: оно не работает, в общем случае. самое надежное, походу, - NDB. только вот он тоже при каких-то там условиях рассыпался. пробовали все перечисленные здесь варианты. в сыром остатке: все важное только на оракле, репликация стореджом, если надо - RAC. а все остальное - мастер-слейв с фейловером сторонними программами и выводом бывшего мастера из схемы репликации до ручного вмешательства (как правило сводящегося к восстановлению из свежей копии с нового мастера и перезапуске репликации в обратную сторону). по желанию можно добавить больше слейвов. короче говоря, кака.