You are here

Главная

Настройка Master-Slave Replication на MariaDB (MySQL). Проверка и тестирование.

Linux: 
MariaDB/MySQL

Настройка Master-Slave Replication на MariaDB (MySQL). Начало.

Продолжим. Если вы не читали статью ранее, сначала изучите её:
Настройка Master-Slave Replication на MariaDB (MySQL). Начало.

В этой статье разберем:

  • Настраиваем конфигурационный файл 50-server.cnf на Slave
  • Дамп базы данных на Slave. Перенос на Slave
  • Восстановление баз данных на Slave
  • Репликация: подключаем Slave к Master
  • Проверка работы репликации

1. Настраиваем конфигурационный файл 50-server.cnf на Slave

Открываем файл 50-server.cnf на Slave, и заполняем по аналогии (как мы заполняли Master):

  1. sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

В файле находим строчку блока «Logging and Replication». В конце этого блока начинаем прописывать наши параметры:

  1. [mysqld]
  2. server-id       = 02
  3. relay-log-index = /var/log/mysql/slave-relay-bin.index
  4. relay-log       = /var/log/mysql/slave-relay-bin
  5. replicate-do-db = wordpress
  6. replicate-do-db = mariamaster
  7. read-only = 1
  8. bind-address    = 192.168.0.6

Новая строчка:
read-only = 1 - данная строчка означает: "Только чтение".

Не забываем закомментировать строку:

  1. # bind-address = 127.0.0.1

Сохраняем файл и перезапускаем MariaDB:

  1. sudo systemctl restart mariadb

Наши сервера почти готовы к процессу репликации. На данном этапе работу со Slave пока прекращаем.

2. Дамп базы данных на Slave. Перенос на Slave

Нам нужно скопировать наши базы данных с главного сервера на подчиненный. И только потом запускать процесс репликации. Возвращаемся в Master. Заходим в базу данных и вводим команду блокировки:

  1. > flush tables with read lock;

Проверяем статус мастера:

  1. MariaDB [(none)]> show master status;
  2. +-------------------+----------+--------------+------------------+
  3. | File              | Position | Binlog_Do_DB | Binlog_Ignore_DB |
  4. +-------------------+----------+--------------+------------------+
  5. | master-bin.000001 |      772 |              |                  |
  6. +-------------------+----------+--------------+------------------+
  7. 1 row in set (0.000 sec)

Важно: НЕ выходя из монитора MariaDB, делаем дамп базы. Если выйти, то это снимет блокировку.

Открываем второй терминал и там делаем дамп базы данных. Делать его будем в какой-то определенной папке. Мы делали в папке пользователя(дамп делается не в самой базе MariaDB, а в терминале Debian).

  1. sudo mysqldump -u root mariamaster  > mariamaster.sql
  2. sudo mysqldump -u root wordpress  > wordpress.sql

Напоминаем: если вы не помните как называется ваша база данных, в MariaDB введи команду "show databases;".

Как только мы сделали бэкап базы данных, разблокируем базы и сделаем выход из MariaDB:

  1. > unlock tables;
  2. > exit;

Теперь нам нужно перенести файлы баз данных на Slave. Самое простое использовать команду scp. Использование данной команды описывать я не буду, можете почитать отдельно. Скажу только, что у меня настроен SSH от Master к Slave:

  1. scp /home/debuser/Документы/MariaDB_MS debiuser@192.168.0.6:/home/debiuser/Документы/

Если у вас будет ошибка, скорее всего у вас проблема с правами как на файлы дампа, так и на созданную папку. Не забываем проверить права, при копировании. Если вы будете копировать пользователем, а у вас дамп сделан с правами root, он вам ничего не скопирует. Команда "sudo chown" вам в помощь.

3. Восстановление баз данных на Slave

После того как мы все скопировали, необходимо создать пустые базы (с такими же именами, как в дампах). Для этого на Slave заходим в базу MariaDB и вводим команды:

  1. CREATE DATABASE wordpress;
  2. CREATE DATABASE mariamaster;

Проверяем наши вновь созданные базы и выходим из MariaDB:

  1. SHOW DATABASES;
  2. exit;

Уже в терминале восстанавливаем наш бэкап баз из дампа:

  1. sudo mysql -u root wordpress < wordpress.sql
  2. sudo mysql -u root wordpress < mariamaster.sql

Делаем перезагрузку MariaDB:

  1. sudo systemctl restart mariadb

Мы сделали идентичные базы на Master и Slave, в одинаковом первоначальном состоянии. И только после этого, можно приступать к подключению.

4. Репликация: подключаем Slave к Master

Для того чтобы подключить Slave к Master, нужно на подчиненном сервере (Slave) зайти в MariaDB и ввести следующие значения (сначала их составьте в блокноте, потом вставляйте в консоль базы):

  1. MariaDB [(none)]> change master 'master01' to     
  2. master_host='192.168.0.5',     
  3. master_user='replicant',     
  4. master_password='replicant',     
  5. master_port=3306,     
  6. master_log_file='master-bin.000001',     
  7. master_log_pos=772,     
  8. master_connect_retry=10,     
  9. master_use_gtid=slave_pos;

В данных выше мы указали:

  • Название мастера
  • IP мастера
  • Пользователя и его пароль, созданный ранее для базы
  • Порт, стандартный
  • "master_log_file" и "master_log_pos" взяли из команды: "show master status;" (есть выше в тексте)
  • остальное укажите по примеру

Начинаем соединение в MariaDB на Slave:

  1. > start slave 'master01';

Проверяем статус в MariaDB на Slave:

  1. show slave 'master01' status\G;

и получим следующее:

  1. MariaDB [(none)]> show slave 'master01' status\G;
  2. *************************** 1. row ***************************
  3.                 Slave_IO_State: Waiting for master to send event
  4.                    Master_Host: 192.168.0.5
  5.                    Master_User: replicant
  6.                    Master_Port: 3306
  7.                  Connect_Retry: 10
  8.                Master_Log_File: master-bin.000009
  9.            Read_Master_Log_Pos: 343
  10.                 Relay_Log_File: slave-relay-bin-master01.000002
  11.                  Relay_Log_Pos: 643
  12.          Relay_Master_Log_File: master-bin.000009
  13.               Slave_IO_Running: Yes
  14.              Slave_SQL_Running: Yes
  15.                Replicate_Do_DB: wordpress,mariamaster
  16.            Replicate_Ignore_DB:
  17.             Replicate_Do_Table:
  18.         Replicate_Ignore_Table:
  19.        Replicate_Wild_Do_Table:
  20.    Replicate_Wild_Ignore_Table:
  21.                     Last_Errno: 0
  22.                     Last_Error:
  23.                   Skip_Counter: 0
  24.            Exec_Master_Log_Pos: 343
  25.                Relay_Log_Space: 961
  26.                Until_Condition: None
  27.                 Until_Log_File:
  28.                  Until_Log_Pos: 0
  29.             Master_SSL_Allowed: No
  30.             Master_SSL_CA_File:
  31.             Master_SSL_CA_Path:
  32.                Master_SSL_Cert:
  33.              Master_SSL_Cipher:
  34.                 Master_SSL_Key:
  35.          Seconds_Behind_Master: 0
  36.  Master_SSL_Verify_Server_Cert: No
  37.                  Last_IO_Errno: 0
  38.                  Last_IO_Error:
  39.                 Last_SQL_Errno: 0
  40.                 Last_SQL_Error:
  41.    Replicate_Ignore_Server_Ids:
  42.               Master_Server_Id: 1
  43.                 Master_SSL_Crl:
  44.             Master_SSL_Crlpath:
  45.                     Using_Gtid: Slave_Pos
  46.                    Gtid_IO_Pos: 0-1-4
  47.        Replicate_Do_Domain_Ids:
  48.    Replicate_Ignore_Domain_Ids:
  49.                  Parallel_Mode: conservative
  50.                      SQL_Delay: 0
  51.            SQL_Remaining_Delay: NULL
  52.        Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
  53.               Slave_DDL_Groups: 0
  54. Slave_Non_Transactional_Groups: 0
  55.     Slave_Transactional_Groups: 0
  56. 1 row in set (0.001 sec)
  57.  
  58. ERROR: No query specified

Если вы не видите ошибок в выводе, это означает, что репликация работает хорошо. Вы должны увидеть следующие два «Yes», указывающие, что все идет хорошо:

  1. ...
  2. Slave_IO_Running: Yes
  3. Slave_SQL_Running: Yes
  4. ...

И?... cкажете вы, где тут проверка, что все работает? Ранее мы создавали тестовую таблицу, вот на ней и будем проверять! Читаем дальше.

* Некоторые полезные команды:

  • stop slave 'master01'; (Чтобы остановить репликацию)
  • reset slave 'master01'; (чтобы репликация перезапускалась из чистого состояния, вы можете сбросить репликацию)
  • reset slave 'master01' all; (тоже что и второе, только не пытается запустить репликации после перезапуска)

5. Проверка работы репликации

Вариант 1

На мастере делаем команду:

  1. MariaDB [(none)]> show variables like 'gtid_binlog_pos';
  2. +-----------------+-------+
  3. | Variable_name   | Value |
  4. +-----------------+-------+
  5. | gtid_binlog_pos | 0-1-4 |
  6. +-----------------+-------+
  7. 1 row in set (0.002 sec)

Далее на подчиненном сервере выполняем:

  1. MariaDB [(none)]> show variables like 'gtid_slave_pos';
  2. +----------------+-------+
  3. | Variable_name  | Value |
  4. +----------------+-------+
  5. | gtid_slave_pos | 0-1-4 |
  6. +----------------+-------+
  7. 1 row in set (0.002 sec)

Если эти два значения совпадают, то изменения данных на ведущем устройстве копируются на ведомое устройство.

И что? Не верю! Тогда 100% вариант ниже.

Вариант 2

На мастере заходим в базу данных и переходим в таблицу для тестов "mariamaster":

  1. USE mariamaster;

Вносим новые данные:

  1. INSERT INTO equipment (type, install_date, color, working, location)
  2. VALUES
  3. ("Swing", Now(), "green", 1, "Northwest Corner");

Проверяем данные:

  1. SELECT * FROM equipment;

Выходим...

... Заходим в базу данных на Slave. Переключаемся в нашу базу и проверяем таблицу:

  1. MariaDB [mariamaster]> USE mariamaster;
  2. MariaDB [mariamaster]> SELECT * FROM equipment;
  3. +----------+-------+--------------+-------+---------+------------------+
  4. | equip_id | type  | install_date | color | working | location         |
  5. +----------+-------+--------------+-------+---------+------------------+
  6. |        1 | Slide | 2019-10-02   | blue  |       1 | Southwest Corner |
  7. |        2 | Swing | 2019-10-02   | green |       1 | Northwest Corner |
  8. +----------+-------+--------------+-------+---------+------------------+
  9. 2 rows in set (0.001 sec)

Таблица отразилась! Репликация полностью работает! Всем спасибо, кто читал)

Источник: http://linuxsql.ru