Кодер знает...

Настройка репликации MariaBD

Начиная с версии 10.0.2 у MariaDB есть новый режим репликации. Чем он отличается от старого?

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

Теперь можно создать ещё одну базу данных (slave) и указать оригинальной базе (master), с какого момента нужно передать данные из binlog-а в новую базу. Т.е. процесс такой:

master изменяется
данные об изменении записываются в binlog
из slave в master передаются данные, какой файл binlog-а и какое смещение от начала в этом файле было передано последним в slave
данные из binlog-а передаются в slave

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

Это объяснение на пальцах и на сколько я понял сам.

Теперь, как настраивать.

На сервере с master-базой:

Открываем конфигурационный файл my.cnf. Обычно он находится в каталоге \etc\mysql\.
```
sudo vi \etc\mysql\my.cnf
```

Включаем ведение файлов bin-log.

log_bin          = /var/log/mysql/mariadb-bin
log_bin_index    = /var/log/mysql/mariadb-bin.index
max_binlog_size  = 100M
expire_logs_days = 10

Устанавливаем идентификатор сервера.
```
server-id = 1
```
Перезапускаем сервер:
```
sudo service mysql restart
```
Запускаем клиент СУБД и создаем пользователя с правами на репликацию:
```
mysql -p -u root
   
GRANT REPLICATION SLAVE ON *.* TO 'user_replicate'@'%' IDENTIFIED BY 'yourSuperMegaPassword';
```
Делаем dump базы:
```
 mysqldump -p -u root --single-transaction --skip-lock-tables --hex-blob --master-data=2 dbName | gzip > ~/dbNameDump.sql.gz
```
где:
- --master-data нужно указать обязательно, он добавляет в выгрузку данные о текущей точке в binlog-е.

На сервере со slave-базой:

Восстанавливаем базу из dump-а:

gunzip dbNameDump.sql.gz
mysql -p -u root -D dbName < dbNameDump.sql

Смотрим, с какой точки начать репликацию:

> head dbName.sql -n100 | grep "gtid_slave_pos"
   
// вывод должен быть примерно таким:
-- SET GLOBAL gtid_slave_pos='0-1-74712158';

Конфигурационный файл уже оказался немного другой:
```
sudo vi \etc\mysql\mariadb.conf.d\50-server.cnf
```
Но, всё так же, основной конфигурационный файл - это my.cnf, а все остальные конфигурационные файлы вставляются в него через директиву include.

Включаем ведение файлов bin-log.

log_bin          = /var/log/mysql/mysql-bin.log
log_bin_index    = /var/log/mysql/mysql-bin.index
max_binlog_size  = 100M
expire_logs_days = 10

Устанавливаем идентификатор сервера.
```
server-id = 2
```
Задаем базу, которую будем реплицировать:
```
replicate_do_db = dbName
```
Для репликации нескольких баз нужно повторить этот параметр для каждой базы.
Перезапускаем сервер:
```
sudo service mysql restart
```

Запускаем клиент СУБД и запускаем репликацию:

mysql -p -u root
   
// указываем, с какой точки читать bin-log
SET GLOBAL gtid_slave_pos='0-1-74712158';
   
// говорим СУБД, с какого сервера реплицировать и с какой точки binlog-а начать репликацию
CHANGE MASTER TO master_host="master.domain", master_port=3306, master_user="user_replicate", master_use_gtid=slave_pos;
   
// или при использовании SSH-тунеля, как описано в этой статье https://coderknows.com/2019/02/28/ssh-tunel/
CHANGE MASTER TO master_host="127.0.0.1", master_port=33060, master_user="user_replicate", master_use_gtid=slave_pos;
   
// начать репликацию
START SLAVE;

Посмотреть статус репликации можно командой:
```
SHOW SLAVE STATUS\G
```

Полезные ссылки:

Linux MariaDB DevOps database replication

Евгений Вдовенко

Физик по образованию, занимаюсь веб-разработкой на PHP с 2013 года. Нравится ковырятся в Zend Framework/Expressive и Joomla CMS/Framework. В процессе разборок с Python. Подумываю посмотреть Go. Считаю PostgreSQL крутым продуктом и внедряю его везде, где могу.

eugene@vdovenko.xyz

eugene.vdovenko.xyz