MariaDB multi-source replication

http://blog.mariadb.org/tag/mariadb-10/

Available since 10.0.0

• Multi-source replication (MDEV-253)
  • Multi-source replication is a longtime wish of many users. In scenarios where you partition your data over many masters you can then replicate the data from all masters onto one slave. Typical use cases are:
    • Data partitioned over many masters can be pulled together onto one slave for analytical queries
    • Many masters can replicate to the same slave and a complete backup can be done on the slave
    • Newer hardware usually provides more performance. Usually all hardware isn’t upgraded at once and multi-source can be used for replicating many masters to a powerful new slave.
  • Original code from Taobao

Более подробное описание
https://mariadb.atlassian.net/browse/MDEV-253

Each master is handled by a specific replicator instance in the slave server. Each replicator instance consists of separate I/O thread, SQL thread, and associated state and configuration. In efffect, several replication slaves are running at the same time, each replicating from a separate master, but all replicating into a common data store (typically, but not necessarily to separate databases/tables).
A replicator instance is identified with a user-chosen name used in replication SQL statements such as CHANGE MASTER TO ... This name is also included in file names to distinguish the files that keep the replication state (relay logs, master.info, relay-log.info). This way, each separate instance can be configured separately, but otherwise the same way as existing single-source replication.

синтаксис
https://mariadb.com/kb/en/multi-source-replication/

MySQL+SSL репликация

Репликация у MySQL изначально без шифрования, что снижает нагрузку на систему, но при разнесении базы на несколько площадок возникает вопрос безопасной репликации. Это можно делать как через сторонние тоннели, так и штатными методами через SSL. Будем делать штатными методами.

MySQL Master-Master

Основная дока этой заметки:
Опыт эксплуатации MySQL Master-Master — как пережить аварию датацентра

Плюс о репликации у меня есть
http://dragonflybsd.blogspot.ru/search/label/mysql

mysql и репликация: Multi-Master Replication Manager for MySQL

MMM (Multi-Master Replication Manager for MySQL) is a set of flexible scripts to perform monitoring/failover and management of MySQL master-master replication configurations (with only one node writable at any time).
То есть это master-master в режиме active-passive.

Основной сайт
http://mysql-mmm.org/
Но там есть такое:
NOTE: By now there are a some good alternatives to MySQL-MMM. Maybe you want to check outGalera Cluster which is part of MariaDB Galera Cluster and Percona XtraDB Cluster.

Судя по тому, что "по вопросам обращайтесь в перкону", лучше действительно посмотреть на Galera/XtraDB.

"Сейчас, в контексте настоящей синхронной Master-Master репликации (когда целостность данных гарантируется и писать можно одновременно на все ноды кластера) много говорят про Galera. Кто-то скажет, что для этого можно попробовать использовать давно известный MySQL NDB Cluster — но широко известно, что этот «автожир» подходит очень узкому кругу приложений, редко из мира веб.

Мы с интересом следим за Galera — возможно именно на ней в будущем будут строить подлинные Master-Master кластера, а пока посмотрим что полезного можно извлечь из имеющихся хорошо проверенных стабильных инструментов."

http://habrahabr.ru/company/bitrix/blog/146490/
И снова битрикс-блог...

Галеру/XtraDB рассмотрю отдельно, как руки дойдут. Скорее всего, будет применяться у нас для отказоустойчивости, гео-кластер.

Даже с MMM остаётся вопрос идентичности данных на нодах. Как там реализована проверка целостности? Есть ли тогда автоматическое лечение? Скорее всего, нет ничего, и для небольших таблиц надо делать CHECKSUM TABLE, а с большими будет засада.

Линки
Installation Guide
http://mysql-mmm.org/mysql-mmm.html
http://habrahabr.ru/company/bitrix/blog/146490/

Ещё о репликации

Есть сервер, надо поднять ему slave.
Раньше была команда load data from master, но потом её объявили deprecated. Сейчас 2 метода:
1) rsync/csync2/etc
2) dump - restore

Оба сервера должны быть предварительно подготовлены -- создан юзер для репликации, прописаны server-id, bin-log итд.
На слейве - прописаны базы/таблицы для репликации.
Если сихронизировать через rsync, базы на слейве надо предварительно создать, причём крайне желательно, чтобы такие параметры как язык совпадал. Движок (engine) совпадать должен обязательно! И так не получится перенести innodb. Для dump можно указать ключ
Пользователи и права переносятся руками.

Любые такие операции выполняются с flush tables with read lock, show master status

По идее, можно остановить мастер, выполнить файловую синхронизацию.. но как в этом случае узнать позицию в логе? А без неё не запустить репликацию, так что получили п.1

1) сихронизируем (пока без остановки - главное, перегнать основной объем);
flush, show, делаем синхронизацию, снова show чтобы проверить, что ничего не убежало, снимаем лок (unlock tables), меняем мастера.

Но тут обнаружилась проблема: первая синхронизация шла со скоростью порядка 10мбит/с (канал такой, но проектам хватает), а вот вторая...
sent 2751559 bytes received 2278456 bytes 3617.41 bytes/sec
3кб/с! Заняло это минут 20, что вызвало 500 ошибку. А изменений было относительно немного... Вывод - этот метод непригоден для нагруженных проектов, с часто изменяемыми данными. Да и просто большими базами. Но хорошо работает на копировании с slave-сервера, подробнее есть ниже (с остановкой sql_thread и переносом файлов). И только для myisam; innodb в режиме разделения по файлам.

2) dump
могут пригодиться ключи
--master-data - обязательный ключ. Включает в себя CHANGE MASTER TO - устанавливает позицию в логе итд. Можно дописать =1 или 2: при 1 CHANGE MASTER TO сменит мастера и позицию, при 2 CHANGE MASTER TO закомментирован и несёт скорее информативный характер.
--delete-master-logs - имеет смысл только если слейв 1 или для бэкапов.
--single-transaction - в 1 поток, это несколько быстрее, но ставит глобальный лок на некоторое время. Имеет смысл только с транзакционными движками типа InnoDB
--create-db - создать базу
--opt - ключ, который включает в себя массу других, наиболее часто применямых. Рекомендуемо. Впрочем, если верить ману, он включен по умолчанию.


Важный момент: если надо перенести больше 1 базы - позиция должна быть неизменной или для каждой заливки надо делать flush, dump, restore, иначе данные могут оказаться разными на разных серверах.

В man mysqldump описан ещё вариант создания слейва, если уже есть хотя бы один, искать описание --master-data
Приведу тут пересказ:
1. Остановить SQL поток на слейве
mysql> STOP SLAVE SQL_THREAD;
mysql> SHOW SLAVE STATUS;
Нужны поля Relay_Master_Log_File и Exec_Master_Log_Pos
2. Дампим данные
shell> mysqldump --master-data=2 --all-databases > dumpfile

3. запускаем слейв
mysql> START SLAVE;

4. На новом слейве загружаем дамп
shell> mysql < dumpfile 5. На новом слейве меняем мастера mysql> CHANGE MASTER TO
-> MASTER_LOG_FILE = 'file_name', MASTER_LOG_POS = file_pos;
Может потребоваться также задать такие значения как MASTER_HOST

Ещё момент - при использовании ZFS можно сделать lock, дождаться его (как?), сделать snapshot, получить master_pos, unlock. И теперь можно перекидывать данные или сам снапшот на другой сервер (если делаем полную копию)

12.5.2.1. CHANGE MASTER TO Syntax
CHANGE MASTER TO option [, option] ...

option:
MASTER_HOST = 'host_name'
| MASTER_USER = 'user_name'
| MASTER_PASSWORD = 'password'
| MASTER_PORT = port_num
| MASTER_CONNECT_RETRY = interval
| MASTER_LOG_FILE = 'master_log_name'
| MASTER_LOG_POS = master_log_pos
| RELAY_LOG_FILE = 'relay_log_name'
| RELAY_LOG_POS = relay_log_pos
| MASTER_SSL = {0|1}
| MASTER_SSL_CA = 'ca_file_name'
| MASTER_SSL_CAPATH = 'ca_directory_name'
| MASTER_SSL_CERT = 'cert_file_name'
| MASTER_SSL_KEY = 'key_file_name'
| MASTER_SSL_CIPHER = 'cipher_list'
http://dev.mysql.com/doc/refman/5.0/en/change-master-to.html

--размышления--

Вот есть у нас сервер, к примеру с десятком баз, реплицируется допустим 8. Как переносить базы на другой сервер, с минимальным простоем? Если делать к примеру mysqldump на каждую базу, то master-data будет показывать на разные записи. Что будет происходить при загрузке этих дампов? Как обеспечить тогда синхронность данных? Делать после каждой заливки slave start,...,slave stop и следующую заливать? Залить просто все, потом на slave start оно само выровняет? Сомневаюсь.
Обидно, что нет команды resync например, чтобы сервер сам проверил все записи и нужные слил. Важно, чтобы еще с innodb работало. С инной даже проще - делаем транзакцию (и получаем целостный набор данных), и сохраняем в переменные текущую лог-позицию. После синхронизации завершаем транзакцию и выставляем лог. Причем для оперативности можно relay-log с текущей позиции сразу вести, и по окончанию перелива быстро прогнать его.

про репликацию файлов

[в процессе написания]
Задача: есть несколько серверов, данные на которых надо синхронизировать.
Тут несколько видов решений:
1) раз в N минут делается скан системы на изменения и синхронизируется.
Плюсы - работает со всеми фс, позволяет делать выборочную синхронизацию, эффективное использование сети, возможность ограничить скорость
Минусы - больше нагрузка на процессор, диски, измененный файл может оказаться на зеркале через весьма долгое время, возможны конфликты с одновременным изменением файла. Эффективно может быть только в системе master-slave. Неприменимо для объектов с небольшим временем жизни.
Примеры - rsync, unison

1b) Почти (1), но на базе систем контроля версий.

1c) csync
На базе rsync, но используется в битриксе, значит, как минимум можно рассмотреть. Насколько я понял из документации, возможна работа мастер-мастер.

2) NAS - монтирование по сети через CIFS, NFS.
Плюсы - просто, быстро
Минусы - требует для хорошей работы сети с маленькими задержками и большими скоростями, так что применимо только при размещении в 1 датацентре, а лучше в 1 стойке, а также нормальные сетевые карты и свичи. Относительно большой оверхед. Большие требования к хранилищу, и чем больше клиентов, тем серьёзнее требования.

3) SAN - монтирование блочного устройства с отдельного хранилища. Требования еще больше, чем для (2). Для совместной работы требуется или кластерная ФС, или на машине надо поднимать такие службы как NFS.

2) блочные устройства
3) DRBD, geom gate
4) распределенные ФС
5) кластерные ФС

6) Синхронизация на базе журналов журналируемых ФС. Примеры мне неизвестны. Реализовано может быть на таких опциях как inotify, dnotify, Fanotify (2.6.37+)

немного про репликацию mysql

Понадобилось внести в набор master-slave еще одну базу.
Бинлог ведется по всем базам.
mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000416 | 6253340 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Пробуем..
master:
create database db character set cp1251;

slave:
vi my.cnf
вносим базу в список replicate-do-db=
перезапускаем слейв (стоит скип-старт). Базы нет. Да и не должно.
slave start;
базы нет. Но в show slave status она есть.
Попробуем создать.
create database db character set cp1251;
use db;
база есть.
show tables пока пуст, но и на мастере нету ничего. А теперь проверим "живую" заливку.

master:
mysql -u root -p db
slave:
show tables - заливка прошла!
Теперь осталось залить пользователей, потому что слейв не слушает базу mysql.

master и slave:

grant all privileges on db.* to 'db'@'localhost' identified by 'pass';
flush privileges;

В принципе все.