Репликация mysql: Настройка репликации в MySQL | Timeweb Cloud

Настройка репликации — MariaDB Knowledge Base

Contents

1. Конфигурация master
   1. Пример
2. Проверка настроек
3. Конфигурация slave
4. Получение координат binary log на master
5. Запуск slave
6. Репликация с MySQL master на MariaDB slave
7. Использование global transaction id (GTID)
8. Читайте также

Данная инструкция replication включает шаги для master и для slave серверов.

MariaDB 10.0 ввел репликацию с global transaction IDs. Оно имеет ряд преимуществ, поэтому эту функцию рекомендуется использовать для MariaDB 10.0. Данная инструкция описывает устаревший стиль репликации.

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

• Включите binary logging. Смотрите Activating the Binary Log и Binary log formats для получения деталей.
• Задайте для master уникальный server_id. Также у всех slave должен быть указан server_id. Для этого введите число от 1 до 2 ³²-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;

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

Есть несколько вариантов установки опций, которые могут повлиять на репликацию. Проверьте следующие настройки опций, чтобы в дальнейшем избежать проблем.

• skip-networking. Если skip-networking=1, то сервер будет ограничивать подключения только к localhost, а удаленные slave не смогут соединиться.
• bind-address. Также, если адрес сервера прослушивает соединения TCP/IP 127.0.0.1 (localhost), удаленные slave не смогут соединиться.

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

• Задайте для slave уникальный server_id. У всех серверов, вне зависимости master или slave, должен быть указан server_id. Для этого введите число от 1 до 2 ³²-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 только что был включен, то поля будут пустые.
• Теперь, когда таблицы еще заблокированы, скопируйте данные с master на slave. О том, как это сделать, вы можете прочитать в Backup, Restore and Import.
• После того как данные будут получены, вы можете снять блокировку на master выполнив UNLOCK TABLES.

UNLOCK TABLES;

Запуск slave

• После того как данные были импортированы, вы можете запустить репликацию. Для начала запустите CHANGE MASTER TO, убедившись в том, что MASTER_LOG_FILE и MASTER_LOG_POS соответствую полям выведенными ранее командой SHOW MASTER STATUS. Например:

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;

Если вы запускаете slave со свежим master который только что был настроен на запуск репликации, то в этом случае вам не нужно указывать MASTER_LOG_FILE и MASTER_LOG_POS.

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

START SLAVE;

Репликация с MySQL master на MariaDB slave

• Репликация с MySQL 5.5 на MariaDB 5.5+ работает.
• Репликация с MySQL 5.6 без GTID на MariaDB 10+ работает.
• Репликация с MySQL 5.6 с GTID, binlog_rows_query_log_events и 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.

Использование global transaction id (GTID)

MariaDB starting with 10.0

Обратите внимание, что в MariaDB 10.0 введен global transaction IDs (GTIDs) для репликации. Как правило, это рекомендуется использовать (GTIDs) для MariaDB 10.0, так как имеет ряд преимуществ. Все что требуется, так это добавить MASTER_USE_GTID опцию в оператор CHANGE MASTER, например:

CHANGE MASTER TO MASTER_USE_GTID = current_pos

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

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

• Replication and Foreign Keys
• Replication as a Backup Solution
• Multi-source Replication
• Global Transaction ID
• Parallel Replication
• Replication and Binary Log Status Variables
• Semisynchronous Replication
• Delayed Replication

Comments

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.

Репликация MySQL. Настройка репликации MySQL (Master/Slave)

Репликация MySQL позволяет повысить уровень отказоустойчивости приложения, а так же позволяет распределить нагрузку между серверами баз данных MySQL или MariaDB.

Для создания репликации необходимо, как минимум, 2 сервера. Один из них будет являться master-сервером, а второй (и другие) — slave. При выполнении операций в базе данных на master сервере, она записывает всю информацию в специальный файл — binlog. А slave сервер, в свою очередь, подключается к master серверу, сравнивает значения и если появляется новая информация — выполняет ее у себя в базе данных.

Пример настройки репликации

Для примера, мы возьмем 2 сервера. Устанавливать будем на примере Debian GNU/Linux. Настройка везде примерно одинакова за исключением того, что файл my. cnf в Debian (Ubuntu) находится в директории /etc/mysql/, а в CentOS — просто в /etc/.

Адреса серверов:

• Master-сервер — 192.168.0.1
• Slave-сервер — 192.168.0.2

Настраиваем Master-сервер.

Для начала, нужно открыть файл my.cnf и указываем следующее:

# выбираем ID сервера, произвольное число, лучше начинать с 1
server-id = 1

# путь к бинарному логу
log_bin = /var/log/mysql/mysql-bin.log

# название базы данных, реплика которой необходима
binlog_do_db = websitedb

Затем, перезапускаем сервер MySQL командой

/etc/init.d/mysql restart

Затем, нам нужно выдать пользователю права на репликацию. Подключаемся к серверу под пользователем root:

mysql -u root -p

Добавляем необходимые права для пользователя slave_user (владельца нашей базы websitedb) и задаем ему пароль password:

GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘password’;
FLUSH PRIVILEGES;

Затем, нам нужно заблокировать все таблицы от всех изменений:

USE websitedb;
FLUSH TABLES WITH READ LOCK;

Затем, нам нужно проверить статус работы Master-сервера с помощью команды:

SHOW MASTER STATUS;

Если все сделано верно, Вы увидите сообщение с именем файла, с названием вида:

mysql-bin. 000001

А так же запомните значение из столбца Position. В нашем случае, это 10.
Это имя нам потребуется при создании и запуска слейв-сервера.

Делаем свежий дамп базы данных:

mysqldump -u root -p websitedb > websitedb.sql

Копируем файл на слейв-сервер и на мастере подключаемся к MySQL еще раз под root’ом и выполняем команду, чтобы разблокировать таблицы:

UNLOCK TABLES;

Создаем базу на Slave-сервере

Для того, чтобы работало все корректно, на слейв сервере необходимо создать базу с таким же именем. Подключаемся к MySQL на слейв-сервере и создаем базу:

CREATE DATABASE websitedb;

И заливаем наш дамп, который мы уже скопировали командой:

mysql -u root -p websitedb < websitedb.sql

Настройка Slave-сервера

Открываем файл my.cnf и указываем следующие параметры:

# ID сервера, будет удобно выбирать следующим числом после Master
server-id = 2

# Путь к relay логу
relay-log = /var/log/mysql/mysql-relay-bin. log

# Путь к bin логу на Мастере
log_bin = /var/log/mysql/mysql-bin.log

# База данных для репликации
binlog_do_db = websitedb

И перезапускаем сервер MySQL командой

/etc/init.d/mysql restart

Запуск Slave сервера

Все сделано, осталось самое главное — подключить Slave сервер к мастеру. Подключаемся к MySQL под root’ом и выполняем следующую команду:

CHANGE MASTER TO MASTER_HOST=’192.168.0.1′, MASTER_USER=’slave_user’, MASTER_PASSWORD=’password’, MASTER_LOG_FILE = ‘mysql-bin.000001’, MASTER_LOG_POS = 10;

Здесь мы вставляем номер из столбца Position (в нашем случае, это было число 10) и название binlog файла — mysql-bin.000001

И теперь стартуем слейв сервер командой в консоли MySQL:

START SLAVE;

Проверить работу на мастер сервере можно командой в MySQL консоли:

SHOW MASTER STATUS\G;

А на слейв-сервере, соответственно:

SHOW SLAVE STATUS\G;

Под настройку репликации мы рекомендуем выделенные сервера купить в аренду у нашей компании. Мы поможем с настройкой и поддержкой Ваших баз данных MySQL и MariaDB.

Если у вас возникли вопросы или трудности в настройках — вы можете в любое время обратиться за помощью к специалистам хостинга RigWEB. Мы будем рады вам помочь!

Как реплицировать базу данных MySQL на другой сервер

Репликация MySQL позволяет легко копировать базу данных с одного сервера на другой. MySQL поддерживает различные виды репликации, такие как master-slave, master-master и групповая репликация. MariaDB также поддерживает репликацию с несколькими мастерами. В этой статье мы рассмотрим репликацию Master-Slave в MySQL и узнаем, как реплицировать базу данных MySQL в Linux. Вы можете использовать эти шаги для репликации базы данных MySQL в Ubuntu, Debian, CentOS, Fedora, Red Hat и других типах Linux.

Как реплицировать базу данных MySQL

Вот шаги для репликации базы данных MySQL. Для нашей настройки нам понадобится главная база данных (IP — 54.24.32.12) и подчиненная база данных (IP — 45. 12.21.23). Мы будем реплицировать базу данных с именем exampledb от главного к подчиненному. Мы предположили, что у вас установлен MySQL на обоих этих серверах, и у вас есть привилегии суперпользователя для них обоих. В противном случае вы можете установить MySQL с помощью следующей команды

 $ sudo apt-get install mysql-server mysql-client 

Дополнительное чтение: Лучшие альтернативы MySQL Workbench

1. Отредактируйте основной файл конфигурации

Откройте терминал на сервере основной базы данных и выполните следующую команду

 $ sudo vi /etc/mysql/my.cnf 

По умолчанию удаленные подключения отключены в MySQL. Нам нужно разрешить удаленное подключение от ведомого устройства к ведущему для репликации. Поэтому мы раскомментируем следующие две строки, чтобы разрешить удаленные подключения, добавив # в их начале, как показано ниже

 #skip-networking
#бинд-адрес=127.0.0.1 932. 
 
  log-bin  указывает местоположение файла журнала, который будет заполнен MySQL деталями репликации.
   
 
  binlog-do-db  указывает имя базы данных, которую необходимо реплицировать. 
 
 перезапустить MySQL Server для применения изменений 
 
 $ sudo service mysql restart 
 Войдите в MySQL как root user
 $ sudo mysql -u root -p 
 и запустить следующую команду
 MySQL> Показать мастер -статус;
+------------------+----------+---------------+---- --------------+
| Файл | Позиция | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+---------------+---- --------------+
| mysql-bin.000001 | 107 | пример БД | |
+------------------+----------+---------------+---- --------------+ 
 Пожалуйста, обратите внимание на приведенные выше данные, они понадобятся нам позже на шаге №3.
 
 Дополнительная информация: Как включить SSL/TLS в MySQL
 2. Создать пользователя репликации 
 Войдите на сервер MySQL на главном сервере.
 $ sudo mysql -u root -p 
 Вам будет предложено ввести пароль root.
 После входа в MySQL выполните следующие команды, чтобы создать удаленного пользователя  slave_user  и предоставить ему права репликации для всех баз данных. Пожалуйста, замените 45.12.21.23 ниже IP-адресом вашего подчиненного сервера и замените $password подходящим паролем в соответствии с вашими требованиями.
 
 mysql> СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ slave_user@  45.12.21.23  ;
mysql> ПРЕДОСТАВИТЬ ПОДЧИНЕННУЮ РЕПЛИКАЦИЯ НА *.* TO slave_user@  45.12.21.23 
       ОПРЕДЕЛЕН ' $пароль ';
mysql> УДАЛИТЬ ПРИВИЛЕГИИ; 
 Добавьте правило брандмауэра для входящего трафика для порта 3306 и разрешите 45.12.21.23. Этот удаленный пользователь должен подключиться к базе данных master, чтобы репликация произошла.
 Дополнительное прочтение: Как изменить сопоставление всех таблиц в MySQL
 3. Редактировать файл конфигурации подчиненного устройства 
 Откройте терминал на подчиненном сервере базы данных и выполните следующую команду
 $ sudo vi /etc/mysql/my.  cnf 
 Добавьте следующие строки в [mysqld], чтобы они выглядели как
 [mysqld]
идентификатор сервера = 2
реле-журнал = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = exampledb 
 В первой строке мы назначаем идентификатор сервера 2 подчиненному серверу. Следующие несколько строк указывают расположение файлов журнала ретрансляции и журнала репликации. Последняя строка указывает базу данных для репликации.
 Перезапустите сервер MySQL и войдите в MySQL
 $ sudo service mysql restart
$ sudo mysql -u root -p 
 Выполните следующие команды, чтобы создать пустую базу данных на ведомом устройстве.
 mysql> СОЗДАТЬ БАЗУ ДАННЫХ exampledb;
mysql> USE exampledb; 
 Загрузить данные из главной базы данных для заполнения подчиненной базы данных
 mysql> ЗАГРУЗИТЬ ДАННЫЕ ИЗ ГЛАВНОЙ; 
 Выход из MySQL.
 Дополнительное чтение : Лучшие блоги по базам данных, за которыми стоит следить
 4.
 Инициализация репликации
 Пока вы вошли в MySQL, выполните следующие команды, чтобы инициировать процесс репликации. Замените детали в  жирным шрифтом  на ваши значения.
 mysql> ПОДЧИНЕННЫЙ СТОП;
mysql> ИЗМЕНИТЬ МАСТЕР НА MASTER_HOST=' 54.24.32.12 ',
       MASTER_USER=' slave_user ',
       MASTER_PASSWORD='< пароль >',
       MASTER_LOG_FILE=' mysql-bin.000001 ',
       MASTER_LOG_POS=  107  ; 
 MASTER_HOST – IP-адрес или имя хоста мастера (54.24.32.12). 
 MASTER_USER — подчиненный пользователь, которого мы создали на шаге №2. 
 MASTER_PASSWORD — пароль подчиненного пользователя, который мы создали на шаге №2. 
 MASTER_LOG_FILE — файл, который MySQL вернул на шаге № 1, когда вы запустили 
 SHOW MASTER STATUS 
 MASTER_LOG_POS — позиция, которую MySQL вернул, когда вы запустили SHOW MASTER STATUS на шаге № 1 
 Наконец, мы запускаем ведомое устройство, чтобы начать репликацию базы данных MySQL .
 mysql> НАЧАТЬ ПОДЧИНЕННЫЙ; 
 Надеюсь, эта статья поможет вам реплицировать базу данных MySQL.
 Похожие сообщения: 
 Об авторе
 Об Ubiq 
 Ubiq — это мощная платформа для мониторинга и создания отчетов. Создавайте информационные панели, диаграммы и отчеты для своего бизнеса за считанные минуты. Попробуйте бесплатно!
 Мастер репликации MySQL | База знаний MariaDB 
 Термины  ведущий  и  подчиненный  исторически использовались в репликации, но термины  первичный  и , реплика  теперь предпочтительнее. Старые термины все еще используются в части документации и в командах MariaDB, хотя в MariaDB 10.5 начался процесс переименования. Процесс документирования продолжается. См. MDEV-18777, чтобы следить за ходом этой работы.
 Содержание 
 Настройка подчиненного устройства репликации с помощью Mariabackup
 Версии
 Настройка мастера
 Пример включения репликации для MariaDB
 Пример включения репликации для MySQL
 Параметры для проверки
 Настройка подчиненного устройства
 Получение координат двоичного журнала мастера
 Запуск подчиненного устройства
 Использование глобального идентификатора транзакции (GTID)
 Репликация с ведущего устройства MySQL на ведомое устройство MariaDB
 См. также
 Чтобы запустить репликацию, нужно выполнить шаги как на главном сервере, так и на подчиненном сервере.
 В MariaDB 10.0 появилась репликация с глобальными идентификаторами транзакций. У них есть ряд преимуществ, и обычно рекомендуется использовать эту функцию из MariaDB 10.0.
 Настройка подчиненного устройства репликации с помощью Mariabackup 
 Если вы хотите использовать Mariabackup для настройки подчиненного устройства репликации, вам может оказаться полезной информация в разделе Настройка подчиненного устройства репликации с помощью Mariabackup.
 Версии 
 В целом, при репликации между различными версиями MariaDB лучше всего, чтобы главная версия была более старой, чем подчиненная. Версии MariaDB обычно обратно совместимы, хотя, конечно, более старые версии не всегда могут быть совместимы вперед. См. также Репликация с ведущего устройства MySQL на ведомое устройство MariaDB.
 Настройка ведущего устройства 
 Включите ведение двоичного журнала, если оно еще не включено. Дополнительные сведения см. в разделе Активация форматов двоичного журнала и двоичного журнала.
 Присвойте мастеру уникальный server_id. Всем подчиненным также должен быть присвоен server_id. Это может быть число от 1 до 2  32  -1, и оно должно быть уникальным для каждого сервера в группе репликации.
 Укажите уникальное имя для журналов репликации с --log-basename. Если это не указано, будет использоваться ваше имя хоста, и возникнут проблемы, если имя хоста когда-либо изменится.
 Подчиненным устройствам потребуется разрешение на подключение и запуск репликации с сервера. Обычно это делается путем создания выделенного подчиненного пользователя и предоставления этому пользователю разрешения только на репликацию (разрешение REPLICATION SLAVE).
 Пример включения репликации для MariaDB 
 Добавьте следующее в файл my.cnf и перезапустите базу данных.
 [мариадб]
бревно
идентификатор_сервера=1
имя_журнала=master1
бинлог-формат = смешанный
 
 Идентификатор сервера — это уникальный номер для каждого сервера MariaDB/MySQL в вашей сети. binlog-format указывает, как протоколируются ваши заявления. В основном это влияет на размер двоичного журнала, который пересылается между ведущим и ведомыми устройствами.
 Затем выполните следующий SQL с помощью клиента командной строки  mysql :
 CREATE USER 'replication_user'@'%' ИДЕНТИФИКАЦИЯ 'bigs3cret';
GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
 
 Пример включения репликации для MySQL 
 Если вы хотите включить репликацию из MySQL в MariaDB, вы можете сделать это почти так же, как между серверами MariaDB. Основное отличие состоит в том, что MySQL не поддерживает  log-basename  .
 [mysqld]
бревно
идентификатор_сервера=1
 
 Параметры для проверки 
 Существует ряд параметров, которые могут повлиять на репликацию или нарушить ее. Проверьте следующие настройки, чтобы избежать проблем.
 пропуск сети. Если  skip-networking=1  , сервер будет ограничивать подключения только к локальному хосту и запрещать подключение всех удаленных подчиненных устройств.
 адрес привязки. Точно так же, если сервер прослушивает соединения TCP/IP по адресу 127.0.0.1 (localhost), соединения с удаленными ведомыми устройствами завершатся ошибкой.
 Настройка подчиненного устройства 
 Дайте подчиненному устройству уникальный server_id. Всем серверам, ведущим или подчиненным, присваивается server_id. Это может быть число от 1 до 2  32  -1, и оно должно быть уникальным для каждого сервера в группе репликации. Сервер необходимо будет перезапустить, чтобы изменение этой опции вступило в силу.
 Получение координат бинарного лога Мастера 
 Теперь вам нужно предотвратить любые изменения данных при просмотре позиции бинарного лога. Вы будете использовать это, чтобы указать ведомому серверу, с какой именно точки он должен начать репликацию.
 На мастере очистить и заблокировать все таблицы, запустив  FLUSH TABLES WITH READ LOCK  . Держите этот сеанс в рабочем состоянии — выход из него снимет блокировку.
 Получите текущую позицию в двоичном журнале, запустив  SHOW MASTER STATUS  :
 ПОКАЗАТЬ ГЛАВНЫЙ СТАТУС;
+--------------------+----------+---------------+-- --+
| Файл | Позиция | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+---------------+-- --+
| master1-bin.000096 | 568 | | |
+--------------------+----------+---------------+-- --+
 
 Запишите данные  File  и  Position . Если ведение двоичного журнала только что было включено, они будут пустыми.
 Теперь, не снимая блокировки, скопируйте данные с ведущего на ведомый. Подробную информацию о том, как это сделать, см. в разделе «Резервное копирование, восстановление и импорт».
 Примечание для активных баз данных: вам просто нужно сделать локальную копию данных, вам не нужно держать главный сервер заблокированным, пока подчиненный не импортирует данные.
 После того, как данные будут скопированы, вы можете снять блокировку с мастера, запустив UNLOCK TABLES.
 РАЗБЛОКИРОВАТЬ СТОЛЫ;
 
 Запуск ведомого устройства 
 После импорта данных вы готовы начать репликацию. Начните с выполнения CHANGE MASTER TO, убедившись, что  MASTER_LOG_FILE  соответствует файлу, а  MASTER_LOG_POS  позиции, возвращенной ранее SHOW MASTER STATUS. Например:
 ЗАМЕНИТЬ МАСТЕР НА
  MASTER_HOST='master.domain.com',
  MASTER_USER='replication_user',
  MASTER_PASSWORD='bigs3cret',
  МАСТЕР_ПОРТ=3306,
  MASTER_LOG_FILE='master1-bin.000096',
  MASTER_LOG_POS=568,
  MASTER_CONNECT_RETRY=10;
 
 Если вы запускаете подчиненное устройство против нового главного устройства, которое с самого начала было настроено для репликации, вам не нужно указывать  MASTER_LOG_FILE  и  MASTER_LOG_POS  .
 Использовать глобальный идентификатор транзакции (GTID) 
 MariaDB, начиная с 10.0 
 MariaDB 10.0 представила глобальные идентификаторы транзакций (GTID) для репликации. Обычно рекомендуется использовать (GTID) из MariaDB 10.0, так как это имеет ряд преимуществ. Все, что нужно, это добавить  MASTER_USE_GTID  опция оператора  CHANGE MASTER , например:
 CHANGE MASTER TO MASTER_USE_GTID = slave_pos
 
 Полное описание см. в разделе Глобальный идентификатор транзакции.
 Теперь запустите ведомое устройство с помощью команды  START SLAVE :
 ЗАПУСК ПОДЧИНЕННЫЙ;
 
 Убедитесь, что репликация работает, выполнив команду  SHOW SLAVE STATUS :
 ПОКАЗАТЬ СОСТОЯНИЕ ВЕДОМОГО \G
 
 Если репликация работает правильно, оба значения  Slave_IO_Running  и  Slave_SQL_Running  должны быть  Да  :
 Slave_IO_Running: Да
Slave_SQL_Running: Да
 
 Репликация с MySQL Master на MariaDB Slave 
 Репликация с MySQL 5.5 на MariaDB 5.5+ должна работать. При использовании MariaDB 10.2+ в качестве ведомого может потребоваться установить для binlog_checksum значение NONE.
 Репликация из MySQL 5.6 без GTID в MariaDB 10+ должна работать.
 Репликация из MySQL 5.6 с GTID, binlog_rows_query_log_events и игнорируемыми событиями работает, начиная с MariaDB 10.0.22 и MariaDB 10.1.8. В этом случае MariaDB удалит MySQL GTID и другие ненужные события и вместо этого добавит свои собственные GTID.
 См. также 
 Различия между протоколированием на основе операторов, смешанным протоколированием и протоколированием строк
 Репликация и внешние ключи
 Репликация как решение для резервного копирования
 Репликация с несколькими источниками
 Идентификатор глобальной транзакции
 Параллельная репликация
 Системные переменные репликации и двоичного журнала
 Переменные состояния репликации и двоичного журнала
 Полусинхронная репликация
 Отложенная репликация
 Совместимость с репликацией
 Комментарии 
 Контент, воспроизведенный на этом сайте, является собственностью соответствующих владельцев,
 и этот контент не проверяется заранее MariaDB.
No related posts.