Pull to refresh

Comments 27

А где указания файла бинлога и позиции в нем?
В том то и прикол, что в 5.6 с появлением GTID это не нужно…
Примерно так. В пером случае gtid репликация не используется
А я уж подумал мастер-мастер репликация, а тут мастер-слейв…
GTID позволяет не просто мастер-мастер репликацию, а мастер-мастер репликацию с произвольной топологией. Правда, сам я настраивал такое только в MariaDB 10, там синтаксис немного отличается.

Жду теперь релиза MariaDB 10.1, там возможен мультидоменный GTID, это позволит простым способом один хост использовать в нескольких кластерах.
Увы, пока такой возможности нет ((
А что Вы имели в виду под репликацией с произвольной топологией?
Произвольная топология — это когда сервера соединяются не в кольцо (как было раньше: А —> Б —> В —> Г —> А) и не звездой вокруг выделенного сервера ( А <—> Б; А <—> В; А <—> Г), а в произвольном порядке. Например, А <—> Б <—> В <—> Г; Б <—> Д; В <—> Е. И изменения на любом из серверов разойдутся по всему кластеру.
Но это должна быть очень грамотно придуманная база, иначе при рассинхронизации схемы проще всего будет застрелиться )
Ну, чтобы избежать конфликтов ID, можно использовать UUID или auto_increment_increment/auto_increment_offset.

А при сбоях при копировании данных можно воспользоваться pt-table-sync.

В общем, задача не такая страшная :)



Для меня куда сложнее вопрос файловой синхронизации. Кластерные ФС отвратительно работают на разнесённых датацентрах. Приходится пользоваться lsyncd.
Как матёрый некропостер спрошу — я правильно понимаю, что если настроить mariadb таким образом:
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) тоже можно применять, но с ней легко запутаться. А так все проще: на каждом из серверов пишем в свой мастер, читаем доп. изменения из своего слейва.

Или таки третий сервер и галеру :)
да, уже пришёл к тем же выводам.
Галера — это все таки синхронная репликация и нормально работает только в быстрых сетях, иначе начинаются дикие тормоза. Описанная Вами схема работает, я ее использовал довольно много раз. Но нужно хорошо понимать, что делаешь и кто какие запросы шлет
Это вообще решается в рамках My? Как там с фрагментацией (по колонкам и столбцам), есть ли фильтрация как в MS?
Вот-вот. Мастер-мастер интереснее. И мультимастер.
Для мастер-мастер репликации могу посоветовать посмотреть в сторону Galera, легко настраивается, хорошо работает.
Лично я очень доволен этим решением.
Это конечно крутое изменение, что не нужно указывать позиций.
Но я бы не сказал бы что их указывать было так тяжело.

Приятная мелочь, конечно.
Еще куча приятных мелочей появилась при отслеживании и лечении поломок
Например восстановление после сбоев. Манипулируем не абстрактным position, а вполне реальной и понятной транзакцией. Еще есть percona toolkit, в котором что то про это было интересное, но я ее рассматривал довольно обзорно
Погодите, я отстал от жизни. А как же момент заливки дампа на слейв? Раньше кошмар заключался в том что надо было стопарить мастер как минимум на время снятия дампа для слейва, запоминать позицию, заливать дамп на слейв и говорить с какой позиции лога стартовать. Ну ладно, теперь можно позицию не запоминать, но что это меняет?
Если используем что-то типа xtrabackup, мастер останавливать не надо. Innobackupex сам его остановит в нужный момент для финализации изменений и копирования MyISAM-таблиц. Если MyISAM данных много, время простоя будет ощутимым.
если мы начинаем с чистой базы, то слейв вольется сам. А позицию запоминать не нужно, она будет сохранена в дампе
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention