Comments 27
А где указания файла бинлога и позиции в нем?
В том то и прикол, что в 5.6 с появлением GTID это не нужно…
Если я правильно понял выдержку из документации, то либо мы указываем MASTER_LOG_FILE и MASTER_LOG_POS, либо MASTER_AUTO_POSITION
А я уж подумал мастер-мастер репликация, а тут мастер-слейв…
GTID позволяет не просто мастер-мастер репликацию, а мастер-мастер репликацию с произвольной топологией. Правда, сам я настраивал такое только в MariaDB 10, там синтаксис немного отличается.
Жду теперь релиза MariaDB 10.1, там возможен мультидоменный GTID, это позволит простым способом один хост использовать в нескольких кластерах.
Жду теперь релиза MariaDB 10.1, там возможен мультидоменный GTID, это позволит простым способом один хост использовать в нескольких кластерах.
Увы, пока такой возможности нет ((
А что Вы имели в виду под репликацией с произвольной топологией?
А что Вы имели в виду под репликацией с произвольной топологией?
Произвольная топология — это когда сервера соединяются не в кольцо (как было раньше: А —> Б —> В —> Г —> А) и не звездой вокруг выделенного сервера ( А <—> Б; А <—> В; А <—> Г), а в произвольном порядке. Например, А <—> Б <—> В <—> Г; Б <—> Д; В <—> Е. И изменения на любом из серверов разойдутся по всему кластеру.
Но это должна быть очень грамотно придуманная база, иначе при рассинхронизации схемы проще всего будет застрелиться )
Ну, чтобы избежать конфликтов ID, можно использовать UUID или auto_increment_increment/auto_increment_offset.
А при сбоях при копировании данных можно воспользоваться pt-table-sync.
В общем, задача не такая страшная :)
…
Для меня куда сложнее вопрос файловой синхронизации. Кластерные ФС отвратительно работают на разнесённых датацентрах. Приходится пользоваться lsyncd.
А при сбоях при копировании данных можно воспользоваться pt-table-sync.
В общем, задача не такая страшная :)
…
Для меня куда сложнее вопрос файловой синхронизации. Кластерные ФС отвратительно работают на разнесённых датацентрах. Приходится пользоваться lsyncd.
Как матёрый некропостер спрошу — я правильно понимаю, что если настроить mariadb таким образом:
server1 (master) → server2 (slave)
а затем
server2 (master) → server1 (slave)
то при использовании auto_increment_increment/auto_increment_offset и gtid, цивилизация не рухнет и у нас будет master-master replication?
или не пытаться строить велосипед и смотреть в сторону галеры?
server1 (master) → server2 (slave)
а затем
server2 (master) → server1 (slave)
то при использовании auto_increment_increment/auto_increment_offset и gtid, цивилизация не рухнет и у нас будет master-master replication?
или не пытаться строить велосипед и смотреть в сторону галеры?
Как матерый некрофил отвечу:
Получите впечатлений и проблем. Массу.
Дело в том что цивилизация будет жить ровно до прилета первой птицы. Которая ее и разрушит. Это крайне шаткая конструкция, особенно когда вы получите свой первый split brain.
Но и в сторону галеры с двумя серверами лучше не смотреть.
Если у вас только 2 сервера и ни каплей больше, рассмотрите вариант чтобы поднять по два сервера баз данных на одном сервере (через вирт.машины или напрямую на нем — второе посложнее будет т.к. будут нужны разные конфиги и разные systemd юниты для свежих систем) и уже с ними делайте master->slave так:
server1 db1 (master) -> server2 db2 (slave)
server2 db1 (master) -> server1 db2 (slave)
Т.е. на каждом сервере db1 это мастер, а db2 это слейв (чтобы не путаться), и они на противоположные db2 синхронизируются.
Схему где server1 db1 (master) -> server2 db1 (slave) и server2 db2 (master) -> server1 db2 (slave) тоже можно применять, но с ней легко запутаться. А так все проще: на каждом из серверов пишем в свой мастер, читаем доп. изменения из своего слейва.
Или таки третий сервер и галеру :)
Получите впечатлений и проблем. Массу.
Дело в том что цивилизация будет жить ровно до прилета первой птицы. Которая ее и разрушит. Это крайне шаткая конструкция, особенно когда вы получите свой первый split brain.
Но и в сторону галеры с двумя серверами лучше не смотреть.
Если у вас только 2 сервера и ни каплей больше, рассмотрите вариант чтобы поднять по два сервера баз данных на одном сервере (через вирт.машины или напрямую на нем — второе посложнее будет т.к. будут нужны разные конфиги и разные systemd юниты для свежих систем) и уже с ними делайте master->slave так:
server1 db1 (master) -> server2 db2 (slave)
server2 db1 (master) -> server1 db2 (slave)
Т.е. на каждом сервере db1 это мастер, а db2 это слейв (чтобы не путаться), и они на противоположные db2 синхронизируются.
Схему где server1 db1 (master) -> server2 db1 (slave) и server2 db2 (master) -> server1 db2 (slave) тоже можно применять, но с ней легко запутаться. А так все проще: на каждом из серверов пишем в свой мастер, читаем доп. изменения из своего слейва.
Или таки третий сервер и галеру :)
Галера — это все таки синхронная репликация и нормально работает только в быстрых сетях, иначе начинаются дикие тормоза. Описанная Вами схема работает, я ее использовал довольно много раз. Но нужно хорошо понимать, что делаешь и кто какие запросы шлет
Это вообще решается в рамках My? Как там с фрагментацией (по колонкам и столбцам), есть ли фильтрация как в MS?
Вот-вот. Мастер-мастер интереснее. И мультимастер.
GTID для этого и придумали, посмотрите доклад Осипова Константина на failoverconf
видео www.youtube.com/watch?v=v68l2YOur5M
pdf failoverconf.ru/upload/iblock/dc5/05_Osipov.pdf
видео www.youtube.com/watch?v=v68l2YOur5M
pdf failoverconf.ru/upload/iblock/dc5/05_Osipov.pdf
Для мастер-мастер репликации могу посоветовать посмотреть в сторону Galera, легко настраивается, хорошо работает.
Лично я очень доволен этим решением.
Лично я очень доволен этим решением.
del
Будет ли обзор Mariadb vs Postgresql? По следам данной статьи
Это конечно крутое изменение, что не нужно указывать позиций.
Но я бы не сказал бы что их указывать было так тяжело.
Приятная мелочь, конечно.
Но я бы не сказал бы что их указывать было так тяжело.
Приятная мелочь, конечно.
Погодите, я отстал от жизни. А как же момент заливки дампа на слейв? Раньше кошмар заключался в том что надо было стопарить мастер как минимум на время снятия дампа для слейва, запоминать позицию, заливать дамп на слейв и говорить с какой позиции лога стартовать. Ну ладно, теперь можно позицию не запоминать, но что это меняет?
Sign up to leave a comment.
Настройка репликации в Mysql 5.6