LINUX.ORG.RU

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

hidden_4003 ()

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

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

true_admin ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

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

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

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

BaBL ★★★★★ ()
Последнее исправление: BaBL (всего исправлений: 1)
Ответ на: комментарий от BaBL

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

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

hidden_4003 ()
Ответ на: комментарий от hidden_4003

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от hidden_4003

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

hidden_4003 ()
Ответ на: комментарий от tazhate

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

hidden_4003 ()
Ответ на: комментарий от hidden_4003

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от BaBL

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

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

leave ★★★★★ ()
Ответ на: комментарий от tazhate

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

leave ★★★★★ ()
Ответ на: комментарий от leave

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от BaBL

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

a_andry ()
Ответ на: комментарий от tazhate

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

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

true_admin ★★★★★ ()
Ответ на: комментарий от tazhate

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

leave ★★★★★ ()
Ответ на: комментарий от leave

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

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

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

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

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

У меня их ~250.

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

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

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

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

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

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

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

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

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

leave ★★★★★ ()
Ответ на: комментарий от leave

просто 250

Да.

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

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

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

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

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

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

зимбра?

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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

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

leave ★★★★★ ()
Ответ на: комментарий от leave

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

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

tazhate ★★★★★ ()

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

kostian ★★★★☆ ()
Ответ на: комментарий от kostian

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

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

tazhate ★★★★★ ()
Ответ на: комментарий от tazhate

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

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

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

true_admin ★★★★★ ()

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

ventilator ★★★ ()
Ответ на: комментарий от tazhate

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

hidden_4003 ()
Ответ на: комментарий от true_admin

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

hidden_4003 ()
Ответ на: комментарий от hidden_4003

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

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

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

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.

hidden_4003 ()
Ответ на: комментарий от hidden_4003

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

true_admin ★★★★★ ()

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

val-amart ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.