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

You are viewing an old version of this article. View the current version here.

Getting replication working involves steps on both the master server/s and steps on the slave server/s.

MariaDB 10.0 introduced replication with global transaction IDs. These have a number of benefits, and it is generally recommended to use this feature from MariaDB 10.0. The following instructions describe the old-style replication first.

Конфигурация master

  • Включите binary logging. Смотрите Activating the Binary Log и Binary log formats для получения деталей.
  • Задайте для master уникальный server_id. Также у всех slave должен быть указан server_id. Для этого введите число от 1 до 232-1, это число должно быть уникальным для каждого сервера группы репликации.
  • Укажите уникальное название для ваших журналов репликации --log-basename. Если это не указывать, то тогда будет использоваться название хоста и в дальнейшем могут возникнуть проблемы, если это название хоста будет изменено.
  • Для slave серверов необходимо выставить права на соединение и запуск репликации. Обычно для этого создается выделенный пользователь на slave и указываются для него права только на репликацию (REPLICATION SLAVE права).

Пример

Добавьте в файл my.cnf:

[mariadb]
log-bin
server_id=1
log-basename=master1

Выполните в командной строке SQL:

GRANT REPLICATION SLAVE ON *.* TO replication_user;

Проверка настроек

There are a number of options that may impact or break replication. Check the following settings to avoid problems.

  • skip-networking. Если skip-networking=1, то сервер будет ограничивать подключения только к localhost, а удаленные slave не смогут соединиться.
  • bind-address. Similarly, if the address the server listens for TCP/IP connections is 127.0.0.1 (localhost), remote slaves connections will fail.

Конфигурация slave

  • Задайте для slave уникальный server_id. У всех серверов, вне зависимости master или slave, должен быть указан server_id. Для этого введите число от 1 до 232-1, это число должно быть уникальным для каждого сервера группы репликации. Сервера должны быть перезапущены для того, чтобы изменения вступили в силу.

Получение координат binary log на master

Теперь вам необходимо предотвратить любые изменения данных для того чтобы получить текущую позицию в binary log. Это необходимо для того, чтобы задать всем slave позицию начала репликации данных.

  • На master, заблокируйте все таблицы выполнив FLUSH TABLES WITH READ LOCK. Поддерживайте эту сессию запущенной иначе блокировка будет снята.
  • Получите текущую позицию binary log выполнив SHOW MASTER STATUS:
SHOW MASTER STATUS;
+--------------------+----------+--------------+------------------+
| File               | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+--------------+------------------+
| mariadb-bin.000096 |      568 |              |                  |
+--------------------+----------+--------------+------------------+
  • Запишите данные поля File и Position. Если binary log только что был включен, то поля будут пустые.
  • Now, with the lock still in place, copy the data from the master to the slave. See Backup, Restore and Import for details on how to do this.
  • После того как данные будут получены, вы можете снять блокировку на master выполнив UNLOCK TABLES.
UNLOCK TABLES;

Запуск slave

  • Once the data has been imported, you are ready to start replicating. Begin by running a CHANGE MASTER TO, making sure that MASTER_LOG_FILE matches the file and MASTER_LOG_POS the position returned by the earlier SHOW MASTER STATUS. For example:
CHANGE MASTER TO
  MASTER_HOST='master.domain.com',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='bigs3cret',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='mariadb-bin.000096',
  MASTER_LOG_POS=568,
  MASTER_CONNECT_RETRY=10;

If you are starting a slave against a fresh master that was configured for replication from the start, then you don't have to specify MASTER_LOG_FILE and MASTER_LOG_POS.

  • Теперь запустите slave с помощью комманды START SLAVE:
START SLAVE;

Replicating from MySQL master to MariaDB slave

  • Replicating from MySQL 5.5 to MariaDB 5.5+ should just work.
  • Replicating from MySQL 5.6 without GTID to MariaDB 10+ should work.
  • Replication from MySQL 5.6 with GTID, binlog_rows_query_log_events and ignorable events works starting from MariaDB 10.0.22 and MariaDB 10.1.8. In this case MariaDB will remove the MySQL GTIDs and other unneeded events and instead adds its own GTIDs.

Use global transaction id (GTID)

MariaDB starting with 10.0

Note that MariaDB 10.0 introduced global transaction IDs (GTIDs) for replication. It is generally recommended to use (GTIDs) from MariaDB 10.0, as this has a number of benefits. All that is needed is to add the MASTER_USE_GTID option to the CHANGE MASTER statement, for example:

CHANGE MASTER TO MASTER_USE_GTID = current_pos

Смотрите полное описание Global Transaction ID.

Читайте также

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.