Глава 19. Репликация

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

Преимущества репликации в MySQL включают:

См. раздел 19.3.

MySQL 8.0 понимает различные методы репликации. Традиционный метод основан на мультиплицировании событий от двоичного журнала ведущего устройства и требует, чтобы файлы системного журнала и позиции в них были синхронизированы между ведущим устройством и ведомым устройством. Более новый метод, основанный на глобальных операционных идентификаторах (GTID), является транзакционным и поэтому не требует работы с файлами системного журнала или позициями в пределах этих файлов, что очень упрощает много общих задач репликации. Репликация используя GTIDs гарантирует последовательность между ведущим устройством и ведомым устройством, пока все транзакции, переданные на ведущем устройстве, были также применены на ведомое устройство. Для получения дополнительной информации о GTIDs в MySQL см. раздел 19.1.3.

Репликация в MySQL поддерживает различные типы синхронизации. Оригинальный тип синхронизации это односторонний, асинхронный, в котором один сервер действует как ведущее устройство, в то время как один или более других серверов действуют как ведомые устройства. В MySQL 8.0 полусинхронная репликация поддержана в дополнение к встроенной асинхронной репликации. С полусинхронной репликацией передача выполнена на основных блоках прежде, чем возвратиться к сеансу, который выполнил транзакцию, пока по крайней мере одно ведомое устройство не признает, что получило и зарегистрировало события для транзакции, см. раздел 19.3.10 . MySQL 8.0 также поддерживает отложенную репликацию таким образом, что ведомый сервер сознательно отстает от ведущего устройства, по крайней мере на указанное количество времени, см. раздел 19.3.11. Для сценариев, где синхронная репликация требуется, используйте MySQL Cluster (см. MySQL Cluster NDB 7.5).

Есть много решений, доступных для репликации между серверами, и лучший метод, чтобы использовать зависит от присутствия данных и типов механизма, которые Вы используете. Для получения дополнительной информации о доступных параметрах см. раздел 19.1.2.

Есть два основных типа формата репликации, основанная на запросе и на строке. Вы можете также использовать также третий, смешанную репликацию. См. раздел 19.2.1.

Репликацией управляют через многие различные опции и переменные. Для получения дополнительной информации см. раздел 19.1.6.

Вы можете использовать репликацию, чтобы решить много различных проблем, включая резервное копирование различных баз данных, и как часть решения проблем с восстановлением после системных отказов. Для информации о том, как обратиться к этим проблемам см. раздел 19.3.

Для примечаний и подсказок относительно того, как различные типы данных и запросы обработаны во время репликации, включая детали особенностей репликации, совместимости вариантов, обновления, потенциальные проблемы и их разрешение см. раздел 19.4.

19.1. Конфигурирование репликации

Этот раздел описывает, как сконфигурировать различные типы репликации, доступные в MySQL, и включает установку и конфигурацию, требуемую для окружающей среды репликации, включая постепенные инструкции для того, чтобы создать новую окружающую среду репликации. Главные компоненты этого раздела:

19.1.1. Краткий обзор конфигурации репликации на основе двоичной позиции файла системного журнала

Этот раздел описывает репликацию между серверами MySQL, основанными на двоичном методе позиции файла системного журнала, где случай MySQL, действующий в качестве ведущего устройства (источник изменений базы данных), пишет обновления и изменения как события в двоичный журнал. Информация в двоичном журнале хранится в различных форматах журналирования согласно зарегистрированным изменениям базы данных. Ведомые устройства сконфигурированы, чтобы считать двоичной журнал от ведущего устройства, и запускать события в местной базе данных ведомого устройства.

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

Вы не можете сконфигурировать ведущее устройство, чтобы зарегистрировать только определенные события.

Каждое ведомое устройство ведет учет двоичных координат журнала: имя файла и позиция в пределах файла, который это считало и обработало от ведущего устройства. Это означает, что многократные ведомые устройства могут быть соединены с ведущим устройством и выполнять различные части того же самого двоичного журнала. Поскольку ведомые устройства управляют этим процессом, отдельные ведомые устройства могут быть соединены и разъединены от сервера, не затрагивая работу ведущего устройства. Кроме того, потому что каждое ведомое устройство делает запись текущей позиции в пределах двоичного журнала, для ведомых устройств возможно быть разъединенным, повторно соединиться и затем продолжить обрабатывать.

Ведущее устройство и каждое ведомое устройство должны быть сконфигурированы с уникальным ID (используя опцию server-id). Кроме того, каждое ведомое устройство должно быть сконфигурировано с информацией об основном имени хоста, имени файла системного журнала и позиции в пределах того файла. Этими деталями можно управлять изнутри сеанса MySQL, используя команду CHANGE MASTER TO на ведомом устройстве. Детали сохранены в пределах основного репозитария информации ведомого устройства, который может быть файлом или таблицей (см. раздел 19.2.4).

19.1.2. Установка двоичной позиции файла системного журнала

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

Есть некоторые задачи, которые характерны для всех установок:

Определенные шаги в пределах процесса установки требуют привилегии SUPER. Если у Вас нет этой привилегии, может быть невозможно включить репликацию.

После конфигурирования основных опций, выберите свой сценарий:

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

19.1.2.1. Установка ведущей конфигурации репликации

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

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

Каждый сервер в пределах группы репликации должен быть сконфигурирован с уникальным ID. Этот ID используется, чтобы идентифицировать отдельные серверы в пределах группы, и должно быть положительным целым числом между 1 и (232)-1. То, как Вы организуете и выбираете числа, является Вашим выбором.

Чтобы сконфигурировать двоичной журнал и опции ID сервера, закройте сервер MySQL и отредактируйте файл my.cnf или my.ini. В раздел [mysqld] конфигурационного файла добавляют опции log-bin и server-id. Если эти опции уже существуют, но прокомментированы, раскомментируют опции и изменяют их согласно Вашим потребностям. Например, чтобы включить двоичное журналирование, используя файл системного журнала с префиксом имени mysql-bin и сконфигурировать ID сервера 1, используйте эти строки:

[mysqld]
log-bin=mysql-bin
server-id=1

После произведения изменений, перезапустите сервер.

Следующие опции оказывают влияние на эту процедуру:

19.1.2.2. Установка ведомой конфигурации репликации

У каждого ведомого устройства репликации должно быть уникальное ID сервера. Если это не было сделано, эта часть ведомой установки требует перезапуска сервера.

Если ведомое ID сервера не установлено, или есть конфликты со значением, которое Вы выбрали для главного сервера, закройте ведомый сервер и редактируйте раздел [mysqld] конфигурационного файла, чтобы определить уникальное ID сервера. Например:

[mysqld]
server-id=2

После произведения изменений, перезапустите сервер.

Если Вы настраиваете многократные ведомые устройства, у каждого должно быть уникальное server-id , которое отличается от того из ведущего устройства и от любого другого ведомого устройства.

Если Вы опускаете server-id (или ставите это явно к его значению по умолчанию 0), ведомое устройство отказывается соединиться с ведущим устройством.

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

19.1.2.3. Создание пользователя для репликации

Каждое ведомое устройство соединяется с ведущим устройством, используя имя пользователя MySQL и пароль, таким образом должна быть учетная запись пользователя на ведущем устройстве, которую ведомое устройство может использовать, чтобы соединиться. Любая учетная запись может использоваться для этой работы, если ей предоставили привилегию REPLICATION SLAVE . Вы можете хотеть создавать различные учетки на каждое ведомое устройство или соединяться с ведущим устройством, используя одну и ту же учетку.

Хотя Вы не должны создать учетную запись определенно для репликации, Вы должны знать, что имя пользователя репликации и пароль сохранены простым тексте в основном файле репозитария информации или таблице (см. раздел 19.2.4.2). Поэтому Вы можете хотеть создать отдельную учетную запись, у которой есть привилегии только для процесса репликации, чтобы минимизировать возможность проблем с этой стороны.

Чтобы создать новую учетную запись, надо использовать CREATE USER. Чтобы предоставить этой учетной записи привилегии, требуемые для репликации, используйте GRANT. Если Вы создаете учетную запись исключительно в целях репликации, та учетная запись нуждается только в привилегии REPLICATION SLAVE . Например, чтобы настроить нового пользователя repl, который может соединиться для репликации от любого узла в пределах домена mydomain.com, сделайте так на ведущем устройстве:

mysql> CREATE USER 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';

См. раздел 14.7.1.

19.1.2.4. Получение ведущих координат двоичного журнала

Чтобы сконфигурировать ведомое устройство, чтобы запустить процесс репликации в правильном пункте, Вы должны отметить текущие координаты ведущего устройства в пределах его двоичного журнала.

Эта процедура использует FLUSH TABLES WITH READ LOCK, который блокирует COMMIT для таблиц InnoDB.

Чтобы получить основные двоичные координаты журнала, следуйте этим шагам:

  1. Запустите сеанс на ведущем устройстве, соединяясь с этим клиентом командной строки, сбросьте все таблицы и заблокируйте запросы записи, выполняя FLUSH TABLES WITH READ LOCK :

    mysql> FLUSH TABLES WITH READ LOCK;
    

    Оставьте клиента, от которого Вы выполнили FLUSH TABLES, так, чтобы блокировка чтения осталась в силе. Если Вы выходите из клиента, блокировка будет снята.

  2. В другом сеансе на ведущем устройстве, используйте SHOW MASTER STATUS, чтобы определить текущие имя файла и позицию двоичного системного журнала:
    mysql > SHOW MASTER STATUS;
    +------------------+----------+--------------+------------------+
    | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
    +------------------+----------+--------------+------------------+
    | mysql-bin.000003 | 73       | test         | manual,mysql     |
    +------------------+----------+--------------+------------------+
    

    Столбец File показывает название файла системного журнала и столбец Position показывает позицию в пределах файла. В этом примере двоичный файл системного журнала mysql-bin.000003, позиция 73. Сделайте запись этих значений. Вы нуждаетесь в них позже, когда Вы настраиваете ведомое устройство. Они представляют координаты репликации, в которых ведомое устройство должно начать обрабатывать новые обновления от ведущего устройства.

    Если ведущее устройство работало ранее без включенного журналирования, имя файла системного журнала и значения позиции, выведенные на экран SHOW MASTER STATUS или mysqldump --master-data будут пусты. В этом случае значения, которые Вы должны использовать позже, определяя файл системного журнала ведомого устройства и позицию, являются пустой строкой ('') и 4.

У Вас теперь есть информация, которую Вы должны указать ведомому устройству начать читать из журнала, чтобы запустить репликацию.

Следующий шаг зависит от того, есть ли у Вас существующие данные на ведущем устройстве. Выберите одну из следующих опций:

19.1.2.5. Выбор метода для снимков данных

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

Чтобы выбрать соответствующий метод дампа базы данных, выберите между этими опциями:

19.1.2.5.1. Создание снимка данных, используя mysqldump

Чтобы создать снимок данных в существующей основной базе данных, используйте mysqldump . Как только дамп данных был завершен, импортируйте эти данные в ведомое устройство прежде, чем запустить процесс репликации.

Следующий пример выводит все базы данных в файл dbdump.db и включает опцию --master-data, которая автоматически прилагает запрос CHANGE MASTER TO, требуемый на ведомом устройстве, чтобы запустить процесс репликации:

shell> mysqldump --all-databases --master-data > dbdump.db

Если Вы не используете --master-data, необходимо заблокировать все таблицы в отдельном сеансе вручную. См. раздел 19.1.2.4.

Возможно исключить определенные базы данных из дампа, используя mysqldump. Если Вы хотите выбрать, которые базы данных включать в дамп, не надо использовать --all-databases. Выберите одну из этих опций:

См. раздел 5.5.4.

Чтобы импортировать данные, скопируйте файл дампа к ведомому устройству или получите доступ к файлу от ведущего устройства, соединяясь удаленно с ведомым устройством.

19.1.2.5.2. Создание снимка данных, используя файлы необработанных данных

Этот раздел описывает, как создать снимок данных, используя сырые файлы, которые составляют базу данных. Использование этого метода с таблицей, используя механизм хранения, у которого есть сложные алгоритмы кэширования, требует дополнительные шаги, чтобы произвести снимок: начальная команда копии могла не учесть информацию о кэше и обновления, даже если Вы приобрели глобальную блокировку чтения. Как механизм хранения отвечает, зависит от его способностей к восстановлению катастрофического отказа.

Если Вы используете InnoDB, Вы можете использовать mysqlbackup из MySQL Enterprise Backup, чтобы произвести последовательный снимок. Эта команда делает запись имени журнала и смещения, соответствующего снимку, который будет использоваться на ведомом устройстве. См. раздел 27.2.

Этот метод также не работает достоверно, если у ведущего устройства и ведомого устройства есть различные значения для ft_stopword_file , ft_min_word_len или ft_max_word_len и Вы копируете таблицы, имеющие полнотекстовый индекс.

Принятие вышеупомянутых исключений не относится к Вашей базе данных, используя метод холодного резервирования, чтобы получить надежный двоичный снимок таблиц InnoDB: сделайте медленное завершение работы MySQL Server, затем скопируйте файлы с данными вручную.

Чтобы создать снимок необработанных данных MyISAM, когда Ваши файлы с данными MySQL существуют на единственной файловой системе, Вы можете использовать стандартные инструменты копирования файла, такие как cp или copy, удаленный инструмент, например, scp или rsync, инструмент архивирования, например, zip или tar, или такой инструмент снимка файловой системы как dump. Если Вы копируете только определенные базы данных, копируйте только те файлы, которые касаются тех таблиц. Для InnoDB все таблицы во всех базах данных сохранены в файлах табличного пространства, если Вы не имеете включенной опции innodb_file_per_table.

Следующие файлы не требуются для репликации:

В зависимости от того, используете ли Вы InnoDB или нет, выберите одно из следующего:

Если Вы используете InnoDB, чтобы получить самые последовательные результаты со снимком необработанных данных, закрывайте главный сервер следующим образом:

  1. Приобретите блокировку чтения и получите состояние ведущего устройства. См. раздел 19.1.2.4.

  2. В отдельном сеансе закройте главный сервер:
    shell> mysqladmin shutdown
    
  3. Сделайте копию файлов с данными MySQL. Следующие примеры показывают распространенные способы сделать это. Вы должны выбрать только один из них:
    shell> tar cf /tmp/db.tar ./data
    shell> zip -r /tmp/db.zip ./data
    shell> rsync --recursive ./data /tmp/dbdata
    
  4. Перезапустите главный сервер.

Если Вы не используете InnoDB, Вы можете получить снимок системы от ведущего устройства, не закрывая сервер как описано в следующих шагах:

  1. Приобретите блокировку чтения и получите состояние ведущего устройства. См. раздел 19.1.2.4.

  2. Сделайте копию файлов с данными MySQL. Следующие примеры показывают распространенные способы сделать это. Вы должны выбрать только один из них:
    shell> tar cf /tmp/db.tar ./data
    shell> zip -r /tmp/db.zip ./data
    shell> rsync --recursive ./data /tmp/dbdata
    
  3. В клиенте, где Вы приобретали блокировку чтения, выпустите блокировку:
    mysql> UNLOCK TABLES;
    

Как только Вы создали архив или копию базы данных, скопируйте файлы к каждому ведомому устройству прежде, чем запустить ведомый процесс репликации.

19.1.2.6. Установка ведомых устройств репликации

Следующие разделы описывают, как настроить ведомые устройства. Прежде, чем Вы продолжите гарантируйте, что имеете:

Следующие шаги зависят от того, есть ли у Вас существующие данные, чтобы импортировать к ведомому устройству или нет. См. раздел 19.1.2.5 для получения дополнительной информации. Выберите одно из следующего:

19.1.2.6.1. Установка репликации с новыми ведущим и ведомым устройствами

Когда нет никакого снимка предыдущей базы данных, чтобы импортировать, сконфигурируйте ведомое устройство, чтобы запустить репликацию от нового ведущего устройства.

Настройте репликацию между ведущим и новым ведомым устройствами:

  1. Запустите ведомое устройство MySQL.

  2. Выполните CHANGE MASTER TO , чтобы установить основную конфигурацию сервера репликации. См. раздел 19.1.2.7.

Выполните эти шаги установки на каждом ведомом устройстве.

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

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

shell> mysql -h master < fulldb.dump
19.1.2.6.2. Установка репликации с существующими данными

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

Выберите одно из следующего:

Если Вы использовали mysqldump:

  1. Запустите ведомое устройство, используя опцию --skip-slave-start так, чтобы репликация не запустилась.

  2. Импортируйте файл дампа:
    shell> mysql < fulldb.dump
    

Если Вы создали снимок, используя файлы необработанных данных:

  1. Извлеките файлы с данными в свой ведомый каталог данных. Например:

    shell> tar xvf dbdump.tar
    

    Вы, возможно, должны установить разрешения и собственность на файлах так, чтобы ведомый сервер мог получить доступ и изменить их.

  2. Запустите ведомое устройство, используя опцию --skip-slave-start , чтобы репликация не запустилась.
  3. Сконфигурируйте ведомое устройство с координатами репликации от ведущего устройства. Это говорит ведомому устройству двоичный файл системного журнала и позицию в пределах файла, где репликация должна запуститься. Кроме того, сконфигурируйте ведомое устройство с параметрами входа в систему и именем хоста ведущего устройства. Для получения дополнительной информации о CHANGE MASTER TO см. раздел 19.1.2.7.
  4. Запустите ведомые потоки:
    mysql> START SLAVE;
    

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

Если Вы забыли установить опцию server-id для ведущего устройства, ведомые устройства не могут соединиться с этим.

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

Warning: You should set server-id to a non-0 value if master_host
is set; we will force server id to 2, but this MySQL server will
not act as a slave.

Вы также находите сообщения об ошибках в журнале ошибок ведомого устройства, если он не в состоянии копировать по какой-либо другой причине.

Ведомое устройство использует информацию в основном репозитарии информации, чтобы отследить то, сколько из двоичного журнала ведущего устройства это обработало. Репозитарий может быть в форме файлов или таблицы, как определено набором значений для --master-info-repository. Когда ведомое устройство работает с --master-info-repository=FILE, Вы можете найти в его каталоге данных два файла, названные master.info и relay-log.info. Если --master-info-repository=TABLE, эта информация сохранена в таблице master_slave_info базы данных mysql. Ни в коем случае не удаляйте или редактируйте файлы или таблицу, если Вы не знаете точно, что Вы делаете и полностью понимаете значения. Даже в этом случае лучше, если Вы используете CHANGE MASTER TO, чтобы изменить параметры репликации. Ведомое устройство может использовать значения, определенные в запросе, чтобы обновить файлы состояния автоматически. См. раздел 19.2.4.

Содержание основного репозитария информации переопределяет некоторые из параметров сервера, определенных в командной строке или в my.cnf. См. раздел 19.1.6.

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

19.1.2.7. Установка основной конфигурации на ведомом устройстве

Чтобы настроить ведомое устройство, чтобы общаться с ведущим устройством для репликации, сконфигурируйте ведомое устройство с необходимой информацией о соединении. Чтобы сделать это, выполните следующий запрос на ведомом устройстве, заменяя значения опции фактическими значениями, относящимися к Вашей системе:

mysql> CHANGE MASTER TO
    ->        MASTER_HOST='master_host_name',
    ->        MASTER_USER='replication_user_name',
    ->        MASTER_PASSWORD='replication_password',
    ->        MASTER_LOG_FILE='recorded_log_file_name',
    ->        MASTER_LOG_POS=recorded_log_position;

Репликация не может использовать файлы сокета Unix. Вы должны быть в состоянии соединиться с сервером ведущего устройства MySQL по TCP/IP.

CHANGE MASTER TO имеет также и другие опции. Например, возможно настроить безопасную репликацию, используя SSL. Для полного списка опций и информации о максимальной допустимой длине для строк см. раздел 14.4.2.1.

19.1.2.8. Добавление ведомых устройств окружающей среды репликации

Вы можете добавить другое ведомое устройство существующей конфигурации репликации, не останавливая ведущее устройство. Вместо этого настройте новое ведомое устройство, делая копию существующего ведомого устройства, за исключением того, что Вы конфигурируете новое ведомое устройство с отличным server-id.

Дублировать существующее ведомое устройство:

  1. Закройте существующее ведомое устройство:

    shell> mysqladmin shutdown
    
  2. Скопируйте каталог данных от существующего ведомого устройства на новое ведомое устройство. Вы можете сделать это, создавая архив, используя tar или WinZip, или выполняя прямую копию, используя такой инструмент, как cp или rsync. Гарантируйте, что Вы также копируете файлы системного журнала реле и файлы системного журнала.

    Типичная проблема, с которой сталкиваются, когда добавляют новые ведомые устройства репликации состоит в том, что новое ведомое устройство терпит неудачу с рядом предупреждающих сообщений и сообщений об ошибках:

    071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
    replication may break when this MySQL server acts as a slave and has his hostname
    changed! Please use '--relay-log=new_slave_hostname-relay-bin'
    to avoid this problem.
    071118 16:44:10 [ERROR] Failed to open the relay log
    './old_slave_hostname-relay-bin.003525'
    (relay_log_pos 22940879)
    071118 16:44:10 [ERROR] Could not find target log during relay log initialization
    071118 16:44:10 [ERROR] Failed to initialize the master info structure
    

    Эта ситуация может произойти, если опция --relay-log не определена, поскольку файлы системного журнала реле содержат имя хоста как часть их имен файла. Это также верно для индексного файла журнала реле, если не используется опция --relay-log-index, см. раздел 19.1.6.

    Чтобы избежать этой проблемы, используйте то же самое значение для --relay-log на новом ведомом устройстве, которое использовалось на существующем ведомом устройстве. Если эта опция не была установлена явно на существующем ведомом устройстве, надо использовать existing_slave_hostname-relay-bin. Если это невозможно, скопируйте индексный файл реле существующего ведомого устройства к новому ведомому устройству и установите опцию --relay-log-index на новом ведомом устройстве, чтобы соответствовать значению, что использовалось на существующем ведомом устройстве. Если эта опция не была установлена явно на существующем ведомом устройстве, надо использовать existing_slave_hostname-relay-bin.index. Альтернативно, если Вы уже попытались запустить новое ведомое устройство и столкнулись с ошибками, как описанные ранее, то выполните следующие шаги:

    1. Если Вы еще этого не сделали, выполните STOP SLAVE на новом ведомом устройстве.

      Если Вы уже запустили существующее ведомое устройство снова, выполните STOP SLAVE на существующем ведомом устройстве также.

    2. Скопируйте содержание индексного файла журнала реле существующего ведомого устройства в индексный файл журнала реле нового ведомого устройства, перезаписывая любой контент в файле.
    3. Возобновите остающиеся шаги в этом разделе.

  3. Скопируйте основную информацию и репозитарии информации журнала реле (см. раздел 19.2.4) от существующего ведомого устройства на новое ведомое устройство. Они содержат текущие координаты журнала для двоичного журнала ведущего устройства и журнала реле ведомого устройства.
  4. Запустите существующее ведомое устройство.
  5. На новом ведомом устройстве отредактируйте конфигурацию и дайте новому ведомому устройству уникальный server-id не используемый ведущим устройством или любым из существующих ведомых устройств.
  6. Запустите новое ведомое устройство. Ведомое устройство использует информацию в своем основном репозитарии информации, чтобы запустить процесс репликации.

19.1.3. Репликация с глобальными операционными идентификаторами

Этот раздел объясняет основанную на транзакции репликацию, используя global transaction identifiers (GTID). Используя GTID, каждая транзакция может быть идентифицирована и прослежена, поскольку это передано на сервере и применено любыми ведомыми устройствами, это означает, что не надо, используя GTID, обращаться к файлам системного журнала или позициям в пределах тех файлов, запуская новое ведомое устройство, что очень упрощает эти задачи. Поскольку GTID-репликация основана на транзакции, просто определить, последовательны ли ведущие устройства и ведомые устройства: пока все транзакции, переданные на ведущем устройстве, также переданы на ведомом устройстве, последовательность между этими двумя гарантируется. Вы можете использовать основанную на запросе или на строке репликацию с GTID (см. раздел 19.2.1), однако, для лучших результатов, мы рекомендуем, чтобы Вы использовали основанный на строке формат.

Этот раздел обсуждает следующие темы:

Для информации о параметрах сервера MySQL и переменных, касающихся GTID, см. раздел 19.1.6.5. См. также раздел 13.17, который описывает функции SQL, поддержанные MySQL 8.0 для использования с GTID.

19.1.3.1. Понятия GTID

Глобальный операционный идентификатор (GTID) является уникальным идентификатором, создаваемым и связанным с каждой транзакцией, переданной на сервере происхождения (ведущее устройство). Этот идентификатор уникален не только для сервера, на котором он произошел, но и уникален через все серверы в данной установке репликации. Есть 1 к 1 отображение между всеми транзакциями и всеми GTID.

Следующие параграфы обеспечивают основное описание GTID:

GTID представлен как пара координат, отделенных символом двоеточия (:), примерно в таком виде:

GTID = source_id:transaction_id

source_id идентифицирует происходящий сервер. Обычно применяется server_uuid сервера. transaction_id порядковый номер, определенный порядком, в котором транзакция была передана на этом сервере, например, первая транзакция, которая будет передана, имеет 1 как ее transaction_id, десятой транзакции, которая будет передана на том же самом сервере возникновения, назначается transaction_id = 10. Для транзакции невозможно иметь 0 как порядковый номер в GTID. Например, двадцать третья транзакция, которая будет передана на сервере с UUID 3E11FA47-71CA-11E1-9E33-C80AA9429562 имеет такой GTID:

3E11FA47-71CA-11E1-9E33-C80AA9429562:23

Этот формат используется, чтобы представить GTID в выводе запросов SHOW SLAVE STATUS так же, как в двоичном журнале. Они могут также быть замечены, рассматривая файл системного журнала с mysqlbinlog --base64-output=DECODE-ROWS или в выводе SHOW BINLOG EVENTS.

Как написано в выводе запросов SHOW MASTER STATUS или SHOW SLAVE STATUS, последовательность GTID, происходящяя из того же самого сервера, может быть свернута в единственное выражение, как показано здесь.

3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5

Этот пример представляет с первой по пятую транзакции, происходящие на MySQL Server с server_uuid 3E11FA47-71CA-11E1-9E33-C80AA9429562.

Этот формат также используется, чтобы поставлять параметр, требуемый опциями START SLAVE SQL_BEFORE_GTIDS и SQL_AFTER_GTIDS.

Наборы GTID

Набор GTID это множество глобальных операционных идентификаторов, которое представлен как показано здесь:

gtid_set:
uuid_set [, uuid_set] ...
| ''

uuid_set:
uuid:interval[:interval]...

uuid:
hhhhhhhh-hhhh-hhhh-hhhh-hhhhhhhhhhhh
h:
[0-9|A-F]

interval:
n[-n]
(n >= 1)

Наборы GTID используются в MySQL Server несколькими способами. Например, значения, сохраненные в переменных gtid_executed и gtid_purged представлены как наборы GTID. Кроме того, функции GTID_SUBSET() и GTID_SUBTRACT() требуют наборов GTID как входных данных. Когда наборы GTID возвращены из переменных сервера, UUID в алфавитном порядке и числовые интервалы слиты в порядке возрастания.

GTID всегда сохраняются между ведущим устройством и ведомым устройством. Это означает, что Вы можете всегда определять источник для любой транзакции, примененной на любое ведомое устройство, исследуя его двоичной журнал. Кроме того, как только транзакция с данным GTID передана на данном сервере, любая последующая транзакция, имеющая тот же самый GTID, проигнорирована тем сервером. Таким образом, транзакция, переданная на ведущем устройстве, может быть применена не больше, чем однажды на ведомом устройстве, что помогает гарантировать последовательность.

Когда GTID используются, у ведомого устройства нет никакой потребности в любых нелокальных данных, таких как название файла на ведущем устройстве и позиции в пределах того файла. Вся необходимая информация для того, чтобы синхронизировать с ведущим устройством получена непосредственно из потока данных репликации. GTID заменяют смещение в файле. Поэтому не надо включать опции MASTER_LOG_FILE или MASTER_LOG_POS в CHANGE MASTER TO и направлять ведомое устройство, чтобы копировать от данного ведущего устройства, вместо этого необходимо только включить опцию MASTER_AUTO_POSITION. Для точных шагов, чтобы сконфигурировать и запустить ведущие и ведомые устройства, используя GTID см. раздел 19.1.3.2.

Генерация и жизненный цикл GTID состоят из следующих шагов:

  1. Транзакция выполнена и передана на ведущем устройстве.

    Этой транзакции назначают GTID с использованием UUID ведущего устройства и самого маленького операционного порядкового номера, отличного от нуля, используемого на этом сервере, GTID написан в двоичный журнал ведущего устройства (немедленно перед транзакцией непосредственно в журнале).

  2. После того, как двоичные данные о журнале переданы к ведомому устройству и хранятся в журнале реле ведомого устройства (используя установленные механизмы для этого, см. раздел 19.2), ведомое устройство читает GTID и устанавливает значение gtid_next в этот GTID. Это говорит ведомому устройству, что следующая транзакция должна быть зарегистрирована, используя этот GTID.

    Важно отметить, что ведомое устройство устанавливает gtid_next в контексте сеанса.

  3. Ведомое устройство проверяет, что этот GTID не использовался, чтобы зарегистрировать транзакцию в собственном двоичном журнале. Если этот GTID не использовался, ведомое устройство пишет GTID, применяет транзакцию и пишет транзакцию в свой двоичный журнал. Читая и проверяя GTID транзакции сначала, прежде, чем обработать транзакцию непосредственно, ведомое устройство гарантирует не только, что никакая предыдущая транзакция, имеющая этот GTID, не была применена на ведомом устройстве, но также и что никакой другой сеанс, который уже считал этот GTID, еще не передал связанную транзакцию. Другими словами, многим клиентам не разрешают применить ту же самую транзакцию одновременно.
  4. Так как gtid_next не пусто, ведомое устройство не пытается произвести GTID для этой транзакции, но вместо этого пишет GTID, сохраненный в этой переменной, то есть, GTID, полученный из ведущего немедленно перед транзакцией в двоичном журнале.

Таблица mysql.gtid_executed

GTID сохранены в таблице gtid_executed базы данных mysql. Строка в этой таблице содержит для каждого GTID или набора GTID, который это представляет, UUID сервера происхождения, ID первой и последней транзакции набора, для строки, ссылающейся только на единственный GTID, эти последние два значения то же самое.

Таблица mysql.gtid_executed составлена (если она не существует), когда MySQL Server установлен или обновлен, используя CREATE TABLE подобно этому:

CREATE TABLE gtid_executed (source_uuid CHAR(36) NOT NULL,
                            interval_start BIGINT(20) NOT NULL,
                            interval_end BIGINT(20) NOT NULL,
                            PRIMARY KEY (source_uuid, interval_start))

Как с другими системными таблицами MySQL, не пытайтесь создать или изменить эту таблицу самостоятельно.

GTID сохранены в mysql.gtid_executed только, когда gtid_mode=ON, и не сохранены, когда gtid_mode имеет некоторое другое значение. GTID сохранены в этой таблице без отношения к тому, включено ли двоичное журналирование. Однако, манера, в которой они сохранены, отличается в зависимости от того log_bin ON или OFF:

Таблица mysql.gtid_executed сброшена RESET MASTER.

Табличное сжатие mysql.gtid_executed

Со временем таблица mysql.gtid_executed может стать заполненной многими строками, обращающимися к отдельным GTID, которые происходят на том же самом сервере, и чьи операционные ID составляют последовательность, подобную тому, что показывают здесь:

mysql> SELECT * FROM mysql.gtid_executed;
+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
|--------------------------------------+----------------+--------------|
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37             | 37           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 38             | 38           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 39             | 39           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 40             | 40           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 41             | 41           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 42             | 42           |
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 43             | 43           |
...

Значительное свободное место может быть оставлено, если эта таблица периодически сжимается, заменяя каждый такой набор строк единственной строкой, которая охватывает весь интервал операционных идентификаторов:

+--------------------------------------+----------------+--------------+
| source_uuid                          | interval_start | interval_end |
|--------------------------------------+----------------+--------------|
| 3E11FA47-71CA-11E1-9E33-C80AA9429562 | 37             | 43           |
...

Когда GTID включены, сервер выполняет этот тип сжатия на mysql.gtid_executed периодически. Вы можете управлять числом транзакций, которым позволяют пройти прежде, чем таблица будет сжата, и таким образом уровнем сжатия, устанавливая переменную executed_gtids_compression_period. Значение по умолчанию этой переменной 1000 это означает, что, по умолчанию, сжатие таблицы выполнено после каждой 1000 транзакции. Установка executed_gtid_compression_period в 0 препятствует тому, чтобы сжатие было выполнено вообще, однако, Вы должны быть подготовлены к потенциально значительному увеличению количества дискового пространства, которое может требоваться gtid_executed.

Когда двоичное журналирование включено, значение executed_gtids_compression_period не используется и mysql.gtid_executed сжата на каждой ротации двоичного журнала.

Сжатие mysql.gtid_executed выполнено специализированным потоком переднего плана, который создается всякий раз, когда GTID включены на сервере. Этот поток не перечислен в выводе SHOW PROCESSLIST, но это может быть рассмотрено как строка в таблице threads:

mysql> SELECT * FROM PERFORMANCE_SCHEMA.THREADS WHERE NAME LIKE '%gtid%'\G
*************************** 1. row ***************************
THREAD_ID: 21
 NAME: thread/sql/compress_gtid_table
 TYPE: FOREGROUND
 PROCESSLIST_ID: 139635685943104
 PROCESSLIST_USER: NULL
 PROCESSLIST_HOST: NULL
 PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: Daemon
 PROCESSLIST_TIME: 611
PROCESSLIST_STATE: Suspending
 PROCESSLIST_INFO: NULL
 PARENT_THREAD_ID: 1
 ROLE: NULL
 INSTRUMENTED: YES

У этого потока есть имя thread/sql/compress_gtid_table и он обычно спит до выполнения executed_gtids_compression_period транзакций, затем просыпается, чтобы выполнить сжатие таблицы mysql.gtid_executed. Установка executed_gtids_compression_period = 0, когда двоичное журналирование отключено устанавливает, что поток всегда спит и никогда не просыпается.

19.1.3.2. Настройка репликации, используя GTID

Этот раздел описывает процесс для конфигурирования и запуска GTID-репликации в MySQL 8.0. Это процедура, которая предполагает, что Вы запускаете ведущее устройство репликации впервые, или что возможно его остановить, для информации об обеспечивании ведомых устройств репликации, используя GTID от рабочего ведущего устройства, см. раздел 19.1.3.3.

Ключевые шаги в этом процессе запуска для самой простой репликации GTID из одного ведущего устройства и одного ведомого следующие:

  1. Если репликация уже работает, синхронизируйте оба сервера, делая их только для чтения.

  2. Остановите оба сервера.
  3. Перезапустите оба сервера с включенным GTID и правильно сконфигурированными опциями.

    Опции mysqld , необходимые, чтобы запустить серверы как описано, обсуждены в примере, который следует позже в этом разделе.

    server_uuid должен существовать для GTID, чтобы функционировать правильно.

  4. Проинструктируйте ведомое устройство использовать ведущее устройство в качестве хранилища данных репликации и использовать авторасположение, затем запустите ведомое устройство.

    Запросы SQL, чтобы достичь этого шага, описаны в примере, который следует позже в этом разделе.

  5. Включите режим чтения снова на обоих серверах, так, чтобы они могли принять обновления.

В следующем примере уже работают два сервера, ведущее устройство и ведомое, используя двоичный журнал и основанный на позиции протокол репликации. Если Вы запускаете с новых серверов, см. разделы 19.1.2.3 и 19.1.2.1. Следующие примеры показывают, как использовать опции, запуская mysqld. Альтернативно Вы можете сохранить опции запуска в файле опции, см. раздел 5.2.6.

Большинство шагов требуют использования MySQL root или другой учетной записи пользователя MySQL, которая имеет привилегию SUPER. mysqladmin shutdown требует привилегию SUPER или SHUTDOWN.

Шаг 1: Синхронизируйте серверы. Сделайте серверы только для чтения. Чтобы сделать это, включите read_only на обоих серверах:

mysql> SET @@global.read_only = ON;

Позвольте ведомому устройству догонять ведущее устройство. Чрезвычайно важно, чтобы Вы удостоверились, что ведомое устройство обработало все обновления перед продолжением.

Шаг 2: Остановите оба сервера. Остановите каждый сервер, используя mysqladmin, где username это имя пользователя MySQL, имеющего достаточные привилегии, чтобы закрыть сервер:

shell> mysqladmin -u username -p shutdown

Шаг 3: Перезапустите оба сервера с включенным GTID. Чтобы включить GTID-репликацию, каждый сервер должен быть запущен с включенным режимом GTID, устанавливая опцию --gtid-mode в ON и с включенной опцией --enforce-gtid-consistency, чтобы гарантировать, что только запросы, которые безопасны для репликации GTID, зарегистрированы. Кроме того, Вы должны запустить ведомое устройство с опцией --skip-slave-start прежде, чем сконфигурировать ведомые настройки. Для получения дополнительной информации о связанных опциях GTID см. раздел 19.1.6.5.

Необязательно, чтобы использовать GTID, включать двоичное журналирование, используя таблицу mysql.gtid_executed. Это означает, что у Вас могут быть ведомые серверы, используя GTID, но без двоичного журналирования. Ведущим устройствам нужно всегда включать двоичное журналирование, чтобы быть в состоянии копировать. Например, чтобы запустить ведомое устройство с включенным GTID, но без двоичного журналирования, используйте, по крайней мере, эти опции:

shell> mysqld --gtid_mode=ON --enforce-gtid-consistency &

В зависимости от Вашей конфигурации, поставляйте дополнительные опции mysqld.

Шаг 4: Направьте ведомое устройство, чтобы использовать ведущее устройство. Скажите ведомому устройству использовать ведущее устройство в качестве хранилища данных репликации и использовать GTID авторасположение, а не основанное на файле расположение. Выполните CHANGE MASTER TO на ведомом устройстве, используя опцию MASTER_AUTO_POSITION, чтобы сказать ведомому устройству, что транзакции будут идентифицированы GTID.

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

mysql> CHANGE MASTER TO
     >        MASTER_HOST = host,
     >        MASTER_PORT = port,
     >        MASTER_USER = user,
     >        MASTER_PASSWORD = password,
     >        MASTER_AUTO_POSITION = 1;

Ни одна опция MASTER_LOG_FILE и MASTER_LOG_POS не может использоваться с MASTER_AUTO_POSITION равной 1. Попытка сделать так вызовет ошибку в CHANGE MASTER TO .

Если запрос CHANGE MASTER TO преуспел, Вы можете тогда запустить ведомое устройство:

mysql> START SLAVE;

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

mysql> SET @@global.read_only = OFF;

GTID-репликация должна теперь работать, и Вы можете начать деятельность по ведущему устройству как прежде.

19.1.3.3. Использование GTID для Failover и Scaleout

Есть много методов, использования MySQL Replication с Global Transaction Identifiers (GTID) для того, чтобы обеспечить новое ведомое устройство, которое может тогда использоваться для scaleout, будучи продвинутым на ведущее устройство по мере необходимости.

Глобальные операционные идентификаторы были добавлены к репликации MySQL с целью упрощения в общем менеджменте потока данных репликации. Каждый идентификатор уникально идентифицирует ряд двоичных событий журнала, которые вместе составляют транзакцию. GTID играют ключевую роль в применении изменений базы данных: сервер автоматически пропускает любую транзакцию, имеющую идентификатор, который сервер признает тем, что обработал прежде. Это поведение важно для автоматического расположения репликации.

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

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

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

Этот метод прост и эффективен, но требует, чтобы ведомое устройство считало двоичной журнал от ведущего устройства, может иногда требоваться сравнительно много времени для нового ведомого устройства, чтобы догнать ведущее устройство, таким образом, этот метод не является подходящим для быстрого восстанавливающий из резервного копирования. Этот раздел объясняет, как избежать приносить всю историю выполнения от ведущего устройства, копируя двоичные файлы системного журнала к новому серверу.

Копирование данных и транзакций к ведомому устройству. Воспроизведение всей операционной истории может быть отнимающим много времени, и представляет главное узкое место, настраивая новое ведомое устройство репликации. Чтобы устранить это требование, снимок набора данных, двоичных журналов и глобальной информации о транзакции, которую содержит ведущее устройство, должен быть импортирован в ведомое устройство. Двоичный журнал воспроизведен, после чего репликация может быть запущена, позволяя ведомому устройству стать актуальным с любыми остающимися транзакциями.

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

Набор данных История транзакций
  • Используйте mysql , чтобы импортировать файл дампа, создаваемый mysqldump. Используйте опцию --master-data, чтобы включить двоичную информацию о журналировании и установите --set-gtid-purged в AUTO (значение по умолчанию) или ON, чтобы включить информацию о выполненных транзакциях. Вы должны иметь --gtid-mode=ON, импортируя дамп на ведомом устройстве.

  • Остановите ведомое устройство, скопируйте содержание каталога данных ведущего устройства к каталогу данных ведомого устройства, затем перезапустите ведомое устройство.

Если gtid_mode не ON, перезапустите сервер с включенным режимом GTID.

  • Импортируйте двоичной журнал, используя mysqlbinlog с --read-from-remote-server и --read-from-remote-master.

  • Скопируйте двоичные файлы системного журнала ведущего устройства к ведомому устройству. Вы можете сделать копии с ведомого устройства, используя mysqlbinlog --read-from-remote-server --raw. Они могут быть считаны в ведомое устройство любым из следующих способов:

    • Обновите файл binlog.index ведомого устройства, чтобы указать на скопированные файлы системного журнала. Тогда выполните CHANGE MASTER TO в mysql, чтобы указать на первый файл системного журнала, и START SLAVE, чтобы считать их.

    • Используйте mysqlbinlog > file (без опции --raw), чтобы экспортировать двоичные файлы системного журнала в файлы SQL, которые могут быть обработаны mysql .

См. раздел 5.6.8.3.

У этого метода есть преимущество, что новый сервер доступен почти немедленно, только те транзакции, которые были переданы, в то время как файл снимка или дампа переигрывался, все еще будут получены от существующего ведущего устройства. Это означает, что доступность ведомого устройства не мгновенна, но только относительно короткий срок должен требоваться для ведомого устройства, чтобы догнать эти немного остающихся транзакций.

Копирование по двоичным журналам к целевому серверу заранее обычно быстрее, чем чтение всей операционной истории выполнения от ведущего устройства в режиме реального времени. Однако, возможно, не всегда выполнимо переместить эти файлы, когда требуется из-за размера или других соображений. Два остающихся метода для того, чтобы обеспечить новое ведомое устройство, обсуждаемые в этом разделе, используют другие средства, чтобы передать информацию о транзакциях к новому ведомому устройству.

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

SET GTID_NEXT='aaa-bbb-ccc-ddd:N';
BEGIN;
COMMIT;
SET GTID_NEXT='AUTOMATIC';

Как только все операционные идентификаторы были восстановлены таким образом, используя пустые транзакции, Вы должны сбросить и произвести чистку двоичных журналов ведомого устройства, как показано здесь, где N суффикс отличный от нуля текущего имени двоичного файла системного журнала:

FLUSH LOGS;
PURGE BINARY LOGS TO 'master-bin.00000N';

Вы должны сделать это, чтобы препятствовать тому, чтобы этот сервер затопил поток репликации ложными транзакциями, когда это позже будет продвинуто на ведущее устройство. FLUSH LOGS вызывает создание нового двоичного файла системного журнала, PURGE BINARY LOGS производит чистку пустых транзакций, но сохраняет их идентификаторы.

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

Исключая транзакции с gtid_purged. Глобальная переменная gtid_purged ведущего устройства содержит набор всех транзакций, которые были вычищены из двоичного журнала ведущего устройства. Как с методом, обсужденным ранее, Вы можете сделать запись значения gtid_executed на сервере, от которого снимок был взят (вместо копирования двоичных журналов к новому серверу). В отличие от предыдущего метода, нет никакой потребности передать пустые транзакции (или выполнить PURGE BINARY LOGS), вместо этого Вы можете установить gtid_purged на ведомом устройстве непосредственно, основываясь на значении gtid_executed сервера, от которого были взяты резервные копии или снимок.

Как с методом пустых транзакций, этот метод создает сервер, который является функционально снимком, но в состоянии стать ведущим устройством, поскольку его двоичная история журнала сходится с историей из ведущего устройства репликации или группы.

Восстановление ведомых устройств режима GTID. Когда восстановление ведомого устройства в GTID-репликации сталкивается с ошибкой, ввод пустой транзакции, возможно, не решает проблему, потому что у события нет GTID.

Используйте mysqlbinlog , чтобы найти следующую транзакцию, которая является, вероятно, первой транзакцией в следующем файле системного журнала после события. Скопируйте все до COMMIT для той транзакции, чтобы включить SET @@SESSION.GTID_NEXT. Даже если Вы не используете основанную на строке репликацию, Вы можете все еще выполнить двоичные события строки журнала в клиенте командной строки.

Остановите ведомое устройство и выполните транзакцию, которую Вы скопировали. mysqlbinlog выводит разделитель наборов как /*!*/;:

mysql> DELIMITER ;

Перезапустите репликацию от правильной позиции автоматически:

mysql> SET GTID_NEXT=automatic;
mysql> RESET SLAVE;
mysql> START SLAVE;

19.1.3.4. Ограничения на репликацию с GTID

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

Обновления, вовлекающие нетранзакционные механизмы хранения. Используя GTID, обновления таблиц, использующие нетранзакционные механизмы хранения, например, MyISAM , не могут быть сделаны в том же самом запросе или транзакции как обновления таблиц, использующих транзакционные механизмы хранения, например, InnoDB.

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

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

В любом из таких случаев непосредственная связь между транзакциями и GTID сломана, так что в итоге GTID-репликация не может функционировать правильно.

CREATE TABLE ... SELECT. CREATE TABLE ... SELECT не безопасны для основанной на запросе репликации. Используя основанную на строке репликацию, этот запрос фактически зарегистрирован как два отдельных события: одно для создания таблицы и другое для вставки строк от исходной таблицы в новую таблицу. Когда этот запрос выполнен в пределах транзакции, для этих двух событий возможно в некоторых случаях получить тот же самый операционный идентификатор, что означает, что транзакция, содержащая вставки, пропущена ведомым устройством. Поэтому CREATE TABLE ... SELECT не поддержан, используя GTID-репликацию.

Временные таблицы. CREATE TEMPORARY TABLE и DROP TEMPORARY TABLE не поддержаны в транзакциях, используя GTID (то есть, когда сервер был запущен с опцией --enforce-gtid-consistency). Возможно использовать эти запросы с включенным GTID, но только за пределами любой транзакции и только с autocommit=1.

Предотвращение выполнения неподдержанных запросов. Чтобы предотвратить выполнение запросов, которые заставили бы GTID-репликацию терпеть неудачу, все серверы должны быть запущены с опцией --enforce-gtid-consistency, включая GTID. Это заставляет запросы любого из типов, обсужденных ранее в этом разделе терпеть неудачу с ошибкой.

См. раздел 19.1.3.2.

sql_slave_skip_counter не поддержана, используя GTID. Если Вы должны пропустить транзакции, используйте значение gtid_executed от ведущего устройства.

Режим GTID и mysqldump. Возможно импортировать дамп из mysqldump в MySQL Server работающий с включенным режимом GTID, при условии, что нет никаких GTID в двоичном журнале целевого сервера.

Режим GTID и mysql_upgrade. Возможно, но не рекомендуется использовать mysql_upgrade на MySQL Server с --gtid-mode=ON , так как mysql_upgrade может произвести изменения в системных таблицах, которые используют MyISAM, который является нетранзакционным.

19.1.4. Репликация с нескольких источников

Это позволяет Вам копировать от многократных ведущих устройств параллельно.

19.1.4.1. Обзор репликации с нескольких источников

Репликация с нескольких источников позволяет ведомому устройству репликации получить транзакции от многократных источников одновременно. Это может использоваться, чтобы зарезервировать многократные серверы на единственный сервер, слить таблицы и объединить данные от многократных серверов на единственном сервере. Это не осуществляет обнаружения конфликта, применяя транзакции, и оставляет эту задачу приложению, если надо. В мультиисходной топологии репликации ведомое устройство создает канал репликации для каждого ведущего устройства, из которого оно должно получить транзакции. См. раздел 19.2.3.

19.1.4.2. Введение в репликацию с нескольких источников

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

19.1.4.2.1. Конфигурирование мультирепликации

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

Ведущие устройства в мультиисходной топологии репликации могут быть сконфигурированы, чтобы использовать глобальный операционный идентификатор (GTID) или основанную на позиции репликацию. См. разделы 19.1.3.2 и 19.1.2.1.

Ведомые устройства в мультиисходной топологии репликации требуют репозитариев TABLE. Мультирепликация несовместима с репозитариями FILE. Тип репозитария, используемого mysqld, может быть сконфигурирован при запуске или динамически.

Чтобы сконфигурировать тип репозитария, используемого ведомым устройством репликации при запуске, запустите mysqld со следующими опциями:

--master-info-repository=TABLE --relay-log-info-repository=TABLE

Чтобы изменить существующее ведомое устройство репликации, которое использует репозитарий FILE на TABLE, преобразуйте существующие репозитарии репликации динамически, выполняя следующие команды:

STOP SLAVE;
SET GLOBAL master_info_repository = 'TABLE';
SET GLOBAL relay_log_info_repository = 'TABLE';
19.1.4.2.2. Добавление GTID-ведущего устройства к ведомому устройству репликации

Этот раздел предполагает, что Вы включили GTID на ведущем устройстве с использованием gtid_mode=ON, включили пользователя репликации и обеспечили, что ведомое устройство использует репозитарии TABLE. Используйте CHANGE MASTER TO , чтобы добавить новое ведущее устройство к каналу при использовании FOR CHANNEL channel. См. раздел 19.2.3.

Например, чтобы добавить новое ведущее устройство с именем хоста master1 и портом 3451 к каналу master-1:

CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='rpl', \
       MASTER_PORT=3451, MASTER_PASSWORD='', \
       MASTER_AUTO_POSITION = 1 FOR CHANNEL 'master-1';

Мультирепликация совместима с авторасположением. См. раздел 14.4.2.1.

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

19.1.4.2.3. Добавление двоичного журнала ведущего устройства к ведомому устройству мультирепликации

Этот раздел предполагает, что Вы включили двоичное журналирование с использованием --log-bin , включая пользователя репликации, текущую позицию регистрации и обеспечили, что ведомое устройство использует репозитарии TABLE. Вы должны знать текущие MASTER_LOG_FILE и MASTER_LOG_POSITION. Используйте CHANGE MASTER TO, чтобы добавить новое ведущее устройство к каналу, определяя FOR CHANNEL channel. Например, чтобы добавить новое ведущее устройство с именем хоста master1 и портом 3451 к каналу master-1:

CHANGE MASTER TO MASTER_HOST='master1', MASTER_USER='rpl', MASTER_PORT=3451, \
       MASTER_PASSWORD='' MASTER_LOG_FILE='master1-bin.000006', \
       MASTER_LOG_POS=628 FOR CHANNEL 'master-1';

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

19.1.4.2.4. Запуск ведомых устройств мультирепликации

Как только Вы добавили все каналы, которые Вы хотите использовать в качестве ведущих устройств репликации, надо использовать START SLAVE thread_types, чтобы запустить репликацию. Когда Вы включили многократным каналы на ведомом устройстве, Вы можете хотеть запускать все каналы или выбирать определенный канал, чтобы запустить.

Используйте опцию thread_types, чтобы выбрать определенные потоки, которые Вы хотите запустить на ведомом устройстве. См. раздел 14.4.2.6.

19.1.4.2.5. Остановка ведомых устройств мультирепликации

STOP SLAVE может использоваться, чтобы остановить ведомое устройство репликации. По умолчанию, если Вы используете STOP SLAVE на ведомом устройстве мультирепликации, все каналы остановлены. Произвольно используйте FOR CHANNEL channel, чтобы остановить только определенный канал.

Используйте опцию thread_types, чтобы выбрать определенные потоки, которые Вы хотите остановилить на ведомом устройстве. См. раздел 14.4.2.7.

19.1.4.2.6. Сброс ведомых устройств мультирепликации

RESET SLAVE может использоваться, чтобы сбросить ведомое устройство репликации. По умолчанию, если Вы используете RESET SLAVE на ведомом устройстве репликации, все каналы сброшены. Произвольно, используйте FOR CHANNEL channel , чтобы сбросить только определенный канал.

См. раздел 14.4.2.4.

19.1.4.3. Контроль за мультирепликацией

Чтобы контролировать состояние репликации есть варианты:

SHOW VARIABLES не работает с многократными каналами репликации. Информация, которая была доступна через эти переменные, мигрировала в таблицы репликации. Использование SHOW VARIABLES в топологии с многократными каналами показывает состояние только канала по умолчанию.

19.1.4.3.1. Контроль каналов, используя таблицы Performance Schema

Этот раздел объясняет, как использовать таблицы Performance Schema репликации, чтобы контролировать каналы. Вы можете хотеть контролировать все каналы или некое подмножество каналов.

Чтобы контролировать состояние соединения всех каналов:

mysql> SELECT * FROM replication_connection_status\G;
*************************** 1. row ***************************
CHANNEL_NAME: master1
GROUP_NAME:
SOURCE_UUID: 046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID: 24
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 046e41f8-a223-11e4-a975-0811960cc264:4-37
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
*************************** 2. row ***************************
CHANNEL_NAME: master2
GROUP_NAME:
SOURCE_UUID: 7475e474-a223-11e4-a978-0811960cc264
THREAD_ID: 26
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 7475e474-a223-11e4-a978-0811960cc264:4-6
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
2 rows in set (0.00 sec)

В вышеупомянутом выводе есть два активных канала и как показано полем CHANNEL_NAME их называют master1 и master2 .

Добавление поля CHANNEL_NAME позволяет Вам запросить таблицы Performance Schema для определенного канала. Чтобы контролировать состояние соединения названного канала, используйте WHERE channel_name= channel:

mysql> SELECT * FROM replication_connection_status
                   WHERE channel_name='master1'\G
*************************** 1. row ***************************
CHANNEL_NAME: master1
GROUP_NAME:
SOURCE_UUID: 046e41f8-a223-11e4-a975-0811960cc264
THREAD_ID: 24
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 046e41f8-a223-11e4-a975-0811960cc264:4-37
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
1 row in set (0.00 sec)

Точно так же WHERE channel_name=channel может использоваться, чтобы контролировать другие таблицы Performance Schema репликации для определенного канала. Для получения дополнительной информации см. раздел 23.9.11 .

19.1.4.4. Сообщения об ошибках мультирепликации

Коды ошибки и сообщения предоставляют информацию об ошибках, с которыми сталкиваются в топологии репликации. Эти коды ошибки и сообщения появляются только, когда мультирепликация включена и предоставляют информацию, связанную с каналом, который произвел ошибку. Например:

Slave is already running и Slave is already stopped были заменены Replication thread(s) for channel channel_name are already running и Replication threads(s) for channel channel_name are already stopped соответственно.

Сообщения журнала сервера были также изменены, чтобы указать, которые каналы направляют сообщения журнала. Это делает отладку и рассмотрение легче.

19.1.5. Изменение режимов репликации на серверах онлайн

Этот раздел описывает, как изменить режим репликации, не имея необходимости останавливать сервер.

19.1.5.1. Понятия режима репликации

Чтобы быть в состоянии безопасно сконфигурировать режим репликации сервера онлайн, важно понять некоторое ключевое понятие репликации. Этот раздел объясняет эти понятия и является существенным прежде, чем попытаться изменить режим репликации сервера онлайн.

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

Используя GTID, Вы можете использовать в своих интересах авторасположение как использование WAIT_FOR_EXECUTED_GTID_SET(), session_track_gtids и отслеживать копирование транзакций через Performance Schema. С GTID не может использоваться sql_slave_skip_counter, вместо этого используйте пустые транзакции.

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

Способность сконфигурировать режим репликации онлайн означает, что переменные gtid_mode и enforce_gtid_consistency являются теперь динамическими и могут быть установлены из высокоуровневого запроса. В MySQL 5.6 и ниже обе эти переменные могли быть сконфигурированы только используя соответствующую опцию при запуске сервера. То есть, изменения режима репликации требовали перезапуска сервера. Во всех версиях gtid_mode может быть установлена в ON или OFF, что соответствует тому, использовались ли GTID, чтобы идентифицировать транзакции или нет. Когда gtid_mode=ON невозможно копировать анонимные транзакции, а когда gtid_mode=OFF только анонимные транзакции могут копироваться. Когда gtid_mode=OFF_PERMISSIVE , новые транзакции являются анонимными, в то время как разрешается копировать GTID или анонимные транзакции. Когда gtid_mode=ON_PERMISSIVE , новые транзакции используют GTID, в то время как разрешается копировать GTID или анонимные транзакции. Это означает, что возможно иметь топологию репликации, у которой есть серверы, использующие анонимные транзакции и GTID. Например, ведущее устройство с gtid_mode=ON может копировать к ведомому устройству с gtid_mode=ON_PERMISSIVE . Допустимые значения для gtid_mode следующие и в этом порядке:

Важно отметить что статус gtid_mode может быть изменен только на один шаг за один раз, основываясь на вышеупомянутом порядке. Например, если gtid_mode сейчас OFF_PERMISSIVE, возможно изменить на OFF или ON_PERMISSIVE, но не на ON. Это должно гарантировать, что процесс изменения от анонимных транзакций до транзакций GTID онлайн правильно обработан сервером. Когда Вы переключаетесь между gtid_mode=ON и gtid_mode=OFF, статус GTID (другими словами значение gtid_executed) является постоянным. Это гарантирует, что набор GTID, который был применен сервером, всегда сохраняется, независимо от изменений между типами gtid_mode.

Области, связанные с GTID, выводят на экран правильную информацию независимо от в настоящее время выбранного gtid_mode. Это означает, что области, которые выводят на экран наборы GTID, например, gtid_executed, gtid_purged, RECEIVED_TRANSACTION_SET в таблице replication_connection_status Performance Schema и связанные с GTID результаты SHOW SLAVE STATUS , теперь возвратят пустую строку, когда нет никаких существующих GTID. Области, которые выводят на экран единственный GTID, например, CURRENT_TRANSACTION в таблице replication_applier_status_by_worker Performance Schema теперь выведут на экран ANONYMOUS, когда транзакции GTID не используются.

Репликация от ведущего, использующего gtid_mode=ON обеспечивает способность использовать авторасположение, сконфигурированное использованием CHANGE MASTER TO MASTER_AUTO_POSITION = 1;. Топология репликации, использующая то, возможно ли позволить авторасположение или нет, как эта особенность, полагается на GTID и несовместима с анонимными транзакциями. Ошибка произведена, если авторасположение включено и сталкиваются с анонимной транзакцией. Сильно рекомендуется гарантировать, что нет никаких анонимных транзакций, остающихся в топологии прежде, чем позволить авторасположение, см. раздел 19.1.5.2. Допустимые комбинации gtid_mode и авторасположения на ведущем и ведомом устройствах показывают в следующей таблице, где gtid_mode ведущего устройства показано по горизонтали, а gtid_mode ведомого по вертикали:

Таблица 19.1. Допустимые комбинации gtid_mode ведущего и ведомого устройств

Ведущее/Ведомое устройство gtid_mode
OFF
OFF_PERMISSIVE
ON_PERMISSIVE
ON
OFF

Y

Y

N

N

OFF_PERMISSIVE

Y

Y

Y

Y*

ON_PERMISSIVE

Y

Y

Y

Y*

ON

N

N

Y

Y*

В вышеупомянутой таблице записи:

В настоящее время выбираемое gtid_mode также воздействует на gtid_next. Следующая таблица показывает поведение сервера для различных значений gtid_mode и gtid_next.

Таблица 19.2. Допустимые комбинации gtid_mode и gtid_next

gtid_next

AUTOMATIC

binary log on

AUTOMATIC

binary log off

ANONYMOUS

UUID:NUMBER

OFF

ANONYMOUS

ANONYMOUS

ANONYMOUS

Ошибка

OFF_PERMISSIVE

ANONYMOUS

ANONYMOUS

ANONYMOUS

UUID:NUMBER

ON_PERMISSIVE

Новый GTID

ANONYMOUS

ANONYMOUS

UUID:NUMBER

ON

Новый GTID

ANONYMOUS

Ошибка

UUID:NUMBER

В вышеупомянутой таблице записи:

Когда двоичной журнал выключен и gtid_next = AUTOMATIC, GTID не произведен. Это совместимо с поведением предыдущих версий.

19.1.5.2. Включение транзакции GTID онлайн

Этот раздел описывает, как включить транзакции GTID и произвольно авторасположение на серверах, которые уже используют анонимныме транзакции. Эта процедура не требует останова сервера и подходит для использования в производстве. Однако, если у Вас есть возможность остановить сервер, включая транзакциям GTID, этот процесс легче.

Прежде, чем Вы начнете, гарантируйте, что серверы удовлетворяют следующим предварительным условиям:

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

Крайне важно, чтобы Вы завершили каждый шаг прежде, чем перейти к следующему шагу.

Чтобы включить транзакции GTID:

  1. На каждом сервере выполните:

    SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN;
    

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

    Это первый важный шаг. Вы должны гарантировать, что никакие предупреждения не производятся в журналах ошибок прежде, чем идти дальше.

  2. На каждом сервере выполните:
    SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON;
    
  3. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
    

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

  4. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
    

    Не имеет значения, какой сервер выполняет этот запрос сначала.

  5. На каждом сервере ждите, пока переменная ONGOING_ANONYMOUS_TRANSACTION_COUNT не станет 0. Это может быть проверено, используя:
    SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
    

    На ведомом устройстве репликации теоретически возможно, что это показывает ноль и затем отличное от нуля значение снова. Это не проблема, достаточно, что переменная показывает ноль однажды.

  6. Ждите всех транзакций, произведенных к шагу 5, чтобы копировать ко всем серверам. Вы можете сделать это, не останавливая обновления: единственная важная вещь состоит в том, что копируются все анонимные транзакции.

    См. раздел 19.1.5.4 для одного метода проверки, что все анонимные транзакции скопировались ко всем серверам.

  7. Если Вы используете двоичные журналы для чего-нибудь кроме репликации, например, резервного копирования момента времени и восстановления, ждете, пока Вы не нуждаетесь в старых двоичных журналах, имеющих транзакции без GTID.

    Например, после того, как шаг 6 завершился, Вы можете выполнить FLUSH LOGS на сервере, где Вы берете резервные копии. Тогда явно выполните резервное копирование или ждите следующей итерации любой периодической резервной подпрограммы, которую Вы, возможно, настроили.

    Идеально надо произвести чистку всех двоичных журналов, которые существовали, когда шаг 6 был завершен. Также ждите любого резервного копирования перед шагом 6.

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

  8. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = ON;
    
  9. На каждом сервере добавьте gtid-mode=ON в файл my.cnf.

    Вы теперь гарантируете, что у всех транзакций есть GTID (кроме транзакций, произведенных в шаге 5 или ранее, которые были уже обработаны). Чтобы начать использовать протокол GTID так, чтобы Вы могли позже работать автоматически, выполните следующее на каждом ведомом устройстве. Произвольно, если Вы используете мультирепликацию, сделайте это для каждого канала и включите FOR CHANNEL channel:

    STOP SLAVE [FOR CHANNEL 'channel'];
    CHANGE MASTER TO MASTER_AUTO_POSITION = 1 [FOR CHANNEL 'channel'];
    START SLAVE [FOR CHANNEL 'channel'];
    

19.1.5.3. Отключение транзакции GTID онлайн

Этот раздел описывает, как отключить транзакции GTID на серверах, которые уже онлайн. Эта процедура не требует останова сервера и подходит для использования в производстве. Однако, если у Вас есть возможность останова сервера, отключая режим GTID, этот процесс легче.

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

Прежде, чем Вы начнете, гарантируйте, что серверы удовлетворяют следующим предварительным условиям:

  1. Выполните следующее для каждого ведомого устройства, и если Вы используете мультирепликацию, сделайте это для каждого канала и включите FOR CHANNEL:

    STOP SLAVE [FOR CHANNEL 'channel'];
    CHANGE MASTER TO MASTER_AUTO_POSITION = 0, MASTER_LOG_FILE = file, \
           MASTER_LOG_POS = position [FOR CHANNEL 'channel'];
    START SLAVE [FOR CHANNEL 'channel'];
    
  2. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
    
  3. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
    
  4. На каждом сервере ждите, пока переменная @@GLOBAL.GTID_OWNED не станет пустой строкой, проверить это можно так:
    SELECT @@GLOBAL.GTID_OWNED;
    

    На ведомом устройстве репликации теоретически возможно, что это пусто и затем не пусто снова. Это не проблема, достаточно, что это пусто однажды.

  5. Ждите копирования всех транзакций, которые в настоящее время существуют в любом двоичном журнале, ко всем ведомым устройствам. См. раздел 19.1.5.4 для одного метода проверки, что все анонимные транзакции скопировались ко всем серверам.
  6. Если Вы используете двоичные журналы для чего-либо еще, кроме репликации, например, чтобы сделать копию момента времени, ждите, пока Вы не нуждаетесь в старых двоичных журналах, имеющих транзакции GTID.

    Например, после того, как шаг 5 завершился, Вы можете выполнить FLUSH LOGS на сервере, где Вы делаете резервное копирование. Тогда явно выполните резервное копирование или ждите следующей итерации любой периодической резервной подпрограммы, которую Вы, возможно, настроили.

    Идеально произведите чистку всех двоичных журналов, которые существовали, когда шаг 5 был завершен.

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

  7. На каждом сервере выполните:
    SET @@GLOBAL.GTID_MODE = OFF;
    
  8. На каждом сервере установите в my.cnf gtid-mode=OFF.

    Если Вы хотите установить enforce_gtid_consistency=OFF, Вы можете сделать это теперь. После установки этого Вы должны добавить enforce_gtid_consistency=OFF к Вашему конфигурационному файлу.

Если Вы хотите откатиться к более ранней версии MySQL, Вы можете сделать это теперь, используя нормальную процедуру.

19.1.5.4. Подтверждение репликации анонимных транзакций

Этот раздел объясняет, как контролировать топологию репликации и проверить, что скопировались все анонимные транзакции. Это полезно, изменяя режим репликации онлайн, поскольку Вы можете проверить, что безопасно измениться на транзакции GTID.

Есть несколько возможных способов ждать, чтобы скопировать транзакции:

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

Более безопасный метод в том смысле, что это не зависит от синхронизации: если у Вас есть ведущее устройство с одним или более ведомыми устройствами, сделайте следующее:

  1. На ведущем устройстве выполните:

    SHOW MASTER STATUS;
    

    Запишите значения в столбцах File и Position.

  2. На каждом ведомом устройстве, используйте информацию от ведущего устройства, чтобы выполнить:
    SELECT MASTER_POS_WAIT(file, position);
    

Если у Вас есть ведущее устройство и несколько уровней ведомых устройств, или другими словами Вы имеете ведомые устройства ведомых устройств, повторите шаг 2 на каждом уровне.

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

Например, предположите, что у Вас есть три сервера A, B и C, копирующие по кругу так, чтобы A -> B -> C -> A. Процедура тогда:

19.1.6. Репликация и опции двоичного журналирования

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

Из особого значения --server-id.

Командная строка --server-id=#
Системная Имя server_id
Контекст переменной Глобальная
Динамическая Да
Допустимые значения Типinteger
Значение по умолчанию 0
Минимум 0
Максимум 4294967295

Эта опция характерна для основных и для ведомых серверов репликации и используется в репликации, чтобы позволить основным и ведомым серверам идентифицировать себя уникально. Для дополнительной информации см. разделы 19.1.6.2 и 19.1.6.3.

На ведущем устройстве и каждом ведомом устройстве, Вы должны использовать --server-id, чтобы установить уникальный ID репликации в диапазоне от 1 до 232-1. Уникальный значит, что каждый ID должен отличаться от любого ID в использовании любым другим ведущим устройством репликации или ведомым устройством. Например, server-id=3.

--server-id должен использоваться, если двоичное журналирование включено, и значение 0 не изменено сервером. Если Вы определяете --server-id без параметра эффект тот же самый, как использование 0. В любом случае, если server_id = 0, двоичное журналирование имеет место, но ведомые устройства не могут соединиться с ведущим устройством, и при этом любые другие серверы не могут соединиться с ним как ведомые устройства (Bug #11763963, Bug #56718).

См. раздел 19.1.2.2.

server_uuid

В MySQL 8.0 сервер производит истинный UUID в дополнение к --server-id, поставляемому пользователем. Это доступно как глобальная переменная только для чтения server_uuid .

Присутствие server_uuid в MySQL 8.0 не изменяет требование того, чтобы был установлен уникальный --server-id для каждого сервера MySQL как часть подготовки и выполнения репликации MySQL, как описано ранее в этом разделе.

Системная Имя server_uuid
Контекст переменной Глобальная
Динамическая Нет
Допустимые значения Типstring

Запускаясь, сервер MySQL автоматически получает UUID следующим образом:

  1. Попытаться считать и использовать UUID, написанный в файле data_dir/auto.cnf (data_dir это каталог данных сервера).

  2. Если data_dir/auto.cnf не найден, произвести новый UUID и сохранить его в этом файле, создавая файл в случае необходимости.

auto.cnf имеет формат похожий на my.cnf или my.ini. В MySQL 8.0 auto.cnf имеет только один раздел [auto] раздел, содержащий параметр server_uuid, содержание файла кажется подобным тому, что показывают здесь:

[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562

auto.cnf автоматически произведен, не пытайтесь написать или изменить этот файл.

Используя репликацию MySQL, ведущие и ведомые устройства знают UUID друг друга. Значение UUID ведомого устройства может быть замечено в выводе SHOW SLAVE HOSTS. Когда START SLAVE был выполнен, значение UUID ведущего устройства доступно на ведомом устройстве в выводе SHOW SLAVE STATUS.

STOP SLAVE или RESET SLAVE не сбрасывает UUID ведущего устройства как использующийся на ведомом устройстве.

Серверный server_uuid также используется в GTID для транзакций, происходящих на том сервере. Для получения дополнительной информации см. раздел 19.1.3.

Запускаясь, ведомый поток ввода/вывода производит ошибку и прерывается, если UUID ведущего устройства не равен собственному, если установлена опция --replicate-same-server-id. Кроме того, ведомый поток ввода/вывода производит предупреждение, если любое из следующего истина:

19.1.6.1. Репликация и опции двоичного журналирования

Следующие таблицы приводят основную информацию о параметрах командной строки MySQL и системных переменных, применимых к репликации и двоичному журналу.

Таблица 19.3. Обзор опций и переменных репликации в MySQL 8.0

Имя
Командная строкаСистемная? Статусная?
Файл опцийКонтекст Динамическая?
Примечания

abort-slave-event-count

Да Нет Нет
Да Нет
ОПИСАНИЕ: Опция, используемая mysql-test для отладки и тестирования репликации.

binlog_gtid_simple_recovery

Да Да Нет
Да Глобальная Нет
ОПИСАНИЕ: Средство управления, как двоичные журналы повторены во время восстановления GTID.

Com_change_master

Нет Нет Да
Нет Both Нет

Счетчик CHANGE MASTER TO

Com_show_master_status

Нет Нет Да
Нет Both Нет

Счетчик SHOW MASTER STATUS

Com_show_new_master

Нет Нет Да
Нет Both Нет

Счетчик SHOW NEW MASTER

Com_show_slave_hosts

Нет Нет Да
Нет Both Нет

Счетчик SHOW SLAVE HOSTS

Com_show_slave_status

Нет Нет Да
Нет Both Нет

Счетчик SHOW SLAVE STATUS

Com_show_slave_status_nonblocking

Нет Нет Да
Нет Both Нет

Счетчик SHOW SLAVE STATUS NONBLOCKING

Com_slave_start

Нет Нет Да
Нет Both Нет

Счетчик START SLAVE

Com_slave_stop

Нет Нет Да
Нет Both Нет

Счетчик STOP SLAVE

disconnect-slave-event-count

Да Нет Нет
Да Нет

Опция, используемая mysql-test для отладки и тестирования репликации.

enforce-gtid-consistency

Да Да Нет
Да Глобальная Да

Предотвращает выполнение запросов, которые не могут быть зарегистрированы транзакционным образом.

enforce_gtid_consistency

Да Да Нет
Да Глобальная Да

Предотвращает выполнение запросов, которые не могут быть зарегистрированы транзакционным образом.

executed-gtids-compression-period

Да Нет Нет
Да Нет

Устарел и будет удален в будущей версии. Используйте gtid-executed-compression-period.

executed_gtids_compression_period

Нет Да Нет
Нет Глобальная Да

Устарел и будет удален в будущей версии. Используйте gtid_executed_compression_period.

gtid-executed-compression-period

Да Нет Нет
Да Нет

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

gtid-mode

Да Да Нет
Да Глобальная Да

Средство управления включено ли журналирование GTID, и какие транзакции журналы могут содержать.

gtid_executed

Нет Да Нет
Нет Глобальная Нет

Все GTID в двоичном журнале (глобальная) или текущая транзакция (сеансовая). Только для чтения.

gtid_executed_compression_period

Нет Да Нет
Нет Глобальная Да

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

gtid_mode

Нет Да Нет
Нет Глобальная Да

Управляет включено ли GTID журналирование, и какие транзакции журналы могут содержать.

gtid_next

Нет Да Нет
Нет Session Да

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

gtid_owned

Нет Да Нет
Нет Both Нет

Набор GTID, принадлежащий этому клиенту (сеанс) или всем клиентам, вместе с ID потока (глобально) владельца. Только для чтения.

gtid_purged

Нет Да Нет
Нет Глобальная Да

Набор всех GTID, которые были вычищены из двоичного журнала.

init_slave

Да Да Нет
Да Глобальная Да

Запросы, которые выполнены, когда ведомое устройство соединяется с ведущим.

log-slave-updates

Да Да Нет
Да Глобальная Нет

Говорит ведомому устройству регистрировать обновления, выполненные его потоком SQL, в его собственном двоичном журнале.

log_slave_updates

Да Да Нет
Да Глобальная Нет

Должно ли ведомое устройство зарегистрировать обновления, выполненные его потоком SQL в его собственном двоичном журнале. Только для чтения, устанавливается, используя параметр сервера --log-slave-updates.

log_statements_unsafe_for_binlog

Нет Да Нет
Нет Глобальная Да

Отключает ошибку 1592, написанную в журнал ошибок.

master-info-file

Да Нет Нет
Да Нет

Местоположение и название файла, который помнит ведущее устройство и где поток ввода/вывода репликации находится в двоичных журналах ведущего устройства.

master-info-repository

Да Нет Нет
Да Нет

Написать ли основную информацию о статусе и местоположении потока ввода/вывода репликации в двоичных журналах ведущего устройства в файл или в таблицу.

master-retry-count

Да Нет Нет
Да Нет

Число попыток, которые ведомое устройство делает, чтобы соединиться с ведущим устройством перед отказом.

master_info_repository

Да Да Нет
Да Глобальная Да

Написать ли основную информацию о статусе и местоположении потока ввода/вывода репликации в двоичных журналах ведущего устройства в файл или в таблицу.

relay-log

Да Да Нет
Да Глобальная Нет

Местоположение и имя, чтобы использовать для журналов реле.

relay-log-index

Да Да Нет
Да Глобальная Нет

Местоположение и имя, чтобы использовать для файла, который сохраняет список последних журналов реле.

relay-log-info-file

Да Нет Нет
Да Нет

Местоположение и название файла, который помнит, где поток репликации SQL находится в журналах реле.

relay-log-info-repository

Да Нет Нет
Да Нет

Написать местоположение потока SQL в журнале реле в файл или в таблицу.

relay-log-recovery

Да Нет Нет
Да Нет

Включает автоматическое восстановление файлов системного журнала реле от ведущего устройства при запуске.

relay_log_basename

Нет Да Нет
Нет Глобальная Нет

Полный путь к журналу реле, включая имя файла.

relay_log_index

Да Да Нет
Да Глобальная Нет

Название индексного файла журнала реле.

relay_log_info_file

Да Да Нет
Да Глобальная Нет

Название файла, в котором ведомое устройство делает запись информации о журналах реле.

relay_log_info_repository

Нет Да Нет
Нет Глобальная Да

Написать местоположение потока SQL в журнале реле в файл или таблицу.

relay_log_purge

Да Да Нет
Да Глобальная Да

Определяет, очищены ли журналы реле.

relay_log_recovery

Да Да Нет
Да Глобальная Да

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

relay_log_space_limit

Да Да Нет
Да Глобальная Нет

Максимальное пространство, чтобы использовать для всех журналов реле.

replicate-do-db

Да Нет Нет
Да Нет

Говорит ведомому потоку SQL ограничивать репликацию указанной базой данных.

replicate-do-table

Да Нет Нет
Да Нет

Говорит ведомому потоку SQL ограничивать репликацию указанной таблицей.

replicate-ignore-db

Да Нет Нет
Да Нет

Говорит ведомому потоку SQL не копировать к указанной базе данных.

replicate-ignore-table

Да Нет Нет
Да Нет

Говорит ведомому потоку SQL не копировать к указанной таблице.

replicate-rewrite-db

Да Нет Нет
Да Нет

Обновления базы данных с другим именем, чем оригинал.

replicate-same-server-id

Да Нет Нет
Да Нет

В репликации, если установлено в 1, не пропускать события, имеющие id нашего сервера.

replicate-wild-do-table

Да Нет Нет
Да Нет

Говорит ведомому потоку ограничивать репликацию таблицами, которые соответствуют указанному подстановочномму образцу.

replicate-wild-ignore-table

Да Нет Нет
Да Нет

Говорит ведомому потоку не копировать к таблицам, которые соответствуют данному подстановочному образцу.

report-host

Да Да Нет
Да Глобальная Нет

Имя хоста или IP ведомого устройства, о котором сообщат ведущему устройству во время ведомой регистрации.

report-password

Да Да Нет
Да Глобальная Нет

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

report-port

Да Да Нет
Да Глобальная Нет

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

report-user

Да Да Нет
Да Глобальная Нет

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

Rpl_semi_sync_master_clients

Нет Нет Да
Нет Глобальная Нет

Число полусинхронных ведомых устройств.

rpl_semi_sync_master_enabled

Нет Да Нет
Нет Глобальная Да

Включена ли полусинхронная репликация на ведущем устройстве.

Rpl_semi_sync_master_net_avg_wait_time

Нет Нет Да
Нет Глобальная Нет

Среднее время, которое ведущее устройство ждало ответа ведомого.

Rpl_semi_sync_master_net_wait_time

Нет Нет Да
Нет Глобальная Нет

Полное время, которое ведущее устройство ждало ответа ведомого.

Rpl_semi_sync_master_net_waits

Нет Нет Да
Нет Глобальная Нет

Общее количество времени, которое ведущее устройство ждало ответа ведомых

Rpl_semi_sync_master_no_times

Нет Нет Да
Нет Глобальная Нет

Число раз, которое ведущее устройство выключило полусинхронную репликацию.

Rpl_semi_sync_master_no_tx

Нет Нет Да
Нет Глобальная Нет

Число передач, не признанных успешными.

Rpl_semi_sync_master_status

Нет Нет Да
Нет Глобальная Нет

Является ли полусинхронная репликация операционной на ведущем устройстве.

Rpl_semi_sync_master_timefunc_failures

Нет Нет Да
Нет Глобальная Нет

Число раз, которое ведущее устройство потерпело неудачу, вызывая функции времени.

rpl_semi_sync_master_timeout

Нет Да Нет
Нет Глобальная Да

Число миллисекунд, чтобы ждать ответа ведомого.

rpl_semi_sync_master_trace_level

Нет Да Нет
Нет Глобальная Да

Уровень трассировки полусинхронной репликации на ведущем устройстве.

Rpl_semi_sync_master_tx_avg_wait_time

Нет Нет Да
Нет Глобальная Нет

Среднее время, которое ведущее устройство ждало каждой транзакции.

Rpl_semi_sync_master_tx_wait_time

Нет Нет Да
Нет Глобальная Нет

Полное время, которое ведущее устройство ждало транзакций.

Rpl_semi_sync_master_tx_waits

Нет Нет Да
Нет Глобальная Нет

Общее количество времени, которое ведущее устройство ждало транзакций.

rpl_semi_sync_master_wait_for_slave_count

Нет Да Нет
Нет Глобальная Да

Сколько ответов от ведомого ведущее устройство должно получить за транзакцию перед обработкой.

rpl_semi_sync_master_wait_no_slave

Нет Да Нет
Нет Глобальная Да

Ждет ли ведущее устройство тайм-аута даже без ведомых устройств.

rpl_semi_sync_master_wait_point

Нет Да Нет
Нет Глобальная Да

Точка лжидания подтверждения получения ведомой транзакции.

Rpl_semi_sync_master_wait_pos_backtraverse

Нет Нет Да
Нет Глобальная Нет

Сколько раз ведущее устройство ждало события с двоичными координатами ниже, чем события раньше.

Rpl_semi_sync_master_wait_sessions

Нет Нет Да
Нет Глобальная Нет

Число сеансов, в настоящее время ожидающих ответов ведомых.

Rpl_semi_sync_master_yes_tx

Нет Нет Да
Нет Глобальная Нет

Число передач, признанных успешными.

rpl_semi_sync_slave_enabled

Нет Да Нет
Нет Глобальная Да

Включена ли полусинхронная репликация на ведомом устройстве.

Rpl_semi_sync_slave_status

Нет Нет Да
Нет Глобальная Нет

Является ли полусинхронная репликация операционной на ведомом устройстве.

rpl_semi_sync_slave_trace_level

Нет Да Нет
Нет Глобальная Да

Уровень трассировки полусинхронной репликации на ведомом устройстве.

rpl_stop_slave_timeout

Да Да Нет
Да Глобальная Да

Определить число секунд, которые STOP SLAVE ждет перед синхронизацией.

server_uuid

Нет Да Нет
Нет Глобальная Нет

Глобальный уникальный ID сервера, автоматически произведенный при запуске сервера.

show-slave-auth-info

Да Нет Нет
Да Нет

Показать имя пользователя и пароль в SHOW SLAVE HOSTS на этом ведущем устройстве.

simplified_binlog_gtid_recovery

Да Да Нет
Да Глобальная Нет

Средство управления, как двоичные журналы повторены во время восстановления GTID.

skip-slave-start

Да Нет Нет
Да Нет

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

slave-checkpoint-group

Да Нет Нет
Да Нет

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

slave-checkpoint-period

Да Нет Нет
Да Нет

Обновить состояние продвижения мультипоточного ведомого устройства и сбросить на диск журнал реле после этого числа миллисекунд. Не поддержан MySQL Cluster.

slave-load-tmpdir

Да Да Нет
Да Глобальная Нет

Куда ведомое устройство должно поместить свои временные файлы, копируя LOAD DATA INFILE.

slave-max-allowed-packet

Да Нет Нет
Да Нет

Максимальный размер в байтах пакета, который можно послать от ведущего устройства репликации в ведомое устройство, переопределяет max_allowed_packet.

slave_net_timeout

Да Да Нет
Да Глобальная Да

Число секунд, которое надо ждать большего количества данных от основного/ведомого соединения прежде, чем прервать чтение.

slave-parallel-type

Да Нет Нет
Да Нет

Говорит ведомому устройству использовать базу данных (DATABASE) или информацию timestamp (LOGICAL_CLOCK) от ведущего устройства, чтобы обеспечить параллельность транзакциям. Значение по умолчанию DATABASE.

slave-parallel-workers

Да Нет Нет
Да Нет

Число рабочих потоков для того, чтобы запустить события параллельно. 0 (по умолчанию) отключает ведомую мультипоточную обработку. Не поддержан MySQL Cluster.

slave-pending-jobs-size-max

Да Нет Нет
Нет Нет

Максимальный размер очередей ведомого, хранящих еще не примененные события.

slave-rows-search-algorithms

Да Нет Нет
Да Нет

Определяет алгоритмы поиска, используемые для ведомого группирования обновления. Любые 2 или 3 из списка INDEX_SEARCH, TABLE_SCAN, HASH_SCAN, по умолчанию TABLE_SCAN, INDEX_SCAN.

slave-skip-errors

Да Да Нет
Да Глобальная Нет

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

slave_checkpoint_group

Да Да Нет
Да Глобальная Да

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

slave_checkpoint_period

Да Да Нет
Да Глобальная Да

Обновить состояние продвижения мультипоточного ведомого устройства и сбросить на диск журнал реле после этого числа миллисекунд. Не поддержан MySQL Cluster.

slave_compressed_protocol

Да Да Нет
Да Глобальная Да

Использовать сжатие на основном/ведомом протоколе.

slave_exec_mode

Да Да Нет
Да Глобальная Да

Учитывает переключение ведомого потока между режимом IDEMPOTENT (ключ и некоторыми другими ошибки подавлены) и режимом STRICT (по умолчанию, за исключением MySQL Cluster, где IDEMPOTENT всегда используется).

Slave_heartbeat_period

Нет Нет Да
Нет Глобальная Нет

Интервал биения репликации ведомого устройства в секундах.

slave_max_allowed_packet

Нет Да Нет
Нет Глобальная Да

Максимальный размер в байтах пакета, который можно послать от ведущего устройства репликации в ведомое устройство, переопределение max_allowed_packet.

Slave_open_temp_tables

Нет Нет Да
Нет Глобальная Нет

Число временных таблиц, которые ведомый поток SQL в настоящее время открыл.

slave_parallel_type

Нет Да Нет
Нет Глобальная Да

Говорит ведомому устройству использовать базу данных (DATABASE) или информацию timestamp (LOGICAL_CLOCK) от ведущего устройства, чтобы обеспечить параллельность транзакциям. Значение по умолчанию DATABASE.

slave_parallel_workers

Да Да Нет
Нет Глобальная Да

Число рабочих потоков для того, чтобы запустить события параллельно. Установка в 0 (значение по умолчанию) отключает ведомую мультипоточную обработку. Не поддержан MySQL Cluster.

slave_pending_jobs_size_max

Нет Да Нет
Нет Глобальная Да

Максимальный размер очередей ведомого для хранения еще не примененных событий.

slave_preserve_commit_order

Да Да Нет
Нет Глобальная Да

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

Slave_retried_transactions

Нет Нет Да
Нет Глобальная Нет

Сколько раз начиная с запуска поток SQL ведомого устройства повторил транзакции.

slave_rows_search_algorithms

Нет Да Нет
Нет Глобальная Да

Определяет алгоритмы поиска, используемые для ведомого группирования обновления. Любые 2 или 3 из списка INDEX_SEARCH, TABLE_SCAN, HASH_SCAN, по умолчанию TABLE_SCAN, INDEX_SCAN.

Slave_running

Нет Нет Да
Нет Глобальная Нет

Статус этого сервера как ведомого устройства репликации (ведомое состояние потока ввода/вывода).

slave_transaction_retries

Да Да Нет
Да Глобальная Да

Сколько раз ведомый поток SQL повторит транзакцию в случае, если это потерпело неудачу с тупиком или тайм-аутом блокировки перед отказом.

slave_type_conversions

Да Да Нет
Да Глобальная Нет

Средство управления конверсионным режимом на ведомом устройстве репликации. Значение список из ноля или большего количества элементов из списка: ALL_LOSSY, ALL_NON_LOSSY. Установите к пустой строке, чтобы отвергнуть преобразования типа между ведущим устройством и ведомым устройством.

sql_slave_skip_counter

Нет Да Нет
Нет Глобальная Да

Число событий от ведущего устройства, которое должен пропустить ведомый сервер. Несовместимо с репликацией GTID.

sync_binlog

Да Да Нет
Да Глобальная Да

Синхронно сбросить двоичной журнал к диску после каждого #-го события.

sync_master_info

Да Да Нет
Да Глобальная Да

Синхронизировать master.info с диском после каждого #-го события.

sync_relay_log

Да Да Нет
Да Глобальная Да

Синхронизировать журнал реле с диском после каждого #-го события.

sync_relay_log_info

Да Да Нет
Да Глобальная Да

Синхронизировать файл relay.info с диском после каждого #-го события.

Раздел 19.1.6.2 обеспечивает более подробную информацию об опциях и переменных, касающихся главных серверов репликации. Для получения дополнительной информации об опциях и переменных, касающихся ведомых устройств репликации, см. раздел 19.1.6.3.

Таблица 19.4. Опции и переменные двоичного журналирования в MySQL 8.0

Имя
Командная строка Системная? Статусная?
Файл опций Контекст Динамическая?
Примечания

binlog-checksum

Да Нет Нет
Да Нет

Включить/отключить контрольные суммы двоичного журнала.

binlog-do-db

Да Нет Нет
Да Нет

Ограничить двоичное журналирование к определенным базам данных.

binlog_format

Да Да Нет
Да Both Да

Определяет формат двоичного журнала.

binlog-ignore-db

Да Нет Нет
Да Нет

Говорит ведущему устройству, которое обновляет эту базу данных, не регистрировать в двоичном журнале.

binlog-row-event-max-size

Да Нет Нет
Да Нет

Максимальный размер события в двоичном журнале.

binlog-rows-query-log-events

Да Нет Нет
Да Нет

Позволяет регистрировать события запроса строк, используя основанное на строке журналирование. Отключен по умолчанию. Не включайте, производя журналы для ведомых устройств pre-5.6.2.

Binlog_cache_disk_use

Нет Нет Да
Нет Глобальная Нет

Число транзакций, которые использовали временный файл вместо двоичного кэша журнала.

binlog_cache_size

Да Да Нет
Да Глобальная Да

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

Binlog_cache_use

Нет Нет Да
Нет Глобальная Нет

Число транзакций, которые использовали временный кэш журнала.

binlog_checksum

Нет Да Нет
Нет Глобальная Да

Включить/отключить контрольные суммы двоичного журнала.

binlog_direct_non_transactional_updates

Да Да Нет
Да Both Да

Обновления, использующие формат запроса к нетранзакционным механизмам, будут написаны непосредственно двоичному журналу. См. документацию перед использованием.

binlog_error_action

Да Да Нет
Да Both Да

Средство управления, что происходит, когда сервер не может написать в двоичный журнал.

binlog_group_commit_sync_delay

Да Да Нет
Да Глобальная Да

Определяет сколько микросекунд ждать прежде, чем синхронизировать транзакции с диском.

binlog_group_commit_sync_no_delay_count

Да Да Нет
Да Глобальная Да

Устанавливает максимальное количество транзакций, которое ждать прежде, чем прервать текущую задержку, определенную binlog_group_commit_sync_delay.

binlog_max_flush_queue_time

Нет Да Нет
Нет Глобальная Да

Сколько времени читать транзакции прежде, чем сбросить в двоичный журнал.

binlog_order_commits

Нет Да Нет
Нет Глобальная Да

Передать ли в том же самом порядке, как записано в двоичном журнале.

binlog_row_image

Да Да Нет
Да Both Да

Использовать полные или минимальные образы, регистрируя изменения строки. Позволенные значения full, minimal и noblob.

binlog_rows_query_log_events

Нет Да Нет
Нет Both Да

Когда TRUE, позволяет регистрировать события запроса строк в основанном на строке режиме журналирования. FALSE по умолчанию. Не включайте, производя журналы для ведомых устройств репликации pre-5.6.2.

Binlog_stmt_cache_disk_use

Нет Нет Да
Нет Глобальная Нет

Число нетранзакционных запросов, которые использовали временный файл вместо кэша запросов журнала.

binlog_stmt_cache_size

Да Да Нет
Да Глобальная Да

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

Binlog_stmt_cache_use

Нет Нет Да
Нет Глобальная Нет

Число запросов, которые использовали временный кэш запросов журнала.

binlogging_impossible_mode

Да Да Нет
Да Both Да

Устарел и будет удален в будущей версии. Используйте binlog_error_action.

Com_show_binlog_events

Нет Нет Да
Нет Both Нет

Счетчик SHOW BINLOG EVENTS.

Com_show_binlogs

Нет Нет Да
Нет Both Нет

Счетчик SHOW BINLOGS.

log-bin-use-v1-row-events

Да Да Нет
Да Глобальная Нет

Использовать первую версию событий строки.

log_bin_basename

Нет Да Нет
Нет Глобальная Нет

Полный путь к двоичному журналу, включая имя файла.

log_bin_use_v1_row_events

Да Да Нет
Да Глобальная Нет

Использует ли сервер первую версию событий строки.

master-verify-checksum

Да Нет Нет
Да Нет

Ведущее устройство должно исследовать контрольные суммы, читая из двоичного журнала.

master_verify_checksum

Нет Да Нет
Нет Глобальная Да

Ведущее устройство должно читать контрольные суммы из двоичного журнала.

max-binlog-dump-events

Да Нет Нет
Да Нет

Опция, используемая mysql-test для отладки репликации.

max_binlog_cache_size

Да Да Нет
Да Глобальная Да

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

max_binlog_size

Да Да Нет
Да Глобальная Да

Двоичный журнал будет ротирован автоматически, когда размер превысит это значение.

max_binlog_stmt_cache_size

Да Да Нет
Да Глобальная Да

Может использоваться, чтобы ограничить полный размер, используемый, чтобы кэшировать все нетранзакционные запросы во время транзакции.

slave-sql-verify-checksum

Да Нет Нет
Да Нет

Заставить ведомое устройство исследовать контрольные суммы, читая из журнала реле.

slave_sql_verify_checksum

Нет Да Нет
Нет Глобальная Да

Заставить ведомое устройство исследовать контрольные суммы, читая из журнала реле.

sporadic-binlog-dump-fail

Да Нет Нет
Да Нет

Опция, используемая mysql-test для отладки и тестирования.

Раздел 19.1.6.4 обеспечивает более подробную информацию об опциях и переменных, касающихся двоичного журналирования. Для дополнительной общей информации о двоичном журнале см. раздел 6.4.4.

Для информации о переменных sql_log_bin и sql_log_off см. раздел 6.1.5.

Для таблицы, показывающей все параметры командной строки и переменные состояния, используемые с mysqld, см раздел 6.1.3.

19.1.6.2. Ведущие опции и переменные репликации

Этот раздел описывает параметры сервера и системные переменные, которые Вы можете использовать на главных серверах репликации. Вы можете определить опции в командной строке или в файле опций. Вы можете определить значения переменных с использование SET.

На ведущем устройстве и каждом ведомом устройстве Вы должны использовать опцию server-id , чтобы установить уникальный ID репликации. Для каждого сервера Вы должны выбрать уникальное положительное целое число в диапазоне от 1 до 232 - 1, каждый ID должно отличаться от любого ID в использовании любым другим ведущим устройством репликации или ведомым устройством. Пример: server-id=3.

Для опций, используемых на ведущем устройстве для того, чтобы управлять двоичным журналированием, см. раздел 19.1.6.4.

Системные переменные, используемые на ведущих устройствах репликации

Следующие системные переменные используются, чтобы управлять ведущими устройствами репликации:

19.1.6.3. Ведомые опции и переменные репликации

Этот раздел объясняет параметры сервера и системные переменные, которые относятся к ведомым серверам репликации.

Определите опции в командной строке или в файле опций. Многие из опций могут быть установлены в то время, как сервер работает при использовании CHANGE MASTER TO . Определите значение переменной с использованием SET.

ID сервера. На ведущем устройстве и на каждом ведомом устройстве Вы должны использовать server-id, чтобы установить уникальный ID репликации в диапазоне от 1 до 232-1. Уникальный означает, что каждый ID должен отличаться от любого ID в использовании любым другим ведущим устройством репликации или ведомым устройством. Пример файла my.cnf:

[mysqld]
server-id=3
Опции запуска для ведомых устройств репликации

Этот раздел объясняет опции запуска для того, чтобы управлять ведомыми серверами репликации. Многие из этих опций могут быть установлены в то время, как сервер работает, с помощью CHANGE MASTER TO. Другие, например, опции --replicate-* могут быть установлены только, когда ведомый сервер запускается. Связанные с репликацией системные переменные обсуждены позже в этом разделе.

Следующие опции используются внутренне испытательным набором MySQL для тестирования репликации и отладки. Они не предназначены для использования в производственной установке.

Опции для журналирования состояния ведомого в таблицы

MySQL 8.0 допускает журналирование ведомой информации о статусе репликации к таблицам, а не файлам. Запись основного журнала информации и журнала информации журнала реле может быть сконфигурировано, отдельно используя эти два параметра сервера, перечисленные здесь:

Таблицы журнала информации и их содержание считают местными к данному MySQL Server. Они не копируются, и изменения в них не написаны в двоичный журнал.

См. раздел 19.2.4.

Системные переменные, используемые на ведомых устройствах репликации

Следующий список описывает системные переменные для того, чтобы управлять ведомыми серверами репликации. Они могут быть установлены при запуске сервера и некоторые из них могут быть изменены во время выполнения при использовании SET. Параметры сервера, используемые с ведомыми устройствами репликации, перечислены ранее в этом разделе.

19.1.6.4. Опции и переменные двоичного журналирования

Вы можете использовать опции и системные переменные mysqld, которые описаны в этом разделе, чтобы затронуть работу двоичного журнала так же как управлять, какие запросы написаны двоичному журналу. Для дополнительной информации о двоичном журнале см. раздел 6.4.4.

Опции запуска, используемые с двоичным журналированием

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

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

Опции контрольной суммы. MySQL 8.0 понимает чтение и запись контрольных сумм журнала. Они включены, используя эти две опции:

Чтобы управлять чтением контрольных сумм ведомым устройством от реле, используйте --slave-sql-verify-checksum.

Тестирование и отладка опций. Следующие опции журнала используются в тестировании репликации и отладке. Они не предназначены для использования в нормальном функционировании.

Системные переменные, используемые с двоичным журналированием

Следующий список описывает системные переменные для того, чтобы управлять двоичным журналированием. Они могут быть установлены при запуске сервера, некоторые из них могут быть изменены во время выполнения при использовании SET. Параметры сервера, используемые, чтобы управлять двоичным журналированием, перечислены ранее в этом разделе. Для информации о sql_log_bin и sql_log_off см. раздел 6.1.5.

19.1.6.5. Опции и переменные глобального операционного ID

Опции запуска, используемые с репликацией GTID

Следующие опции запуска сервера используются с GTID-репликацией:

Системные переменные, используемые с репликацией GTID

Следующие системные переменные используются с GTID-репликацией:

19.1.7. Общие задачи управления репликацией

Как только репликация был запущена, она выполняется, не требуя большого регулярного вмешательства. Этот раздел описывает, как проверить состояние репликации и как сделать паузу.

19.1.7.1. Проверка состояния репликации

Наиболее распространенная задача, управления процессом репликации состоит в том, чтобы гарантировать, что репликация имеет место и что не было никаких ошибок между ведомым и ведущим устройствами. Основной запрос для этого SHOW SLAVE STATUS, который Вы должны выполнить на каждом ведомом устройстве:

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
 Slave_IO_State: Waiting for master to send event
Master_Host: master1
Master_User: root
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
 Relay_Log_File: slave1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
 Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
 Replicate_Do_Table:
 Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
 Last_Errno: 0
 Last_Error:
 Skip_Counter: 0
Exec_Master_Log_Pos: 931
Relay_Log_Space: 1365
Until_Condition: None
 Until_Log_File:
Until_Log_Pos: 0
 Master_SSL_Allowed: No
 Master_SSL_CA_File:
 Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
 Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
 Last_SQL_Errno: 0
 Last_SQL_Error:
Replicate_Ignore_Server_Ids: 0

Поля из отчета о состоянии:

Несколько пар областей предоставляют информацию о продвижении ведомого устройства в чтении событий от основного двоичного журнала и обработки их в журнале реле:

На ведущем устройстве Вы можете проверить состояние соединенного ведомого использованием SHOW PROCESSLIST , чтобы исследовать список выполнения процессов. Ведомые соединения имеют Binlog Dump в поле Command:

mysql> SHOW PROCESSLIST \G;
*************************** 4. row ***************************
 Id: 10
 User: root
 Host: slave1:58371
 db: NULL
Command: Binlog Dump
 Time: 777
State: Has sent all binlog to slave; waiting for binlog to be updated
 Info: NULL

Поскольку это ведомое устройство, которое управляет процессом репликации, очень небольшая информация доступна в этом отчете.

Для ведомых устройств, которые были запущены с опцией --report-host и соединены с ведущим устройством, запрос SHOW SLAVE HOSTS о ведущем устройстве показывает основную информацию о ведомых устройствах. Вывод включает ID ведомого сервера, значение опции --report-host , порт соединения и ID:

mysql> SHOW SLAVE HOSTS;
+-----------+--------+------+-------------------+-----------+
| Server_id | Host   | Port | Rpl_recovery_rank | Master_id |
+-----------+--------+------+-------------------+-----------+
| 10        | slave1 | 3306 | 0                 | 1         |
+-----------+--------+------+-------------------+-----------+
1 row in set (0.00 sec)

19.1.7.2. Пауза репликации на ведомом устройстве

Вы можете остановить и запустить репликацию на ведомом устройстве, используя STOP SLAVE и START SLAVE.

Чтобы прекратить обрабатывать двоичный журнал от ведущего устройства, надо использовать STOP SLAVE:

mysql> STOP SLAVE;

Когда репликация остановлена, ведомый поток ввода/вывода прекращает читать события из основного двоичного журнала и писать их в журнал реле, а поток SQL прекращает читать события из журнала реле и выполнять их. Вы можете сделать паузу ввода/вывода или потока SQL индивидуально, определяя тип потока:

mysql> STOP SLAVE IO_THREAD;
mysql> STOP SLAVE SQL_THREAD;

Чтобы запустить выполнение снова, используйте START SLAVE:

mysql> START SLAVE;

Чтобы запустить особый поток, определите тип потока:

mysql> START SLAVE IO_THREAD;
mysql> START SLAVE SQL_THREAD;

Для ведомого устройства, которое выполняет только обновления, обрабатывая события от ведущего устройства, остановить только поток SQL, может быть полезным, если Вы хотите выполнить резервное копирование или другую задачу. Поток ввода/вывода продолжит читать события от ведущего устройства, но они не выполнены. Это облегчает для ведомого устройства нагнать, когда Вы перезапускаете поток SQL.

Остановка только потока ввода/вывода позволяет событиям в журнале реле быть запущенными потоком SQL до того пункта, где журнал реле заканчивается. Это может быть полезно, когда Вы хотите к выполнению паузы догнать события, уже полученные от ведущего устройства, когда Вы хотите выполнить задачи администрирования на ведомом устройстве, но также и гарантировать, что это обработало все обновления отдельного момента. Этот метод может также использоваться для паузы событий на ведомом устройстве, в то время как Вы проводите администрирование на ведущем устройстве. Остановка потока ввода/вывода, но разрешение потоку SQL работать помогает гарантировать, что нет массивного отставания событий, которые будут выполнены, когда репликация запущена снова.

19.2. Выполнение репликации

Репликация основана на главном сервере, отслеживающем все изменения его баз данных (обновления, удаления и так далее) в его двоичном журнале. Двоичный журнал служит отчетом обо всех событиях, которые изменяют структуру базы данных или контент (данные) с момента, когда сервер был запущен. Как правило, SELECT не зарегистрированы, потому что они не изменяют ни структуры базы данных, ни контента.

Каждое ведомое устройство, которое соединяется с ведущим устройством, просит копию двоичного журнала. Таким образом, это вытягивает данные от ведущего устройства, а не ведущее устройство продвигает данные к ведомому устройству. Ведомое устройство также запускает события от двоичного журнала, который оно получает. Это имеет эффект повторения оригинальных изменений так же, как они были сделаны на ведущем устройстве. Таблицы составлены или их структура изменена, а данные вставлены, удалены и обновлены согласно изменениям, которые были первоначально произведены на ведущем устройстве.

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

См. раздел 19.2.2.

Ведущие и ведомые устройства сообщают о своем состоянии относительно процесса репликации регулярно так, чтобы Вы могли контролировать их. См. раздел 9.14.

Основной двоичный журнал написан местному журналу реле на ведомом устройстве прежде, чем это будет обработано. Ведомое устройство также делает запись информации о текущей позиции в двоичным журнале ведущего устройства и местном журнале реле. См. раздел 19.2.4.

Изменения базы данных фильтруются на ведомом устройстве согласно ряду правил, которые применены согласно различным параметрам конфигурации и переменным оценки управления событиями. Для деталей о том, как эти правила применены см. раздел 19.2.5.

19.2.1. Форматы репликации

Репликация работает, потому что события, написанные двоичному журналу, считаны от ведущего устройства и затем обработаны на ведомом устройстве. События зарегистрированы в пределах двоичного журнала в различных форматах, согласно типу события. Различные используемые форматы репликации соответствуют двоичному формату журналирования, используемому, когда события были зарегистрированы в двоичном журнале ведущего устройства. Корреляция между двоичными форматами журналирования и терминами, использованными во время репликации:

Используя формат MIXED, двоичный формат журналирования определен частично используемым механизмом хранения и выполняемым запросом. Для получения дополнительной информации о журналировании смешанного формата и правилах, управляющих поддержкой различных форматов журналирования см. раздел 6.4.4.3.

Форматом журналирования в рабочем сервере MySQL управляют, устанавливая переменную binlog_format . Эта переменная может быть установлена с сеансовым или глобальным контекстом. Управление правилами, когда и как новая установка вступает в силу, является тем же самым, что касается других переменных, установка переменной для текущего сеанса длится только до конца этого сеанса и изменение невидимо другим сеансам, установка переменной глобально требует перезапуска сервера. См. раздел 14.7.4.1.

Есть условия, при которых Вы не можете изменить двоичной формат журналирования во время выполнения, см. раздел 6.4.4.2.

Вы должны иметь привилегию SUPER , чтобы установить глобальное или сеансовое значение binlog_format.

У основанных на запросе и основанных на строке форматов репликации есть другие вопросы и ограничения. Для сравнения их относительных преимуществ и недостатков см. раздел 19.2.1.1 .

С основанной на запросе репликацией Вы можете столкнуться с проблемами с мультиплицированием сохраненных подпрограмм или триггеров. Вы можете избежать этих проблем при использовании основанной на строке репликации вместо этого. Для получения дополнительной информации см. раздел 21.7.

19.2.1.1. Преимущества и недостатки основанной на запросе и строке репликации

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

Преимущества основанной на запросе репликации
Недостатки основанной на запросе репликации
Преимущества основанной на строке репликации
Недостатки основанной на строке репликации

19.2.1.2. Использование основанного на строке журналирования и репликации

MySQL использует основанное на запросе журналирование (SBL), основанное на строке журналирование (RBL) или журналирование смешанного формата. Тип двоичного журнала определяет размер и эффективность журналирования. Поэтому выбор между основанной на строке репликацией (RBR) или основанной на запросе репликацией (SBR) зависит от Вашего приложения и окружающей среды. Этот раздел описывает известные проблемы, используя основанный на строке формат журнала и описывает некоторые лучшие методы, используя это в репликации.

19.2.1.3. Определение безопасных и опасных запросов в двоичном журналировании

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

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

Обработка безопасных и опасных запросов. Запрос обработан по-разному в зависимости от того, считают ли запрос безопасным и относительно двоичного формата журналирования (то есть, текущего значения binlog_format).

Каждый запрос, отмеченный как опасный, производит предупреждение. Прежде, если бы большое количество таких запросов было выполнено на ведущем устройстве, то это могло бы привести к чрезмерно большим файлам журнала ошибок. Чтобы предотвратить это, MySQL 5.7 обеспечивает механизм подавления предупреждения, который ведет себя следующим образом: всякий раз, когда новые 50 предупреждений ER_BINLOG_UNSAFE_STATEMENT были произведены больше 50 раз в любой 50-секундный период, подавление включено. Когда активировано, это заставляет такие предупреждения не быть написанными в журнал ошибок, вместо этого, для каждых 50 предупреждений этого типа пишется примечание The last warning was repeated N times in last S seconds. Это продолжается пока 50 новых таких предупреждений были выпущены за 50 секунд или меньше, как только уровень уменьшился ниже этого порога, предупреждения обычно регистрируются один раз. Подавление предупреждений не имеет никакого эффекта на то, как безопасность запросов для основанного на запросе журналирования определена, ни на то, как предупреждения посылают клиенту. Клиенты MySQL все еще получают предупреждение для каждого такого запроса.

См. раздел 19.2.1.

Опасные запросы. Запросы со следующими характеристиками считают опасными:

См. раздел 19.4.1.

19.2.2. Детали выполнения репликации

Способности репликации MySQL осуществлены, используя три потока, один на главном сервере и два на ведомом устройстве:

В предыдущем описании есть три потока на основное/ведомое соединение. Ведущее устройство, у которого есть многократные ведомые устройства, создает один двоичной поток дампа журнала для каждого в настоящее время соединяемого ведомого устройства, и у каждого ведомого устройства есть свой собственный ввод/вывод и поток SQL.

Ведомое устройство использует два потока, чтобы отделить обновления от ведущего устройства и выполнение их в независимые задачи. Таким образом, задача чтения запросов не замедлена, если выполнение запросов медленное. Например, если ведомый сервер не работал некоторое время, его поток ввода/вывода может быстро принести все двоичное содержание журнала от ведущего устройства, когда ведомое устройство запускается, даже если поток SQL отстает. Если ведомое устройство останавливается прежде, чем поток SQL выполнил все принесенные запросы, поток ввода/вывода, по крайней мере, принес все так, чтобы безопасная копия запросов была сохранена в местном масштабе в журналах реле ведомого устройства, готовых к выполнению в следующий раз, когда ведомое устройство запускается.

SHOW PROCESSLIST предоставляет информацию, которая говорит Вам, что происходит на ведущем устройстве и на ведомом устройстве относительно репликации. Для информации об основных статусах см. раздел 9.14.4. Для статусов ведомого см. разделы 9.14.5 и 9.14.6.

Следующий пример иллюстрирует, как три потока обнаруживаются в выводе от SHOW PROCESSLIST.

На главном сервере вывод SHOW PROCESSLIST похож на это:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 2
 User: root
 Host: localhost:32931
 db: NULL
Command: Binlog Dump
 Time: 94
State: Has sent all binlog to slave; waiting for binlog to
 be updated
 Info: NULL

Здесь поток 2 это Binlog Dump, который обслуживает соединенное ведомое устройство. State указывает, что все обновления послали в ведомое устройство и что ведущее устройство ждет большего количества обновлений. Если Вы не видите поток Binlog Dump на главном сервере, это означает, что репликация не работает, то есть, никакие ведомые устройства в настоящее время не соединяются.

На ведомом сервере вывод SHOW PROCESSLIST похож на это:

mysql> SHOW PROCESSLIST\G
*************************** 1. row ***************************
 Id: 10
 User: system user
 Host:
 db: NULL
Command: Connect
 Time: 11
State: Waiting for master to send event
 Info: NULL
*************************** 2. row ***************************
 Id: 11
 User: system user
 Host:
 db: NULL
Command: Connect
 Time: 11
State: Has read all relay log; waiting for the slave I/O
 thread to update it
 Info: NULL

State указывает, что поток 10 это поток ввода/вывода, который общается с главным сервером, а поток 11 является потоком SQL, который обрабатывает обновления, сохраненные в журналах реле. В то время, когда SHOW PROCESSLIST был выполнен, оба потока были неактивны, ожидая дальнейших обновлений.

Значение в Time может показать, как отстает ведомое устройство по сравнению с ведущим устройством. См. раздел A.13. Если достаточное количество времени протекает на основной стороне без деятельности Binlog Dump, ведущее устройство решает, что ведомое устройство больше не соединено. Что касается любого другого соединения клиента, тайм-ауты для этого зависят от значений net_write_timeout и net_retry_count, см. раздел 6.1.5.

SHOW SLAVE STATUS обеспечивает дополнительную информацию об обработке репликации на ведомом сервере. См. раздел 19.1.7.1.

19.2.3. Каналы репликации

Каналы репликации представляют путь транзакций, вытекающих из ведущего устройства к ведомому устройству. Этот раздел описывает, как каналы могут использоваться в топологии репликации, и влияние, которое они оказывают на репликацию.

Чтобы предоставить совместимость с предыдущими версиями, сервер MySQL автоматически создает на запуске канал по умолчанию, имя которого пустая строка (""). Этот канал всегда присутствует, это не может быть создано или разрушено пользователем. Если никакие другие каналы (имеющие непустые названия) не были созданы, запросы репликации выполняются только на канале по умолчанию, чтобы все запросы репликации от более старой ведомой функции работали, как ожидалось (см. раздел 19.2.3.2. Запросы, относящиеся к каналам репликации как описано в этом разделе, могут использоваться только, когда есть по крайней мере один названный канал.

Канал репликации охватывает путь транзакций, переданных от ведущего устройства к ведомому. В мультиисходной репликации ведомое устройство открывает многократные каналы, один на ведущее устройство, и у каждого канала есть свой собственный журнал реле и поток SQL. Как только транзакции получены получателем канала репликации (ввод/вывод), они добавлены к файлу системного журнала реле канала и проходят к потоку применения. Это позволяет каналам функционировать независимо.

Канал репликации также связан с именем хоста и портом. Вы можете назначить многократные каналы на ту же самую комбинацию имени хоста и порта, в MySQL 8.0 максимальное количество каналов, которые могут быть добавлены к одному ведомому устройству в мультиисходной топологии репликации, 256. У каждого канала репликации должно быть уникальное (непустое) имя (см. раздел 19.2.3.4). Каналы могут быть сконфигурированы независимо.

19.2.3.1. Команды для операций на единственном канале

Чтобы позволить существующим запросым репликации MySQL действовать на отдельные каналы репликации, MySQL вводит опцию FOR CHANNEL channel_name для использования со следующими запросыми репликации в управлении каналом репликации независимо от других каналов:

Точно так же дополнительный параметр channel_name введен для следующих функций:

Следующие запросы отвергнуты для канала group_replication_recovery.

19.2.3.2. Совместимость с предыдущими запросами репликации

Когда у ведомого устройства репликации есть многократные каналы и опция FOR CHANNEL channel_name не определена, допустимый запрос действует на все доступные каналы.

Например, следующие запросы ведут себя как ожидалось:

Применяйте RESET SLAVE с осторожностью, поскольку эта команда удаляет все существующие каналы, производит чистку их файлов системного журнала реле и обновляет только канал по умолчанию.

Некоторые запросы репликации не могут воздействовать на все каналы. В этом случае выводится ошибка 1964 Multiple channels exist on the slave. Please provide channel name as an argument. Следующие запросы и функции производят эту ошибку, когда используются в мультиисходной топологии репликации и опция FOR CHANNEL channel_name не используется, чтобы определить, на который канал действовать:

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

19.2.3.3. Опции запуска и каналы репликации

Этот раздел описывает опции запуска, на которые воздействует добавление каналов репликации.

Следующие опции запуска должны быть сконфигурированы правильно, чтобы использовать мультиисходную репликацию.

Следующие опции запуска теперь затрагивают все каналы в топологии репликации.

Набор значений для следующих опций запуска применяется на каждый канал, так как это опции запуска mysqld , они применены на каждый канал.

19.2.3.4. Соглашения о присвоении имен канала репликации

Этот раздел описывает, как на соглашения о присвоении имен воздействуют каналы репликации.

У каждого канала репликации есть уникальное имя, которое является строкой с максимальной длиной 64 символа и является нечувствительным к регистру. Поскольку названия канала используются в ведомых таблицах, набором символов, используемым для них, всегда является UTF-8. Хотя Вы вообще свободны использовать любое название каналов, следующие имена сохранены:

Имя, которое Вы выбираете для канала репликации, также влияет на имена файла, используемые ведомым устройством мультирепликации. Файлы системного журнала реле и индексные файлы для каждого канала называют base_name-relay-bin-channel_name .0000x, где base_name имя хоста (если не определено использованием --log-bin) и channel_name название канала, зарегистрированного к этому файлу.

19.2.4. Реле репликации и журналы состояния

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

Безопасная от катастрофического отказа репликация. Для репликации, чтобы быть безопасной от катастрофического отказа, используя таблицы для того, чтобы зарегистрировать состояние и информацию о реле, эти таблицы должны использовать транзакционной механизм хранения, такой как InnoDB. В MySQL 8.0 эти таблицы составлены, используя InnoDB.

Поэтому, чтобы гарантировать безопасность при столкновении на ведомом устройстве, Вы должны выполнить ведомое устройство с включенной опцией --relay-log-recovery в дополнение к установке --relay-log-info-repository = TABLE.

В MySQL 8.0 дано предупреждение, когда mysqld неспособен инициализировать таблицы журналирования репликации, но ведомому устройству позволяют продолжить запускаться. Эта ситуация, наиболее вероятно, произойдет, обновляясь от версии MySQL, которая не поддерживает ведомые таблицы журналирования к той, в которой они поддержаны.

В MySQL 8.0 выполнение любого запроса, требующего блокировки записи одной или обеих таблиц slave_master_info и slave_relay_log_info отвергнуто в то время, как репликация работает, но запросы, которые выполняют только чтение, разрешены в любое время.

Не пытайтесь обновить или вставить строки в таблицы slave_master_info или slave_relay_log_info вручную. Выполнение этого может вызвать неопределенное поведение и не поддержано.

19.2.4.1. Ведомый журнал реле

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

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

Файлы системного журнала реле имеют тот же самый формат как двоичные файлы системного журнала и могут быть считаны, используя mysqlbinlog (см. раздел 5.6.8).

По умолчанию у имен файла системного журнала реле есть форма host_name-relay-bin.nnnnnn в каталоге данных, где host_name название ведомого узла сервера и nnnnnn порядковый номер. Последовательные файлы системного журнала реле создаются, используя последовательные порядковые номера, начиная с 000001. Ведомое устройство использует индексный файл, чтобы отследить использующиеся в настоящее время файлы системного журнала реле. Имя индексного файла журнала реле по умолчанию host_name-relay-bin.index в каталоге данных.

Файл системного журнала реле по умолчанию и имена индексного файла журнала реле могут быть переопределены, соответственно, опциями сервера --relay-log и --relay-log-index (см. раздел 19.1.6).

Если ведомое устройство использует значение по умолчанию основанное на имени файла системного журнала реле, изменение имени хоста ведомого устройства после того, как репликация была настроена, может заставить репликацию терпеть неудачу с ошибками Failed to open the relay log и Could not find target log during relay log initialization. Это известная проблема (см. Bug #2122). Если Вы ожидаете, что имя хоста ведомого устройства могло бы измениться в будущем (например, если сети настроены на ведомом устройстве, таким образом, что его имя хоста может быть изменено, используя DHCP), Вы можете избежать этой проблемы полностью при использовании опций --relay-log и --relay-log-index, чтобы определить файл системного журнала реле явно, когда Вы первоначально настраиваете ведомое устройство. Это сделает имена независимыми от изменений имени хоста сервера.

Если Вы сталкиваетесь с проблемой после того, как репликация уже запущена, один способ ее решить состоит в том, чтобы остановить ведомый сервер, перенести содержание старого индексного файла журнала реле в новый, а затем перезапустить ведомое устройство. На системе Unix это может быть сделано как показано здесь:

shell> cat new_relay_log_name.index >> old_relay_log_name.index
shell> mv old_relay_log_name.index new_relay_log_name.index

Ведомый сервер создает новый файл системного журнала реле при следующих условиях:

Поток SQL автоматически удаляет каждый файл системного журнала реле, как только это запустило все события в файле и больше не нуждается в этом. Нет никакого явного механизма для того, чтобы удалить журналы реле, потому что поток SQL заботится о выполнении. Однако, FLUSH LOGS ротирует журналы реле, что влияет на то, когда поток SQL удаляет их.

19.2.4.2. Ведомые журналы состояния

Ведомый сервер репликации создает два журнала. По умолчанию эти журналы файлы master.info и relay-log.info, создаваемые в каталоге данных. Названия и местоположение этих файлов могут быть изменены при использовании опций --master-info-file и --relay-log-info-file. В MySQL 8.0 один или оба из этих журналов могут также быть написаны в таблицы в базе данных mysql с соответствующей опции: надо использовать --master-info-repository, чтобы иметь основной журнал информации, написанный в таблицу mysql.slave_master_info, и --relay-log-info-repository, чтобы иметь журнал реле, написанный в таблицу mysql.slave_relay_log_info, см. раздел 19.1.6.

Два журнала состояния содержат информацию как показано в выводе SHOW SLAVE STATUS, который обсужден в разделе 14.4.2 . Поскольку журналы состояния сохранены на диске, они переживают завершение работы ведомого сервера. В следующий раз, когда ведомое устройство запускается, оно читает два журнала, чтобы определить, как далеко оно ушло в чтении двоичных журналов от ведущего устройства и в обработке его собственных журналов реле.

Основной файл системного журнала информации или таблица должны быть защищены, потому что это содержит пароль для того, чтобы соединиться с ведущим устройством. См. раздел 7.1.2.3.

Ведомый поток ввода/вывода обновляет основной журнал информации. Следующая таблица показывает связь между строками в файле master.info, столбцами в таблице mysql.slave_master_info и столбцами, выведенными на экран SHOW SLAVE STATUS.

Строка в файле master.info Столбец таблицы slave_master_info Столбец SHOW SLAVE STATUS Описание
1 Number_of_lines [None] Число строк в файле или столбцов в таблице.
2 Master_log_name Master_Log_File Название основного двоичного журнала в настоящее время считанного от ведущего устройства.
3 Master_log_pos Read_Master_Log_Pos Текущая позиция в пределах основного двоичного журнала, которая была считаны от ведущего устройства.
4 Host Master_Host Имя хоста ведущего устройства.
5 User_name Master_User Имя пользователя, чтобы соединяться с ведущим устройством.
6 User_password Пароль (не показан SHOW SLAVE STATUS) Пароль для связи с ведущим устройством.
7 Port Master_Port Сетевой порт, чтобы соединяться с ведущим устройством.
8 Connect_retry Connect_Retry Период (в секундах), который ведомое устройство будет ждать прежде, чем попытаться повторно соединиться с ведущим устройством.
9 Enabled_ssl Master_SSL_Allowed Указывает, поддерживает ли сервер соединения SSL.
10 Ssl_ca Master_SSL_CA_File Файл, используемый для сертификата центра сертификации (CA).
11 Ssl_capath Master_SSL_CA_Path Путь к сертификату центра сертификации (CA).
12 Ssl_cert Master_SSL_Cert Название файла сертификата SSL.
13 Ssl_cipher Master_SSL_Cipher Список возможных шифров для соединения SSL.
14 Ssl_key Master_SSL_Key Название файла ключа SSL.
15 Ssl_verify_server_cert Master_SSL_Verify_Server_Cert Проверить ли сертификат сервера.
16 Heartbeat [None] Интервал между тактами репликации в секундах.
17 Bind Master_Bind Какой из сетевых интерфейсов ведомого устройства должен использоваться для того, чтобы соединиться с ведущим устройством.
18 Ignored_server_ids Replicate_Ignore_Server_Ids Список ID сервера, которые будут проигнорированы. Отметьте, что списку Ignored_server_ids предшествует общее количество ID сервера, чтобы проигнорировать.
19 Uuid Master_UUID Уникальный ID ведущего устройства.
20 Retry_count Master_Retry_Count Максимальное количество попыток пересоединения.
21 Ssl_crl [None] Путь к файлу перечня аннулированных сертификатов ssl.
22 Ssl_crl_path [None] Путь к каталогу, содержащему файлы списка аннулирования ssl.
23 Enabled_auto_position Auto_position Авторасположение используется или нет.
24 Channel_name Channel_name Название канала репликации.

Ведомый поток SQL обновляет журнал информации журнала реле. В MySQL 8.0 файл relay-log.info включает количество строк и значение задержки репликации. Следующая таблица показывает связь между строками в файле relay-log.info, столбцов таблицы mysql.slave_relay_log_info и столбцов SHOW SLAVE STATUS.

Строка файла relay-log.info Столбец таблицы slave_relay_log_info Столбец SHOW SLAVE STATUS Описание
1 Number_of_lines [None] Число строк в файле или столбцов в таблице.
2 Relay_log_name Relay_Log_File Название текущего файла системного журнала реле.
3 Relay_log_pos Relay_Log_Pos Текущая позиция в пределах файла системного журнала реле, события до этой позиции были запущены на ведомой базе данных.
4 Master_log_name Relay_Master_Log_File Название основного двоичного файла системного журнала, из которого были считаны события в файле системного журнала реле.
5 Master_log_pos Exec_Master_Log_Pos Эквивалентная позиция в пределах двоичного файла системного журнала ведущего устройства событий, которые были уже запущены.
6 Sql_delay SQL_Delay Число секунд, на которое ведомое устройство отстает от ведущего.
7 Number_of_workers [None] Число потоков для того, чтобы запустить события репликации (транзакции) параллельно.
8 Id [None] ID используется во внутренних целях, в настоящее время это всегда 1.
9 Channel_name Channel_name Название канала репликации.

В более старых версиях MySQL (до MySQL 5.6) файл relay-log.info не включает количество строк или значение задержки (и таблица slave_relay_log_info недоступна).

Если Вы понижаете ведомый сервер к версии, более старой, чем MySQL 5.6, более старый сервер не читает файл relay-log.info как надо. Чтобы обратиться к этому, измените файл в текстовом редакторе, удаляя начальную строку, содержащую число строк.

Содержание relay-log.info и статусы из SHOW SLAVE STATUS не могут соответствовать, если relay-log.info не сброшен на диск. Идеально, Вы должны только рассмотреть relay-log.info на ведомом устройстве, которое является офлайновым (то есть, mysqld не работает). Для рабочей системы Вы можете использовать SHOW SLAVE STATUS или запросить таблицы slave_master_info и slave_relay_log_info, если Вы пишете журналы состояния в таблицы.

Когда Вы поддерживаете данные ведомого устройства, Вы должны поддержать эти два журнала состояния, наряду с файлами системного журнала реле. Журналы состояния необходимы, чтобы возобновить репликацию после того, как Вы восстанавливаете данные от ведомого устройства. Если Вы теряете журналы реле, но все еще имеете журнал информации журнала реле, Вы можете проверить это, чтобы определить, как далеко поток SQL ушел в основных двоичных журналах. Тогда Вы можете использовать CHANGE MASTER TO с опциями MASTER_LOG_FILE и MASTER_LOG_POS, чтобы сказать ведомому устройству перечитывать двоичные журналы. Конечно, это требует, чтобы двоичные журналы все еще существовали на ведущем устройстве.

19.2.5. Как серверы оценивают правила фильтрации репликации

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

На ведущем устройстве Вы можете управлять, которые базы данных регистрируют изменения при использовании опций --binlog-do-db и --binlog-ignore-db, чтобы управлять двоичным журналированием. Для описания правил, применяемых сервером при оценке этих опций, см. раздел 19.2.5.1. Вы не должны использовать эти опции, чтобы управлять, какие базы данных и таблицы копируются. Вместо этого используйте фильтрацию на ведомом устройстве, чтобы управлять событиями, которые запущены на ведомом.

На ведомой стороне решения о том, выполнить или проигнорировать запросы, полученные от ведущего устройства, приняты согласно опциям --replicate-*, с которыми было запущено ведомое устройство. См. раздел 19.1.6. Фильтры, которыми управляют эти опции, могут также быть установлены динамически, используя CHANGE REPLICATION FILTER. Правила, управляющие такими фильтрами, являются теми же самыми, создаются ли они при использовании опций запуска --replicate-* или в то время, как ведомый сервер выполняет CHANGE REPLICATION FILTER.

В самом простом случае, когда нет опций --replicate-*, ведомое устройство выполняет все запросы, что оно получает от ведущего устройства. Иначе результат зависит от особых данных опций.

Опции на уровне базы данных (--replicate-do-db , --replicate-ignore-db) проверены сначала, см. раздел 19.2.5.1 для описания этого процесса. Если никакие опции на уровне базы данных не используются, проверка опции переходит к любым опциям на уровне таблицы, которые могут использоваться (см. раздел 19.2.5.2). Если одна или более опций на уровне базы данных используются, но ни одна не соответствует, запрос не копируется.

Для запросов, затрагивающих только базы данных (то есть, CREATE DATABASE, DROP DATABASE и ALTER DATABASE), опции на уровне базы данных всегда имеют приоритет перед любыми --replicate-wild-do-table. Другими словами, для таких запросов --replicate-wild-do-table проверены, если и только если нет никаких опций на уровне базы данных, которые применяются. Это изменение в поведении от предыдущих версий MySQL, где запрос CREATE DATABASE dbx не копировался, если ведомое устройство было запущено с --replicate-do-db=dbx --replicate-wild-do-table=db%.t1 (Bug #46110).

Чтобы облегчить определять, какой эффект будет иметь набор опций, рекомендуется, чтобы Вы избегали смешивать опции do и ignore или неподстановочные и подстановочные.

Если любые опции --replicate-rewrite-db были определены, они применены перед --replicate-*.

В MySQL 8.0 все опции фильтрации репликации следуют тем же самым правилам для чувствительности к регистру, которые относятся к названиям баз данных и таблиц в другом месте в сервере MySQL, включая эффекты lower_case_table_names.

Это изменение от предыдущих версий MySQL (Bug #51639).

19.2.5.1. Оценка репликации на уровне базы данных и опций двоичного журналирования

Оценивая опции репликации, ведомое устройство начинает с проверки, есть ли какие-то --replicate-do-db или --replicate-ignore-db. Используя --binlog-do-db или --binlog-ignore-db, процесс подобен, но опции проверены на ведущем устройстве.

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

Вовлеченные шаги перечислены здесь:

  1. Есть ли любые --replicate-do-db ?

  2. Есть ли любая опция --replicate-ignore-db?
  3. Продолжите двигаться к проверке опций репликации на уровне таблицы, если они есть. Для описания того, как эти опции проверены, см. раздел 19.2.5.2.

    Запрос, который все еще разрешен на данном этапе, фактически еще не выполнен. Запрос не выполнен, пока все опции на уровне таблицы (если есть) не были также проверены, и результат этого процесса разрешает выполнение запроса.

    Для двоичного журналирования вовлеченные шаги перечислены здесь:

    1. Есть ли любые опции --binlog-do-db или --binlog-ignore-db?

      • Да. Перейти на шаг 2.

      • Нет. Зарегистрировать запрос.

    2. Есть ли база данных по умолчанию (имеется любая база данных, выбранная USE)?

      • Да. Перейти на шаг 3.

      • Нет. Проигнорировать запрос.

    3. Есть база данных по умолчанию. Есть ли любая опция --binlog-do-db ?

      • Да. Какая-либо из них соответствует базе данных?

        • Да. Зарегистрировать запрос.

        • Нет. Проигнорировать запрос.

      • Нет. Перейти на шаг 4.

    4. Любая из опций --binlog-ignore-db соответствуют базе данных?

      • Да. Проигнорировать запрос.

      • Нет. Зарегистрировать запрос.

    Для основанного на запросе журналирования исключение сделано в правилах, для CREATE DATABASE, ALTER DATABASE и DROP DATABASE. В тех случаях база данных заменяет базу данных по умолчанию определяя, зарегистрировать или проигнорировать обновления.

    --binlog-do-db может иногда означать игнорировать другие базы данных . Например, используя основанное на запросе журналирование, сервер, работающий только с --binlog-do-db=sales не пишет в двоичный журнал запросы, для которых база данных по умолчанию отличается от sales. Используя основанное на строке журналирование с той же самой опцией, сервер регистрирует только обновления об изменении в sales.

    19.2.5.2. Оценка опций репликации на уровне таблицы

    Ведомое устройство проверяет и оценивает табличные опции, только если любое из следующих двух условий истина:

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

    Для основанной на запросе репликации события представляют запросы (все изменения, составляющие данное событие, связаны с единственным запросом SQL), для основанной на строке репликации каждое событие представляет изменение в единственной строке таблицы (таким образом, единственный запрос, такой как UPDATE mytable SET mycol = 1 может привести ко многим основанным на строке событиям). Когда рассматривается с точки зрения событий, процесс проверки опций таблицы тот же самый для основанной на строке и для основанной на запросе репликации.

    Достигнув этой точки, если нет никаких табличных опций, ведомое устройство просто запускает все события. Если есть --replicate-do-table или --replicate-wild-do-table, событие должно соответствовать одной из них, если это должно быть выполнено, иначе это проигнорировано. Если есть --replicate-ignore-table или --replicate-wild-ignore-table, все события запущены кроме тех, которые соответствуют любой из этих опций. Этот процесс проиллюстрирован на следующей диаграмме.

    Следующие шаги описывают эту оценку более подробно:

    1. Есть ли какие-либо табличные опции?

      • Да. Перейти на шаг 2.

      • Нет. Выполнить событие.

    2. Есть ли любая опция --replicate-do-table?

      • Да. Таблица соответствует какой-то из них?

        • Да. Выполнить событие.

        • Нет. Перейти на шаг 3.

      • Нет. Перейти на шаг 3.

    3. Есть ли любая опция --replicate-ignore-table?

      • Да. Таблица соответствует какой-то из них?

        • Да. Проигнорировать событие.

        • Нет. Перейти на шаг 4.

      • Нет. Перейти на шаг 4.

    4. Есть ли любая опция --replicate-wild-do-table?

      • Да. Таблица соответствует какой-то из них?

        • Да. Выполнить событие.

        • Нет. Перейти на шаг 5.

      • Нет. Перейти на шаг 5.

    5. Есть ли любая опция --replicate-wild-ignore-table?

      • Да. Таблица соответствует какой-то из них?

        • Да. Проигнорировать событие.

        • Нет. Перейти на шаг 6.

      • Нет. Перейти на шаг 6.

    6. Есть ли любая опция --replicate-do-table или --replicate-wild-do-table?

      • Да. Проигнорировать событие.

      • Нет. Выполнить событие.

    19.2.5.3. Правила репликации

    Этот раздел обеспечивает дополнительное объяснение и примеры использования для различных комбинаций опций фильтрации репликации.

    Некоторые типичные комбинации типов правила фильтра репликации даны в следующей таблице:

    Выражение (типы опций) Результат
    Нет опций --replicate-* вообще: Ведомое устройство запускает все события, которые оно получает от ведущего устройства.
    Опции --replicate-*-db есть, но нет табличных опций: Ведомое устройство принимает или игнорирует события, используя опции базы данных. Это запускает все события, разрешенные теми опциями, потому что нет никаких табличных ограничений.
    Есть опции --replicate-*-table, но нет опций базы данных:Все события приняты на проверяющем базу данных этапе, потому что нет никаких условий базы данных. Ведомое устройство запускает или игнорирует события, базируемые исключительно на табличных опциях.
    Комбинация опций базы данных и таблицы: Ведомое устройство принимает или игнорирует события, используя опции базы данных. Тогда это оценивает все события, разрешенные теми опциями согласно табличным опциям. Это может иногда приводить к результатам, которые кажутся парадоксальными, и может отличаться в зависимости от того, используете ли Вы основанную на запросе или строке репликацию, см. текст для примера.

    Более сложный пример следует, в котором мы исследуем результаты и настройки, основанные на запросе и строке.

    Предположите, что у нас есть две таблицы mytbl1 в базе данных db1 и mytbl2 в базе данных db2 на ведущем устройстве, и ведомое устройство работает со следующими опциями (и ни с какими другими опциями фильтрации репликации):

    replicate-ignore-db = db1
    replicate-do-table= db2.tbl2
    

    Теперь мы выполняем следующие запросы на ведущем устройстве:

    USE db1;
    INSERT INTO db2.tbl2 VALUES (1);
    

    Результаты на ведомом устройстве изменяются значительно в зависимости от двоичного формата журнала и, возможно, не соответствуют начальным ожиданиям в любом случае.

    Основанная на запросе репликация. USE указывает db1 быть базой данных по умолчанию. Таким образом, --replicate-ignore-db соответствует и INSERT проигнорирован. Табличные опции не проверены.

    Основанная на строке репликация. База данных по умолчанию не имеет никакого эффекта на то, как ведомое устройство читает опции базы данных, используя основанную на строке репликацию. Таким образом, USE не имеет никакого значения в том, как --replicate-ignore-db обработана, база данных, определенная этой опцией, не соответствует базе данных, где INSERT меняет данные, таким образом, ведомое устройство продолжает проверять табличные опции. Таблица, определенная --replicate-do-table, соответствует таблице, которая будет обновлена, и строка вставлена.

    19.3. Решения для репликации

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

    Для информации об использовании репликации в резервной окружающей среде, включая примечания по установке и резервной процедуре, см. раздел 19.3.1.

    Чтобы обезопасить Вашу коммуникацию репликации, Вы можете зашифровать канал связи. Для инструкций см. раздел 19.3.9 .

    19.3.1. Использование репликации для резервных копий

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

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

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

    19.3.1.1. Поддержка ведомого устройства используя mysqldump

    Использование mysqldump , чтобы создать копию базы данных позволяет Вам получить все данные в базе данных в формате, который позволяет информации быть импортированной в другой MySQL Server (см. раздел 5.5.4). Поскольку формат информации это запросы SQL, файл может легко быть распределен на рабочие серверы, когда Вы нуждаетесь в доступе к данным в чрезвычайной ситуации. Однако, если размер Вашего набора данных является очень большим, mysqldump может быть непрактичным.

    Используя mysqldump , Вы должны остановить репликацию на ведомом устройстве прежде, чем запустить процесс дампа, чтобы гарантировать, что дамп содержит непротиворечивое множество данных:

    1. Остановите обработку запросов на ведомом. Вы можете остановить репликацию полностью на ведомом устройстве, используя mysqladmin :

      shell> mysqladmin stop-slave
      

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

      shell> mysql -e 'STOP SLAVE SQL_THREAD;'
      

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

    2. Выполните mysqldump , чтобы вывести Ваши базы данных в дамп. Вы можете вывести все базы данных или выбрать базы данных, которые будут выведены. Например, чтобы вывести все базы данных:
      shell> mysqldump --all-databases > fulldb.dump
      
    3. Как только дамп завершился, запустите ведомые операции снова:
      shell> mysqladmin start-slave
      

    В предыдущем примере Вы можете хотеть добавить параметры входа в систему (имя пользователя, пароль) к командам и связать процесс в скрипт, который Вы можете выполнять автоматически каждый день.

    Если Вы используете этот подход, удостоверьтесь, что Вы контролируете ведомый процесс репликации, чтобы гарантировать, что время, потраченное, чтобы выполнить резервное копирование, не затрагивает способность ведомого устройства не отставать от событий от ведущего устройства. См. раздел 19.1.7.1. Если ведомое устройство неспособно поддержать производительность на высоком уровне, Вы можете хотеть добавить другое ведомое устройство и распределить резервный процесс. Для примера того, как сконфигурировать этот сценарий, см. раздел 19.3.6.

    19.3.1.2. Поддержка необработанных данных от ведомого устройства

    Чтобы гарантировать целостность файлов, которые скопированы, поддерживая файлы необработанных данных на Вашем ведомом устройстве репликации MySQL, это должно иметь место в то время, как Ваш ведомый сервер закрыт. Если сервер MySQL все еще работает, фоновые задачи могут все еще обновлять файлы базы данных, особенно те, которые вовлекают механизмы хранения с фоновыми процессами, например, InnoDB. С InnoDB эти проблемы должны быть решены во время восстановления катастрофического отказа, но так как ведомый сервер может быть закрыт во время резервного процесса, не затрагивая выполнение ведущего устройства, имеет смысл использовать в своих интересах эту способность.

    Закрыть сервер и зарезервировать файлы:

    1. Закройте ведомый сервер MySQL:

      shell> mysqladmin shutdown
      
    2. Скопируйте файлы с данными. Вы можете использовать любое подходящее копирование, включая cp, tar или WinZip. Например, предполагая, что каталог данных расположен под текущим каталогом, Вы можете заархивировать весь каталог следующим образом:
      shell> tar cf /tmp/dbbackup.tar ./data
      
    3. Запустите сервер MySQL снова. Под Unix:
      shell> mysqld_safe &
      

      В Windows:

      C:\> "C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqld"
      

    Обычно Вы должны поддержать весь каталог данных для ведомого сервера MySQL. Если Вы хотите быть в состоянии восстановить данные и действовать в качестве ведомого устройства (например, в случае отказа ведомого устройства), то в дополнение к данным ведомого устройства, Вы должны также поддержать ведомые файлы состояния, основную информацию и репозитарии информации журнала реле и файлы системного журнала реле. Эти файлы необходимы, чтобы возобновить репликацию после того, как Вы восстанавливаете данные ведомого устройства.

    Если Вы теряете журналы реле, но все еще имеете файл relay-log.info, Вы можете проверить это, чтобы определить, как далеко поток SQL ушел в основных двоичных журналах. Тогда Вы можете использовать CHANGE MASTER TO с опциями MASTER_LOG_FILE и MASTER_LOG_POS. Это требует, чтобы двоичные журналы все еще существовали на главном сервере.

    Если Ваше ведомое устройство копирует LOAD DATA INFILE, Вы должны также поддержать файлы SQL_LOAD-*, которые существуют в каталоге, который ведомое устройство использует с этой целью. Ведомое устройство нуждается в этих файлах, чтобы возобновить репликацию любого прерванного LOAD DATA INFILE. Местоположение этого каталога это значение опции --slave-load-tmpdir. Если сервер не был запущен с этой опцией, местоположение каталога это значение переменной tmpdir.

    19.3.1.3. Поддержка ведущего или ведомого устройства, делая его только для чтения

    Возможно поддержать основные или ведомые серверы в установке репликации, приобретая глобальную блокировку чтения и управляя переменной read_only, чтобы изменить статус "только для чтения" сервера, который будет сохранен:

    1. Сделайте сервер только для чтения, так, чтобы он обработал только извлечения и заблокировал обновления.

    2. Выполните резервное копирование.
    3. Измените сервер назад на его нормальный статус чтения-записи.

    Инструкции в этом разделе помещают сервер, который будет поддержан, в статус, который безопасен для резервных методов, которые получают данные от сервера, таких как mysqldump (см. раздел 5.5.4). Вы не должны пытаться использовать эти инструкции, чтобы сделать двоичное резервное копирование, копируя файлы непосредственно, потому что сервер, возможно, все еще изменяет данные, кэшируемые в памяти, и не сбросил их на диск.

    Следующие инструкции описывают, как сделать это для главного сервера и для ведомого сервера. Для обоих сценариев, обсужденных здесь, предположите, что у Вас есть следующая установка репликации:

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

    Сценарий 1: Резервное копирование с ведущим устройством только для чтения

    Поместите ведущее устройство М1 в статус только для чтения, выполняя эти запросы:

    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SET GLOBAL read_only = ON;
    

    В то время как M1 находится в состоянии только для чтения, следующие свойства истина:

    В то время как M1 только для чтения, выполните резервное копирование. Например, Вы можете использовать mysqldump.

    После того, как резервная работа на M1 завершается, восстановите M1 к его нормальному рабочему состоянию, выполняя эти запросы:

    mysql> SET GLOBAL read_only = OFF;
    mysql> UNLOCK TABLES;
    

    Хотя выполнение резервного копирования на M1 безопасно, это не оптимально для работы, потому что клиенты M1 заблокированы на выполнение обновлений.

    Эта стратегия относится к поддержке главного сервера в установке репликации, но может также использоваться для единственного сервера в установке нерепликации.

    Сценарий 2: Резервное копирование с ведомым устройством только для чтения

    Поместите ведомого S1 в статус только для чтения, выполняя эти запросы:

    mysql> FLUSH TABLES WITH READ LOCK;
    mysql> SET GLOBAL read_only = ON;
    

    В то время как S1 находится в состоянии только для чтения, следующие свойства истина:

    Эти свойства обеспечивают основание для популярного резервного сценария: наличие одного ведомого занятого выполнением резервного копирования некоторое время не является проблемой, потому что это не затрагивает всю сеть, и система все еще работает во время резервного копирования. В частности, клиенты могут все еще выполнить обновления на главном сервере, который остается не затронут резервной деятельностью на ведомом устройстве.

    В то время как S1 только для чтения, выполните резервное копирование. Например, Вы можете использовать mysqldump.

    После того, как резервная работа на S1 завершается, восстановите S1 к его нормальному рабочему состоянию, выполняя эти запросы:

    mysql> SET GLOBAL read_only = OFF;
    mysql> UNLOCK TABLES;
    

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

    19.3.2. Обработка неожиданного останова ведомого устройства репликации

    Для репликации, чтобы быть эластичной к неожиданным остановам сервера (иногда описываемой как безопасной от катастрофического отказа) для ведомого устройства должно быть возможно возвратить свой статус перед остановкой. Этот раздел описывает воздействие неожиданного останова ведомого устройства во время репликации и как сконфигурировать ведомое устройство для лучшей возможности восстановления.

    После неожиданного останова ведомого устройства при перезапуске поток ввода/вывода должен возвратить информацию, о которой были получены транзакции, и поток SQL должен установить, какие транзакции уже были выполнены. Для информации о ведомых журналах, требуемых для восстановления, см. раздел 19.2.4. Информация, требуемая для восстановления, традиционно хранилась в файлах, у которых был риск сбоя синхронизации с ведущим устройством, зависящим от того, на котором этапе обработки транзакции ведомое устройство остановилось. В MySQL 8.0 Вы можете вместо этого использовать таблицы, чтобы хранить эту информацию. Эти таблицы составлены, используя InnoDB, и при использовании этого транзакционного механизма хранения информация всегда восстанавливаема. Чтобы сконфигурировать MySQL 8.0, чтобы хранить информацию репликации в таблицах, надо установить переменные relay_log_info_repository и master_info_repository в TABLE. Сервер тогда хранит информацию, требуемую для восстановления потока ввода/вывода в таблице mysql.slave_master_info а информацию для восстановления потока SQL в таблице mysql.slave_relay_log_info.

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

    Таблица 19.5. Факторы, влияющие на восстановление однопоточного ведомого.

    GTID

    MASTER_AUTO_POSITION

    relay_log_recovery

    relay_log_info_repository

    Тип катастрофического отказа

    Восстановление гарантировано?

    Воздействие на журнал реле

    OFF

    Любой

    1

    TABLE

    Любой

    Да

    Потерян

    OFF

    Любой

    1

    TABLE

    Server

    Да

    Потерян

    OFF

    Любой

    1

    Любой

    OS

    Нет

    Потерян

    OFF

    Любой

    0

    TABLE

    Server

    Да

    Остается

    OFF

    Любой

    0

    TABLE

    OS

    Нет

    Остается

    ON

    ON

    Любой

    Любой

    Любой

    Да

    Потерян

    ON

    OFF

    0

    TABLE

    Server

    Да

    Остается

    ON

    OFF

    0

    Любой

    OS

    Нет

    Остается

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

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

    Таблица 19.6. Факторы, влияющие на восстановление мультипоточного ведомого

    GTID

    sync_relay_log

    MASTER_AUTO_POSITION

    relay_log_recovery

    relay_log_info_repository

    Тип повреждения

    Восстановление гарантируется?

    Воздействие на журнал реле

    OFF

    1

    Любой

    1

    TABLE

    Любой

    Да

    Потерян

    OFF

    >1

    Любой

    1

    TABLE

    Server

    Да

    Потерян

    OFF

    >1

    Любой

    1

    Любой

    OS

    Нет

    Потерян

    OFF

    1

    Любой

    0

    TABLE

    Server

    Да

    Остается

    OFF

    1

    Любой

    0

    TABLE

    OS

    Нет

    Остается

    ON

    Любой

    ON

    Любой

    Любой

    Любой

    Да

    Потерян

    ON

    1

    OFF

    0

    TABLE

    Server

    Да

    Остается

    ON

    1

    OFF

    0

    Любой

    OS

    Нет

    Остается

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

    Важно отметить воздействие sync_relay_log=1 , который требует записи в журнал реле на транзакцию. Хотя эта установка является самой эластичной к неожиданному останову, с самое большее одной ненаписанной потерянной транзакцией, у этого также есть потенциал, чтобы очень увеличить загрузку на диск. Без sync_relay_log=1 эффект неожиданного останова зависит от того, как журнал реле обработан операционной системой. Также отметьте, что когда relay_log_recovery=0 и ведомое устройство запущено после неожиданного останова, журнал реле обработан как часть восстановления. После того как этот процесс завершается, журнал реле удален.

    Неожиданный останов мультипоточного ведомого устройства репликации и использование рекомендуемой позиции файла может привести к журналу реле с операционными несогласованностями (промежутки в последовательности транзакций), вызванными неожиданным остановом. См. раздел 19.4.1.34. В MySQL 5.7.13 и позже, если процесс восстановления журнала реле сталкивается с такими операционными несогласованностями, процесс восстановления продолжается автоматически. В версиях MySQL до 5.7.13 этот процесс не является автоматическим и требует запуска сервера с relay_log_recovery=0 , запуска ведомого устройства с START SLAVE UNTIL SQL_AFTER_MTS_GAPS, чтобы исправить любые операционные несогласованности и затем перезапуска ведомого устройства с relay_log_recovery=1 .

    Когда Вы используете мультирепликацию и relay_log_recovery=1 , после перезапуска из-за неожиданного останова все каналы репликации проходят процесс восстановления журнала реле. Любые несогласованности, найденные в журнале реле из-за неожиданного останова мультипоточного ведомого устройства, заполнены.

    19.3.3. Контроль основанной на строке репликации

    В MySQL 5.7.16 и позже текущее продвижение потока SQL репликации, используя основанную на строке репликацию проверено через инструменты Performance Schema, позволяя Вам отследить обработку операций и проверить завершенный объем работы и оценить работу. Когда эти инструментальные этапы Performance Schema включены, таблица events_stages_current показывает этапы для потоков и их продвижения. Для вводной информации см. раздел 23.9.5.

    Чтобы отследить продвижение всех трех основанных на строке типов репликации событий (write, update, delete):

    19.3.4. Используя репликацию с различными основными и ведомыми механизмами хранения

    Не имеет значения для процесса репликации, используют ли исходная таблица на ведущем устройстве и копируемая таблица на ведомом различный механизм. Фактически переменная default_storage_engine не копируется.

    Это обеспечивает много выгод в процессе репликации, в котором Вы можете использовать в своих интересах различные типы механизма для различных сценариев репликации. Например, в типичном сценарии масштаба (см. раздел 19.3.5) Вы хотите использовать InnoDB на ведущем устройстве, чтобы использовать в своих интересах транзакционную функциональность, но MyISAM на ведомых устройствах, где операционная поддержка не требуется, потому что данные только считаны. Используя репликацию в регистрирующей данные окружающей среде, Вы можете хотеть использовать на ведомом устройстве Archive.

    Конфигурирование различных механизмов на ведущем устройстве и ведомом устройстве зависит от того, как Вы настраиваете начальный процесс репликации:

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

    1. Запретите ведомому устройству выполнить обновления репликации:

      mysql> STOP SLAVE;
      

      Это позволит Вам изменить типы механизма без прерываний.

    2. Выполните ALTER TABLE ... ENGINE='engine_type ' для каждой таблицы, которая будет изменена.
    3. Запустите ведомый процесс репликации снова:
      mysql> START SLAVE;
      

    Хотя default_storage_engine не копируется, надо знать, что CREATE TABLE и ALTER TABLE, которые включают спецификацию механизма, будут правильно копироваться к ведомому устройству. Например, если у Вас есть таблица CSV, и Вы выполняете:

    mysql> ALTER TABLE csvtable Engine='MyISAM';
    

    Вышеупомянутый запрос будет копироваться к ведомому устройству, и тип механизма на ведомом устройстве будет преобразован в MyISAM, даже если Вы ранее изменили табличный тип на ведомом устройстве. Если Вы хотите сохранить различия в механизме на ведущем устройстве и ведомом устройстве, Вы должны использовать default_storage_engine на ведущем устройстве, составляя новую таблицу. Например, вместо:

    mysql> CREATE TABLE tablea (columna int) Engine=MyISAM;
    

    Используйте этот формат:

    mysql> SET default_storage_engine=MyISAM;
    mysql> CREATE TABLE tablea (columna int);
    

    Когда копируется, default_storage_engine будет проигнорирована, и CREATE TABLE выполнится на ведомом устройстве, используя механизм по умолчанию ведомого устройства.

    19.3.5. Использование репликации для масштаба

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

    Поскольку репликация работает от распределения одного ведущего устройства к одному или более ведомым устройствам, использовать репликация для работ масштаба лучше всего в окружающей среде, где у Вас есть высокое число чтений и низкое число обновлений. Большинство веб-сайтов вписываются в эту категорию, где пользователи просматривают сайт, читая статьи, сообщения или рассматривая продукты. Обновления происходят только во время управления сеансом, делая покупку или добавляя комментарий/сообщение к форуму.

    Репликация в этой ситуации позволяет Вам распределить чтения по ведомым устройствам репликации, все еще позволяя Вашим веб-серверам общаться с ведущим устройством репликации, когда нужна запись. Вы можете видеть типовое расположение репликации для этого сценария на рис. 19.1.

    Рис. 19.1. Использование репликации, чтобы улучшить работу

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

    safe_ в каждом имени функции говорит, что функция заботится об обработке всех состояний ошибки. Вы можете использовать различные названия функций. Важная вещь состоит в том, чтобы иметь объединенный интерфейс для того, чтобы соединиться для чтений и записей.

    Тогда преобразуйте свой код клиента, чтобы пользоваться библиотекой обертки. Это может быть болезненным и страшным процессом сначала, но это окупается в конечном счете. Все приложения, которые используют только что описанный подход, в состоянии использовать в своих интересах основную/ведомую конфигурацию, даже вовлекающие многократные ведомые устройства. Код намного легче поддержать, поиск неисправностей тривиален. Вы должны изменить только одну или две функции, например, чтобы зарегистрировать, сколько времени каждый запрос взял, или какой запрос среди выпущенных дал Вам ошибку.

    Если Вы написали много кода, Вы можете хотеть автоматизировать конверсионную задачу при использовании утилиты replace, которая идет со стандартными пакетами MySQL, или напишите свой собственный конверсионный скрипт. Идеально, если Ваш код использует последовательные программные соглашения стиля.

    19.3.6. Мультиплицирование различных баз данных к различным ведомым устройствам

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

    Рис. 19.2. Использование репликации, чтобы копировать базы данных, чтобы отделить ведомые устройства репликации

    Вы можете достигнуть этого разделения, конфигурируя ведущее устройство и ведомые устройства как обычно, затем ограничивая двоичные запросы журнала, которые каждое ведомое устройство обрабатывает при использовании --replicate-wild-do-table на каждом ведомом устройстве.

    Вы не должны использовать --replicate-do-db с этой целью, используя основанную на запросе репликацию, так как основанная на запросе репликация заставляет эффекты этой опции изменяться согласно базе данных, которая в настоящее время выбирается. Это относится к репликации смешанного формата также, так как это позволяет некоторым обновлениям копироваться, используя основанный на запросе формат.

    Однако, должно быть безопасно использовать --replicate-do-db с этой целью, если Вы используете только основанную на строке репликацию, так как в этом случае в настоящее время выбираемая база данных не имеет никакого влияния на работу опции.

    Например, чтобы поддержать разделение как показано на рис. 19.2, Вы должны сконфигурировать каждое ведомое устройство репликации следующим образом, перед выполнением START SLAVE :

    Каждое ведомое устройство в этой конфигурации получает весь двоичный журнал от ведущего устройства, но запускает только те события, которые относятся к базам данных и таблицам, включенным на том ведомом устройстве опцией --replicate-wild-do-table.

    Если у Вас есть данные, которые должны быть синхронизированы к ведомым устройствам прежде, чем репликация запустится, у Вас есть выбор:

    19.3.7. Улучшение работы репликации

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

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

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

    Рис. 19.3. Использование дополнительного узла репликации, чтобы улучшить работу

    Вы должны сконфигурировать экземпляры MySQL следующим образом:

    Вышеупомянутое решение уменьшает загрузку клиента и сетевого интерфейса на основном ведущем устройстве, что должно улучшить эффективность работы основного ведущего устройства, когда используется в качестве прямого решения для базы данных.

    Если Ваши ведомые устройства испытывают затруднения, отставая от процесса репликации на ведущем устройстве, есть много доступных опций:

    19.3.8. Переключающиеся ведущие устройства

    Используя репликацию с GTID (см. раздел 19.1.3), Вы можете обеспечить переключение между ведущим и ведомыми устройствами в случае отказа, используя mysqlfailover, который обеспечен MySQL Utilities, см. mysqlfailover. Если Вы не используете GTID и поэтому не можете использовать mysqlfailover, Вы должны настроить ведущее устройство и одно или более ведомых устройств, Вы должны также написать приложение или скрипт, который контролирует ведущее устройство, чтобы проверить, работает ли оно, и инструктирует ведомые устройства и приложения изменяться на другое ведущее устройство в случае отказа. Этот раздел обсуждает некоторые из проблем, с которыми сталкиваются, настраивая систему таким образом.

    Вы можете сказать ведомому устройству изменяться на новое ведущее устройство, используя CHANGE MASTER TO. Ведомое устройство не проверяет, совместимы ли базы данных по ведущему устройству, это просто начинает читать и запускать события от указанных координат в двоичном журнале нового ведущего устройства. Все серверы в группе, как правило, запускают те же самые события от того же самого двоичного файла системного журнала, так что изменение источника событий не должно затронуть структуру или целостность базы данных при условии, что Вы осуществляете заботу о произведении изменения.

    Ведомые устройства должны быть выполнены с --log-bin, если они не используют GTID, тогда они должны также быть выполнены без --log-slave-updates. Таким образом, ведомое устройство готово стать ведущим устройством, не перезапуская ведомое устройство mysqld. Предположите, что Вам показали структуру на рис. 19.4.

    Рис. 19.4. Использование начальной структуры репликации

    В этой диаграмме MySQL Master содержит основную базу данных, узлы MySQL Slave это ведомые устройства репликации, а Web Client ведут чтения и записи базы данных. Веб-клиенты, которые выпускают только чтения (и обычно соединялись бы с ведомыми устройствами), не показывают, поскольку они не должны переключиться на новый сервер в случае отказа. Для более подробного примера структуры репликации масштаба чтения-записи см. раздел 19.3.5.

    Каждый MySQL Slave (Slave 1, Slave 2 и Slave 3) это ведомое устройство, работающее с --log-bin и без --log-slave-updates. Поскольку обновления, полученные ведомым устройством от ведущего не зарегистрированы в двоичный журнал, если задана --log-slave-updates, каждое ведомое устройство пусто первоначально. Если по некоторым причинам MySQL Master становится недоступным, Вы можете выбрать одно из ведомых устройств, чтобы стать новым ведущим устройством. Например, если Вы выбираете Slave 1 , все Web Clients должны быть перенаправлены к Slave 1, который пишет обновления его двоичного журнала. Slave 2 и Slave 3 должны тогда копировать от Slave 1.

    Причина выполнения ведомого устройства без --log-slave-updates необходимость препятствовать тому, чтобы ведомые устройства получили обновления дважды в случае, если Вы заставляете одно из ведомых устройств становиться новым ведущим устройством. Если Slave 1 имеет включенную опцию --log-slave-updates, это пишет любые обновления, которые получает от Master в его собственный двоичный журнал. Это означает, что когда Slave 2 меняется от Master на Slave 1 как его ведущее устройство, это может получить обновления из Slave 1, которые это уже получило от Master .

    Удостоверьтесь, что все ведомые устройства обработали любые запросы в своем журнале реле. На каждом ведомом устройстве выполните STOP SLAVE IO_THREAD, проверьте вывод SHOW PROCESSLIST, пока Вы не увидите Has read all relay log. Когда это истина для всех ведомых устройств, они могут быть реконфигурированы к новой установке. На ведомом устройстве Slave 1, чтобы стать ведущим устройством, выполните STOP SLAVE и RESET MASTER.

    На других ведомых устройствах Slave 2 и Slave3, используйте STOP SLAVE и CHANGE MASTER TO MASTER_HOST='Slave1' (где 'Slave1' представляет реальное имя хоста Slave 1). Чтобы применить CHANGE MASTER TO, добавьте всю информацию о том, как соединиться с Slave 1 из Slave 2 или Slave 3 (user, password, port). Командуя CHANGE MASTER TO, нет никакой потребности определить название файла системного журнала или позицию журнала на Slave 1 : начало первого файла двоичного системного журнала и позиция 4 являются значениями по умолчанию. Наконец, надлежит выполнить START SLAVE на машинах Slave 2 и Slave 3.

    Как только новая установка репликации находится где должна, Вы должны сказать каждому из Web Client направить его запросы на Slave 1. Теперь все запросы обновлений, посланные Web Client к Slave 1 написаны двоичному журналу Slave 1, который содержит каждый запрос обновления, посланный в Slave 1 после отказа Master.

    Получающяяся структура серверов показана на рис. 19.5.

    Рис. 19.5. Использование репликации после сбоя

    Когда Master становится доступным снова, Вы должны сделать его ведомым устройством Slave 1. Чтобы сделать это, на Master выполните CHANGE MASTER TO как ранее на Slave 2 и Slave 3. Master становится ведомым устройством S1ave 1 и пишет события за время своего отключения.

    Чтобы сделать Master ведущим устройством снова, используйте предыдущую процедуру как будто Slave 1 недоступно и Master должно быть новым ведущим устройством. Во время этой процедуры не забывайте выполнить RESET MASTER на Master прежде, чем сделать Slave 1, Slave 2 и Slave 3 ведомыми устройствами Master. Если Вы не в состоянии сделать это, ведомые устройства могут устаревшее состояние до пункта, в котором Master стал недоступным.

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

    Один способ держать приложения в курсе местоположения ведущего устройства состоит в том, чтобы иметь динамическую запись DNS для ведущего устройства. С bind можно применить nsupdate, чтобы обновить DNS динамически.

    19.3.9. Настройка репликации, чтобы использовать безопасные соединения

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

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

    См. раздел 7.4.4.

    Чтобы включить безопасные соединения на ведущем устройстве, Вы должны создать или получить подходящий сертификат и ключевые файлы, затем добавить следующие параметры к конфигурации ведущего устройства в пределах раздела [mysqld] файл my.cnf ведущего устройства, изменяя имена файлов по мере необходимости:

    [mysqld]
    ssl-ca=cacert.pem
    ssl-cert=server-cert.pem
    ssl-key=server-key.pem
    

    Пути к файлам могут быть относительными или абсолютными, мы рекомендуем, чтобы Вы всегда использовали полные пути.

    Опции здесь следующие:

    На ведомом устройстве есть два способа определить информацию, запрошенную для того, чтобы соединиться надежно с ведущим устройством. Вы можете назвать ведомый сертификат и ключевые файлы в разделе [client] файла my.cnf ведомого устройства или Вы можете явно определить ту информацию, используя CHANGE MASTER TO:

    После того, как основная информация была обновлена, запустите ведомый процесс репликации:

    mysql> START SLAVE;
    

    Вы можете использовать SHOW SLAVE STATUS, чтобы подтвердить, что безопасное соединение было установлено успешно.

    См. раздел 14.4.2.1.

    Если Вы хотите провести в жизнь использование безопасных соединений во время репликации, надо создать пользователя и использовать опцию REQUIRE SSL, затем предоставить тому пользователю привилегию REPLICATION SLAVE :

    mysql> CREATE USER 'repl'@'%.mydomain.com'
        ->        IDENTIFIED BY 'slavepass' REQUIRE SSL;
    mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com';
    

    Если учетная запись уже существует, Вы можете добавить REQUIRE SSL с этим запросом:

    mysql> ALTER USER 'repl'@'%.mydomain.com' REQUIRE SSL;
    

    19.3.10. Полусинхронная репликация

    В дополнение к встроенной асинхронной репликации, MySQL 8.0 поддерживает интерфейс к полусинхронной репликации, который осуществлен плагинами. Этот раздел обсуждает то, что такое полусинхронная репликация и как это работает. Следующие разделы покрывают административный интерфейс к полусинхронной репликации и как установить, сконфигурировать и контролировать это.

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

    Полусинхронная репликация может использоваться в качестве альтернативы асинхронной репликации:

    В то время как ведущее устройство блокирует (ждет признания от ведомого устройства), оно не возвращается к сеансу, который выполнил транзакцию. Когда блок заканчивается, ведущее устройство возвращается к сеансу, который тогда может продолжить выполнять другие запросы. В этом пункте транзакция передана на основной стороне, и получение ее событий было подтверждено по крайней мере одним ведомым устройством.

    Число признаний, которое ведущее устройство должно получить на транзакцию перед переходом, является конфигурируемым с использованием переменной rpl_semi_sync_master_wait_for_slave_count. По умолчанию 1.

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

    Для запросов, которые не происходят в транзакционном контексте (то есть, когда никакая транзакция не была запущена с START TRANSACTION или SET autocommit = 0), autocommit включен и каждый запрос передается неявно. С полусинхронной репликацией ведущее устройство блокирует для каждого такого запроса, как это делается для явной передачи транзакции.

    Чтобы понять значение "полу" в полусинхронной репликации, сравните это с асинхронной и полностью синхронной репликацией:

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

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

    Полусинхронная репликация действительно оказывает некоторое исполнительное влияние, потому что передачи происходят медленнее из-за потребности ждать ведомые устройства. Это плата за увеличенную целостность данных. Количество замедления по крайней мере, время, чтобы послать по TCP/IP туда и обратно данные ведомому устройству и ждать признания ведомым устройством. Это означает, что полусинхронная репликация работает лучше всего на близких серверах, общающихся по быстрым сетям.

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

    Характеристики репликации этих настроек отличаются следующим образом:

    19.3.10.1. Административный интерфейс полусинхронной репликации

    У административного интерфейса к полусинхронной репликации есть несколько компонентов:

    Переменные состояния доступны, только если соответствующий основной или ведомый плагин был установлен с INSTALL PLUGIN.

    19.3.10.2. Полусинхронная репликация: установка и конфигурация

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

    Этот раздел описывает, как установить полусинхронные плагины репликации. Для общей информации об установке плагинов см. раздел 6.6.2.

    Чтобы использовать полусинхронную репликацию, следующие требования должны быть удовлетворены:

    Чтобы настроить полусинхронную репликацию, используйте следующие инструкции. INSTALL PLUGIN, SET GLOBAL, STOP SLAVE и START SLAVE, упомянутые здесь, требуют привилегии SUPER.

    Дистрибутивы MySQL включают полусинхронные файлы плагина репликации для основной и ведомой сторон.

    Чтобы быть применимым основным или ведомым сервером, соответствующий файл библиотеки должен быть расположен в каталоге плагинов MySQL (каталог, названный переменной plugin_dir ). В случае необходимости, установите значение plugin_dir при запуске сервера, чтобы сказать серверу местоположение каталога.

    Базовые имена файла библиотеки semisync_master и semisync_slave. Суффикс имени файла отличается в зависимости от платформы (например, .so в Unix и .dll в Windows).

    Основной файл библиотеки должен присутствовать в каталоге плагинов главного сервера. Ведомый файл библиотеки должен присутствовать в каталоге плагинов каждого ведомого сервера.

    Чтобы загрузить плагины, используйте INSTALL PLUGIN на ведущем устройстве и на каждом ведомом устройстве, которое должно быть полусинхронным (корректируйте .so для Вашей платформы по мере необходимости).

    На ведущем устройстве:

    INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
    

    На каждом ведомом устройстве:

    INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
    

    Если попытка установить плагин приводит к ошибке в Linux, подобной показанной здесь, Вы должны установить libimf:

    mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
    ERROR 1126 (HY000): Can't open shared library
    '/usr/local/mysql/lib/plugin/semisync_master.so'
    (errno: 22 libimf.so: cannot open shared object file:
    No such file or directory)
    

    Вы можете получить libimf на http://dev.mysql.com/downloads/os-linux.html.

    Чтобы видеть, какие плагины установлены, используйте SHOW PLUGINS или запросите таблицу INFORMATION_SCHEMA.PLUGINS .

    Чтобы проверить установку, исследуйте таблицу INFORMATION_SCHEMA.PLUGINS или используйте SHOW PLUGINS (см. раздел 6.6.3 ):

    mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS
        ->        WHERE PLUGIN_NAME LIKE '%semi%';
    +----------------------+---------------+
    | PLUGIN_NAME          | PLUGIN_STATUS |
    +----------------------+---------------+
    | rpl_semi_sync_master | ACTIVE        |
    +----------------------+---------------+
    

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

    Чтобы управлять, включен ли установленный плагин, устанавливайте соответствующие системные переменные. Вы можете установить эти переменные при использовании во время выполнения SET GLOBAL при запуске сервера в командной строке или в файле опций.

    Во время выполнения эти системные переменные основной стороны доступны:

    SET GLOBAL rpl_semi_sync_master_enabled = {0|1};
    SET GLOBAL rpl_semi_sync_master_timeout = N;
    

    На ведомой стороне эта системная переменная доступна:

    SET GLOBAL rpl_semi_sync_slave_enabled = {0|1};
    

    Для rpl_semi_sync_master_enabled или rpl_semi_sync_slave_enabled значение должно быть 1, чтобы позволить полусинхронную репликацию, или 0, чтобы ее отключить. По умолчанию эти переменные установлены в 0.

    Для rpl_semi_sync_master_timeout значение N дано в миллисекундах. Значение по умолчанию 10000 (10 секунд).

    Если Вы включаете полусинхронную репликацию на ведомом устройстве во время выполнения, Вы должны также запустить ведомый поток ввода/вывода (остановите это сначала, если это уже работает), чтобы заставить ведомое устройство соединяться с ведущим устройством и зарегистрироваться как полусинхронное ведомое устройство:

    STOP SLAVE IO_THREAD;
    START SLAVE IO_THREAD;
    

    Если поток ввода/вывода уже работает, и Вы не перезапускаете его, ведомое устройство продолжает использовать асинхронную репликацию.

    При запуске сервера переменные, которые управляют полусинхронной репликацией, могут быть установлены как параметры командной строки или в файле опции. Установка, перечисленная в файле опции, вступает в силу каждый раз, когда сервер запускается. Например, Вы можете установить переменные в файлах my.cnf на основных и ведомых сторонах следующим образом.

    На ведущем устройстве:

    [mysqld]
    rpl_semi_sync_master_enabled=1
    rpl_semi_sync_master_timeout=1000   # 1 second
    

    На каждом ведомом устройстве:

    [mysqld]
    rpl_semi_sync_slave_enabled=1
    

    19.3.10.3. Полусинхронный контроль репликации

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

    Системная переменная отражает, как полусинхронная репликация сконфигурирована. Чтобы проверить их значения, надо использовать SHOW VARIABLES:

    mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';
    

    Переменные состояния позволяют Вам контролировать работу полусинхронной репликации. Чтобы проверить их значения, надо использовать SHOW STATUS:

    mysql> SHOW STATUS LIKE 'Rpl_semi_sync%';
    

    Когда ведущее устройство переключается между асинхронной или полусинхронной репликацией из-за тайм-аута или наверстывания ведомым, это устанавливает значение Rpl_semi_sync_master_status соответственно. Автоматическое отступление от полусинхронной до асинхронной репликации на ведущем устройстве означает, что возможно для rpl_semi_sync_master_enabled иметь значение 1 на основной стороне, даже когда полусинхронная репликация является фактически не рабочей в настоящее время. Вы можете контролировать Rpl_semi_sync_master_status, чтобы определить, использует ли ведущее устройство в настоящее время асинхронную или полусинхронную репликацию.

    Чтобы видеть, сколько полусинхронных ведомых устройств соединено, надо проверить Rpl_semi_sync_master_clients.

    Число передач, которые были признаны успешно или неудачно ведомыми устройствами, обозначено Rpl_semi_sync_master_yes_tx и Rpl_semi_sync_master_no_tx.

    На ведомой стороне Rpl_semi_sync_slave_status указывает, является ли полусинхронная репликация в настоящее время рабочей.

    19.3.11. Отсроченная репликация

    MySQL 8.0 поддерживает отложенную репликацию, таким образом, что ведомый сервер сознательно отстает от ведущего устройства, по крайней мере, на указанное количество времени. Задержка по умолчанию составляет 0 секунд. Используйте опцию MASTER_DELAY в CHANGE MASTER TO, чтобы установить задержку в to N секунд:

    CHANGE MASTER TO MASTER_DELAY = N;
    

    Событие от ведущего устройства, не запущено, по крайней мере, N секунд после его выполнения на ведущем устройстве. Исключение: нет никакой задержки событий описания формата или ротации файла системного журнала, которые затрагивают только внутреннее состояние потока SQL.

    Отсроченная репликация может использоваться в нескольких целях:

    START SLAVE и STOP SLAVE вступают в силу немедленно и проигнорируют любую задержку. RESET SLAVE сбрасывает задержку к 0.

    SHOW SLAVE STATUS имеет три области, которые предоставляют информацию о задержке:

    Когда ведомый поток SQL ждет задержки прежде, чем запустить событие, SHOW PROCESSLIST показывает State как Waiting until MASTER_DELAY seconds after master executed event.

    19.4. Примечания и подсказки репликации

    19.4.1. Особенности и проблемы репликации

    Следующие разделы предоставляют информацию о том, что поддержано в репликации MySQL и о специфических вопросах и ситуациях, которые могут произойти, копируя определенные запросы.

    Основанная на запросе репликация зависит от совместимости на уровне SQL между ведущим и ведомым устройствами. SBR требует, чтобы любые используемые функции SQL поддерживались ведущим устройством и ведомыми серверами. Например, если Вы используете функцию на главном сервере, которая доступна только в MySQL 8.0 (или позже), Вы не можете копировать к ведомому устройству, которое использует MySQL 5.7 (или ранее).

    Такие несовместимости также могут произойти в пределах ряда выпуска, используя выпуски подготовки производства MySQL. Например, функция SLEEP() доступна, начиная с MySQL 5.0.12. Если Вы используете эту функцию на ведущем устройстве, Вы не можете копировать к ведомому устройству, которое использует MySQL 5.0.11 или ранее.

    Поэтому используйте Generally Available (GA) MySQL для основанной на запросе репликации в производственной установке, так как мы не вводим новые запросы SQL или изменяем их поведение в пределах данного ряда выпуска, как только этот ряд достигает состояния выпуска GA.

    Если Вы планируете использовать основанную на запросе репликацию между MySQL 8.0 и предыдущей серией выпуска MySQL, также хорошая идея консультироваться с выпуском MySQL Reference Manual более раннего ряда выпуска для информации относительно характеристик репликации того ряда.

    С основанной на запросе репликацией MySQL могут быть проблемы с мультиплицированием сохраненных подпрограмм или триггеров. Вы можете избежать этих проблем при использовании основанной на строке репликации MySQL вместо этого. Для подробного списка проблем см. раздел 21.7.

    19.4.1.1. Репликация и AUTO_INCREMENT

    В основанной на запросе репликации AUTO_INCREMENT, LAST_INSERT_ID() и TIMESTAMP сделаны правильно согласно следующим исключениям:

    19.4.1.2. Репликация и таблицы BLACKHOLE

    BLACKHOLE принимает данные, но отказывается от них и не хранит их. Выполняя двоичное журналирование, все вставки к таким таблицам, всегда регистрируются, независимо от формата журналирования. Обновления и удаления обработаны по-другому в зависимости от того, какой формат журналирования применен. С форматом регистрации запросов все воздействие на таблицу BLACKHOLE зарегистрировано, но эффекты проигнорированы. Когда используется основанное на строке журналирование, обновления и удаления к таким таблицам просто пропущены, они не написаны в двоичный журнал. Предупреждение зарегистрировано всякий раз, когда это происходит.

    По этой причине мы рекомендуем, когда Вы копируете к таблицам, используя BLACKHOLE, установить binlog_format в STATEMENT, а не ROW или MIXED.

    19.4.1.3. Репликация и наборы символов

    Следующее относится к репликации между серверами MySQL, которые используют различные наборы символов:

    19.4.1.4. Репликация и CHECKSUM TABLE

    CHECKSUM TABLE возвращает контрольную сумму, которая является расчетной строкой, используя метод, который зависит от формата хранения строки таблицы, который, как гарантируют, не останется тем же самым между выпусками MySQL. Например, формат хранения для временных типов TIME, DATETIME и TIMESTAMP изменен в MySQL 5.6 до MySQL 5.6.5, так что, если таблицы 5.5 обновлены до MySQL 5.6, значение контрольной суммы может измениться.

    19.4.1.5. Репликация CREATE ... IF NOT EXISTS

    MySQL применяет эти правила, когда копирует различные CREATE ... IF NOT EXISTS:

    См. также Bug #45574.

    19.4.1.6. Репликация CREATE TABLE ... SELECT

    Этот раздел обсуждает, как MySQL копирует CREATE TABLE ... SELECT .

    MySQL 8.0 не позволяет CREATE TABLE ... SELECT, чтобы произвести любые изменения в таблицах кроме таблицы, которая составлена запросом. Некоторые более старые версии MySQL разрешали этим запросым делать такое, это означает что, используя основанную на запросе репликацию между MySQL 5.6 или более поздним ведомым устройством и ведущим устройством, выполняющим предыдущую версию MySQL, CREATE TABLE ... SELECT , вызывающий изменения в других таблицах на ведущем устройстве, терпит неудачу на ведомом устройстве, заставляя репликацию остановиться. Чтобы предотвратить это, Вы должны использовать основанную на строке репликацию, переписать незаконное запрос прежде, чем выполнить это на ведущем устройстве или обновить ведущее устройство до MySQL 8.0. Если Вы хотите обновлять ведущее устройство, имейте в виду, что CREATE TABLE ... SELECT терпит неудачу после обновления, если это не переписано, чтобы удалить любые побочные эффекты на других таблицах. Это не проблема, используя основанную на строке репликацию, потому что запрос зарегистрирован как CREATE TABLE с любыми изменениями табличных данных, зарегистрированных, как вставка строк, а не как CREATE TABLE ... SELECT .

    Эти поведения не зависят от версии MySQL:

    Когда целевая таблица существует и задано IF NOT EXISTS, MySQL 8.0 игнорирует запрос полностью; ничто не вставлено или зарегистрировано. Обработка таких запросов в этом отношении изменилась значительно в предыдущих выпусках MySQL, если Вы копируете от MySQL 5.5.6 или ведущего устройства старшего возраста к более новому ведомому устройству, см. Replication of CREATE ... IF NOT EXISTS Statements.

    19.4.1.7. Репликация CREATE SERVER, ALTER SERVER и DROP SERVER

    В MySQL 8.0 CREATE SERVER , ALTER SERVER и DROP SERVER не написаны в двоичный журнал, независимо от двоичного формата журналирования, который используется.

    19.4.1.8. Репликация CURRENT_USER()

    Следующие запросы поддерживают использование CURRENT_USER(), чтобы взять место названия (и, возможно, узел) пользователя или определителя, в таких случаях CURRENT_USER() расширен как и где необходимо:

    Когда CURRENT_USER() или CURRENT_USER используется в качестве определителя в любом из запросов CREATE FUNCTION, CREATE PROCEDURE, CREATE TRIGGER, CREATE EVENT, CREATE VIEW или ALTER VIEW, когда двоичное журналирование включено, функциональная ссылка расширена прежде, чем это будет написано в двоичный журнал, чтобы запрос отнесся к тому же самому пользователю на ведущем и на ведомом устройствах, когда запрос копируется. CURRENT_USER() или CURRENT_USER также расширен до того, как написан в двоичный журнал, когда используется в DROP USER, RENAME USER, GRANT, REVOKE или ALTER EVENT.

    19.4.1.9. Репликация DROP ... IF EXISTS

    DROP DATABASE IF EXISTS, DROP TABLE IF EXISTS и DROP VIEW IF EXISTS всегда копируются, даже если база данных, таблица или представление, которое будет удалено, не существуют на ведущем устройстве. Это должно гарантировать, что объект, который будет удален, не существует на ведущем или на ведомом устройстве, когда ведомое устройство догонит ведущее.

    DROP ... IF EXISTS для сохраненных программ (хранимые процедуры и функции, триггеры и события) также копируются, даже если сохраненная программа, которая будет удалена, не существует на ведущем устройстве.

    19.4.1.10. Репликация с отличающимися табличными определениями на ведущем и ведомом устройствах

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

    Репликация между таблицами, которые разделены по-разному, не поддержана. См. раздел 19.4.1.19 .

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

    19.4.1.10.1. Репликация с большим количеством столбцов на ведущем или ведомом устройстве

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

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

    Примеры. Следующие примеры иллюстрируют некоторые допустимые и недопустимые табличные определения:

    Больше столбцов на ведущем устройстве. Следующие табличные определения допустимы и скопируются правильно:

    master> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
    slave>  CREATE TABLE t1 (c1 INT, c2 INT);
    

    Следующие табличные определения подняли бы ошибку, потому что определения столбцов, характерных для обеих версий таблицы, находятся в различном порядке на ведомом устройстве, чем на ведущем:

    master> CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
    slave>  CREATE TABLE t1 (c2 INT, c1 INT);
    

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

    master> CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);
    slave>  CREATE TABLE t1 (c1 INT, c2 INT);
    

    Больше столбцов на ведомом устройстве. Следующие табличные определения допустимы и cкопируютcя правильно:

    master> CREATE TABLE t1 (c1 INT, c2 INT);
    slave>  CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
    

    Следующие определения поднимают ошибку, потому что столбцы, характерные для обеих версий таблицы, не определены в том же самом порядке:

    master> CREATE TABLE t1 (c1 INT, c2 INT);
    slave>  CREATE TABLE t1 (c2 INT, c1 INT, c3 INT);
    

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

    master> CREATE TABLE t1 (c1 INT, c2 INT);
    slave>  CREATE TABLE t1 (c3 INT, c1 INT, c2 INT);
    

    Следующие табличные определения терпят неудачу, потому что у версии ведомого устройства таблицы есть дополнительные столбцы по сравнению с версией ведущего устройства, и две версии таблицы используют различные типы данных для общего столбца c2:

    master> CREATE TABLE t1 (c1 INT, c2 BIGINT);
    slave>  CREATE TABLE t1 (c1 INT, c2 INT, c3 INT);
    
    19.4.1.10.2. Репликация столбцов, имеющих различные типы данных

    У соответствующих столбцов на ведущем устройстве и копии ведомого устройства той же самой таблицы идеально должен быть тот же самый тип данных. Однако, это не всегда строго проводится в жизнь, пока определенные условия соблюдены.

    Обычно возможно копировать от столбца типа определенных данных к другому столбцу того же самого типа и того же самого размера или ширины или больше. Например, Вы можете копировать от CHAR(10) к другому CHAR(10) или из CHAR(10) в CHAR(25) без любых проблем. В определенных случаях также возможно копировать от столбца, имеющего один тип данных (на ведущем устройстве) к столбцу, имеющему различный тип данных (на ведомом устройстве), когда тип данных версии ведущего устройства столбца копируется на тип, который имеет тот же самый размер или больше на ведомом устройстве, это известно как продвижение признака.

    Продвижение признака может использоваться с основанной на запросе и строке репликацией и не зависит от механизма хранения. Однако, выбор формата журналирования действительно имеет эффект на преобразования типа, которые разрешены, подробные сведения обсуждены позже в этом разделе.

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

    Основанная на запросе репликация. Если бы запрос, выполненный на ведущем устройстве, также выполнился бы успешно на ведомом, это должно также скопироваться нормально. Другими словами, если запрос использует значение, которое совместимо с типом данного столбца на ведомом устройстве, запрос может копироваться. Например, Вы можете вставить любое значение, которое помещается в TINYINT, в столбец BIGINT, из этого следует, что, даже если Вы изменяете тип столбца TINYINT в копии ведомого устройства таблицы на BIGINT, любая вставка в этот столбец на ведущем устройстве, которое преуспевает, должна также преуспеть на ведомом устройстве, так как невозможно иметь TINYINT, которое является достаточно большим, чтобы превысить BIGINT.

    Основанная на строке репликация: продвижение признака. Основанная на строке репликация в MySQL 8.0 поддерживает продвижение между меньшими типами данных и большими типами. Также возможно определить, преобразование с потерями или нет удаленных для значений столбцов, как объяснено позже в этом разделе.

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

    Конверсионные режимы (переменная slave_type_conversions). Глобальная переменная сервера slave_type_conversions управляет конверсионным режимом типа, используемым на ведомом устройстве. Эта переменная берет ряд значений от следующей таблицы, которая показывает эффекты каждого режима на поведении преобразования типа ведомого устройства:

    Режим Эффект
    ALL_LOSSY

    В этом режиме разрешены преобразования, которые означали бы, что потеря информации разрешена.

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

    ALL_NON_LOSSY

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

    У установки этого режима нет никакого ограничения, разрешены ли преобразования с потерями, этим управляют с помощью режима ALL_LOSSY. Если только ALL_NON_LOSSY установлен, но нет ALL_LOSSY, тогда делая попытку преобразования, которое привело бы к потере данных (например, INT в TINYINT ) ведомое устройство останавливается с ошибкой.

    ALL_LOSSY,ALL_NON_LOSSY

    Когда этот режим установлен, все поддержанные преобразования типа разрешены.

    ALL_SIGNED

    Обработайте продвинутые типы целого числа как значения со знаком (поведение по умолчанию).

    ALL_UNSIGNED

    Обработайте продвинутые типы целого числа как значения без знака.

    ALL_SIGNED,ALL_UNSIGNED

    Обработайте продвинутые типы целого числа как со знаком, если возможно, иначе как без знака.

    [empty]

    Когда не задано slave_type_conversions, никакое продвижение признака не разрешено, это означает, что все столбцы в исходных и целевых таблицах должны иметь те же самые типы.

    Это режим по умолчанию.

    Когда тип целого числа продвинут, его знаковость не сохранена. По умолчанию ведомое устройство обрабатывает все такие значения как со знаком. Вы можете управлять этим с использованием ALL_SIGNED, ALL_UNSIGNED или обоих. ALL_SIGNED говорит ведомому устройству обрабатывать все продвинутые типы целого числа как знаковые, ALL_UNSIGNED инструктирует обрабатывать их как без знака. Определение обеих опций предписывает ведомому устройству обработать значение как со знаком, если возможно, иначе обработать это как без знака, порядок, в котором они перечислены, не является существенным. ALL_SIGNED или ALL_UNSIGNED не имеют эффекта, если также не применен ALL_LOSSY или ALL_NONLOSSY.

    Изменение конверсионного режима типа требует перезапуска ведомого устройства с новым значением slave_type_conversions.

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

    Преобразования между типами не в предыдущем списке не разрешены.

    19.4.1.11. Репликация опций DIRECTORY

    Если DATA DIRECTORY или INDEX DIRECTORY применены в CREATE TABLE на главном сервере, табличная опция также используется на ведомом устройстве. Это может вызвать проблемы, если никакой соответствующий каталог не существует в ведомой файловой системе узла, или если он существует, но недоступен для ведомого сервера. Это может быть переопределено при использовании режима SQL NO_DIR_IN_CREATE на ведомом устройстве, который заставляет ведомое устройство игнорировать опции DATA DIRECTORY и INDEX DIRECTORY, копируя CREATE TABLE . Результат: файлы с данными и индексные файлы MyISAM создаются в каталоге базы данных таблицы.

    См. раздел 6.1.8.

    19.4.1.12. Репликация особенностей

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

    Определить, есть ли какие-либо запланированные события на сервере MySQL, которые создавались на различном сервере (который действовал как ведущее устройство репликации), можно запросив таблицу INFORMATION_SCHEMA.EVENTS:

    SELECT EVENT_SCHEMA, EVENT_NAME
           FROM INFORMATION_SCHEMA.EVENTS
           WHERE STATUS = 'SLAVESIDE_DISABLED';
    

    Альтернативно, Вы можете использовать SHOW EVENTS так:

    SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED';
    

    Используя ведомое устройство репликации, имеющее такие события, как ведущее устройство репликации, Вы должны включить каждое событие через ALTER EVENT event_name ENABLE, где event_name название события.

    Если больше, чем одно ведущее устройство было вовлечено в создание событий на этом ведомом устройстве, и Вы хотите идентифицировать события, которые создавались только на данном ведущем устройстве, имеющем ID сервера master_id, измените предыдущий запрос к таблице EVENTS, чтобы включить столбец ORIGINATOR, как показано здесь:

    SELECT EVENT_SCHEMA, EVENT_NAME, ORIGINATOR FROM INFORMATION_SCHEMA.EVENTS
           WHERE STATUS = 'SLAVESIDE_DISABLED' AND
           ORIGINATOR = 'master_id'
    

    Вы можете использовать ORIGINATOR с SHOW EVENTS:

    SHOW EVENTS WHERE STATUS = 'SLAVESIDE_DISABLED' AND
         ORIGINATOR = 'master_id'
    

    Прежде, чем включить события, которые копировались от ведущего устройства, Вы должны отключить MySQL Event Scheduler на ведомом устройстве (с использованием запроса SET GLOBAL event_scheduler = OFF;), выполнить любые необходимые ALTER EVENT, перезапустить сервер, затем повторно включить Event Scheduler на ведомом устройстве позже (используя запрос SET GLOBAL event_scheduler = ON;).

    Если Вы позже понижаете в должности новое ведущее устройство назад к тому, чтобы быть ведомым устройством репликации, Вы должны отключить вручную все события, включенные ALTER EVENT . Вы можете сделать это, храня в отдельной таблице имена событий из показанного ранее SELECT или применяя ALTER EVENT, чтобы переименовать события с общей приставкой, например, replicated_, чтобы идентифицировать их.

    Если Вы переименовываете события, то, понижая в должности этот сервер назад к тому, чтобы быть ведомым устройством репликации, Вы можете идентифицировать события, запрашивая таблицу EVENTS:

    SELECT CONCAT(EVENT_SCHEMA, '.', EVENT_NAME) AS 'Db.Event'
           FROM INFORMATION_SCHEMA.EVENTS
           WHERE INSTR(EVENT_NAME, 'replicated_') = 1;
    

    19.4.1.13. Репликация и значения с плавающей запятой

    С основанной на запросе репликацией значения преобразованы от десятичного числа в двоичные. Поскольку преобразования между десятичными и двоичными представлениями могут быть приблизительными, сравнения, вовлекающие значения с плавающей запятой, неточны. Это истина для операций, которые используют значения с плавающей запятой явно, или значения, которые преобразованы в тип с плавающей запятой неявно. Сравнения значений с плавающей запятой могли бы привести к различным результатам на основных и ведомых серверах из-за различий в архитектуре, компилятора, которым собирали MySQL и т.д., см. разделы 13.2 и B.5.4.8.

    19.4.1.14. Репликация и дробные части секунд

    MySQL 8.0 позволяет дробные части секунд для типов TIME, DATETIME и TIMESTAMP с точностью до микросекунд (6 цифр). См. раздел 12.3.6.

    Может быть мультиплицирование задач от главного сервера, который понимает дробные секунды, к более старому ведомому устройству (MySQL 5.6.3 и ранее), которое этого не делает:

    19.4.1.15. Репликация и FLUSH

    Некоторые формы FLUSH не зарегистрированы, потому что они могли вызвать проблемы, если копируются к ведомому устройству: FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE и FLUSH TABLES WITH READ LOCK. Для примера синтаксиса см. раздел 14.7.6.3. FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE и REPAIR TABLE написаны в двоичный журналу и таким образом копируются к ведомым устройствам. Это обычно не проблема, потому что эти запросы не изменяют табличные данные.

    Однако, это поведение может вызвать трудности при определенных обстоятельствах. Если Вы копируете таблицы привилегии в базе данных mysql и обновляете те таблицы непосредственно без использования GRANT, Вы должны скомандовать FLUSH PRIVILEGES на ведомых устройствах, чтобы осуществить новые привилегии. Кроме того, если Вы используете FLUSH TABLES, переименовывая таблицу MyISAM, которая является частью таблицы MERGE, Вы должны применить FLUSH TABLES вручную на ведомых устройствах. Эти запросы написаны в двоичный журнал, если Вы не определяете NO_WRITE_TO_BINLOG или его псевдоним LOCAL.

    19.4.1.16. Репликация и системные функции

    Определенные функции не копируются хорошо при некоторых условиях:

    Как обходное решение для предыдущих ограничений, когда основанная на запросе репликация работает, Вы можете использовать стратегию сохранения проблематичного функционального результата в пользовательской переменной и обращении к переменной в более позднем запросе. Например, следующий INSERT проблематичен из-за ссылки на функцию UUID():

    INSERT INTO t VALUES(UUID());
    

    Чтобы работать вокруг проблемы, сделайте это:

    SET @my_uuid = UUID();
    INSERT INTO t VALUES(@my_uuid);
    

    Та последовательность запросов копируется, потому что значение @my_uuid сохранено в двоичном журнале как событие вставки переменной через INSERT.

    Та же самая идея относится к многострочной вставке, но более сложна. Для вставки с двумя строками Вы можете сделать это:

    SET @my_uuid1 = UUID(); @my_uuid2 = UUID();
    INSERT INTO t VALUES(@my_uuid1),(@my_uuid2);
    

    Однако, если число строк является большим или неизвестным, обходное решение является трудным или невыполнимым. Например, Вы не можете преобразовать следующий запрос к тому, в котором данная отдельная пользовательская переменная связана с каждой строкой:

    INSERT INTO t2 SELECT UUID(), * FROM t1;
    

    В пределах сохраненной функции RAND() копируется правильно, пока это вызвано только однажды во время выполнения функции. Вы можете рассмотреть функциональное выполнение timestamp и получение случайного числа как неявные вводы, которые идентичны на ведущем и ведомом устройствах.

    FOUND_ROWS() и ROW_COUNT() не копируются достоверно, используя основанную на запросе репликацию. Обходное решение должно сохранить результат вызова функции в пользовательской переменной, а затем использовать это в INSERT. Например, если Вы хотите сохранить результат в таблице mytable, Вы могли бы обычно делать так:

    SELECT SQL_CALC_FOUND_ROWS FROM mytable LIMIT 1;
    INSERT INTO mytable VALUES(FOUND_ROWS());
    

    Однако, если Вы копируете mytable, Вы должны использовать SELECT ... INTO и затем сохраните переменную в таблице:

    SELECT SQL_CALC_FOUND_ROWS INTO @found_rows FROM mytable LIMIT 1;
    INSERT INTO mytable VALUES(@found_rows);
    

    Таким образом, пользовательская переменная копируется как часть контекста и применена на ведомом устройстве правильно.

    Эти функции автоматически копируются, используя основанную на строке репликацию, используя режим MIXED и производят предупреждение в режиме STATEMENT (Bug #12092, Bug #30244).

    19.4.1.17. Репликация и LIMIT

    Основанная на запросе репликация считает LIMIT в in DELETE, UPDATE и INSERT ... SELECT опасным, так как порядок затронутых строк не определен. Такие запросы могут копироваться правильно с основанной на запросе репликацией, только если они также содержат ORDER BY. Когда с таким запросом сталкиваются:

    19.4.1.18. Репликация и LOAD DATA INFILE

    В MySQL 8.0 LOAD DATA INFILE считается опасным (см. раздел 19.2.1.3). Это вызывает предупреждение, используя основанный на запросе формат журналирования, и зарегистрировано, используя основанный на строке формат, используя журналирование смешанного формата.

    19.4.1.19. Репликация и разделение

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

    Репликация между таблицами, имеющими различное разделение, вообще не поддержана. Это потому, что запросы вроде ALTER TABLE ... DROP PARTITION) действуют непосредственно на разделение в таких случаях, что может привести к различным результатам на ведущем и ведомом устройствах. В случае, где таблица разделена на ведущем устройстве, но не на ведомом, любые запросы, воздействующие на разделение на копии на ведущем устройстве, терпят неудачу на ведомом устройстве. Когда копия ведомого устройства таблицы разделена, но копия ведущего устройства нет, запросы, действующие на разделение, не могут быть выполнены на ведущем устройстве, не вызывая ошибки.

    Из-за этих опасностей заставить репликацию терпеть неудачу полностью (из-за неудавшихся запросов) и несогласованностей (когда результат запросов SQL на уровне разделения приводит к различным результатам на ведущем и ведомом устройствах), мы рекомендуем, чтобы Вы обеспечили, чтобы разделение любых таблиц, которые будут копироваться от ведущего устройства, было соответствующим версиям ведомого устройства этих таблиц.

    19.4.1.20. Репликацуя и REPAIR TABLE

    Когда используется на поврежденной таблице, возможно для REPAIR TABLE удалить строки, которые не могут быть восстановлены. Однако, любые такие модификации табличных данных, выполненные этим запросом, не копируются, что может заставить ведущее и ведомое устройства потерять синхронизацию. Поэтому, когда таблица на ведущем устройстве становится поврежденной, и Вы используете REPAIR TABLE, чтобы восстановить это, Вы должны сначала остановить репликацию (если это все еще работает) перед использованием REPAIR TABLE, позже сравнить копии таблицы ведущего и ведомого устройств и быть подготовленными исправить любые несоответствия вручную прежде, чем перезапустить репликацию.

    19.4.1.21. Репликация и завершение работы

    Безопасно закрыть главный сервер и перезапустить его позже. Когда ведомое устройство теряет свое соединение с ведущим устройством, ведомое устройство пытается повторно соединиться немедленно и повторяет попытки периодически, если это терпит неудачу. По умолчанию надо повторять каждые 60 секунд. Это может быть изменено с CHANGE MASTER TO. Ведомое устройство также в состоянии иметь дело с сетевыми отключениями. Однако, ведомое устройство замечает сетевое отключение только после прекращения получения данных от ведущего устройства в течение slave_net_timeout секунд. Если Ваши отключения коротки, Вы можете хотеть уменьшить slave_net_timeout . См. раздел 6.1.5.

    Грязное завершение работы (например, катастрофический отказ) на основной стороне может привести к основному двоичному журналу, имеющему заключительную позицию меньше, чем новая позиция, считанная ведомым устройством, из-за не сброшенного файла основного двоичного системного журнала. Это может заставить ведомое устройство быть не в состоянии копировать, когда ведущее устройство возвращается. Установка sync_binlog=1 в файле my.cnf на ведущем устройстве помогает минимизировать эту проблему, потому что это заставляет ведущее устройство сбрасывать двоичный журнал более часто.

    Закрытие ведомого устройства чисто безопасно, потому что оно отслеживает то, где оно закончило. Однако, проследите чтобы у ведомого устройства не было открытых временных таблиц, см. раздел 19.4.1.24. Грязные завершения работы могли бы произвести проблемы, особенно если дисковый кэш не сброшен к диску прежде, чем проблема произошла:

    Отказоустойчивость Вашей системы для этих типов проблем очень увеличена, если у Вас есть хорошее непрерывное электропитание.

    19.4.1.22. Репликация и max_allowed_packet

    max_allowed_packet задает верхний предел для размера любого единственного сообщения между сервером MySQL и клиентами, включая ведомые устройства репликации. Если Вы копируете большие значения столбцов (те, которые могли бы быть найдены в столбцах TEXT или BLOB) и max_allowed_packet слишком маленькое на ведущем устройстве, ведущее устройство терпит неудачу с ошибкой, и ведомое устройство закрывает поток ввода/вывода. Если max_allowed_packet является слишком маленьким на ведомом устройстве, это также заставляет ведомое устройство останавливать поток ввода/вывода.

    Основанная на строке репликация в настоящее время посылает все столбцы и значения столбцов для обновленных строк от ведущего устройства к ведомому, включая значения столбцов, которые не были фактически изменены обновлением. Это означает, что, когда Вы копируете большие значения столбцов, используя основанную на строке репликацию, Вы должны озаботиться достаточно большим значением max_allowed_packet, чтобы обработать самую большую строку в любой таблице, которая будет копироваться, даже если Вы копируете только обновления или вставляете только относительно маленькие значения.

    19.4.1.23. Репликация и таблицы MEMORY

    Когда главный сервер закрывается и перезапускается, таблицы MEMORY становятся пустыми. Чтобы скопировать этот эффект к ведомым устройствам в первый раз, когда ведущее устройство использует таблицу MEMORY после запуска, это регистрирует событие, которое извещает ведомые устройства, что таблица должна быть освобождена записью DELETE для той таблицы в двоичный журнал.

    Когда ведомый сервер закрывается и перезапускается, таблицы MEMORY становятся пустыми. Это заставляет ведомое устройство быть вне синхронизации с ведущим устройством и может привести к другим отказам или заставить ведомое устройство останавливаться:

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

    Альтернативный метод перезапуска может примениться в некоторых случаях. Когда binlog_format=ROW , Вы можете препятствовать тому, чтобы ведомое устройство остановилось, если Вы устанавливаете slave_exec_mode=IDEMPOTENT прежде, чем Вы запустите ведомое устройство снова. Это позволяет ведомому устройству продолжать копировать, но таблицы MEMORY будут все еще отличаться от тех, которые есть на ведущем устройстве. Это может быть хорошо, если логика приложения такова что содержание таблиц MEMORY может быть безопасно потеряно (например, если MEMORY используются для того, чтобы кэшироваться). slave_exec_mode=IDEMPOTENT применяется глобально ко всем таблицам, таким образом, это может скрыть другие ошибки репликации в таблицах не-MEMORY.

    Размер MEMORY ограничен значением max_heap_table_size, которая не копируется (см. раздел 19.4.1.38). Изменение в max_heap_table_size вступает в силу для MEMORY, которые составлены или обновлены с использованием ALTER TABLE ... ENGINE = MEMORY или TRUNCATE TABLE после изменения или для всех MEMORY после перезапуска сервера. Если Вы увеличиваете значение этой переменной на ведущем устройстве, не делая так на ведомом устройстве, для таблицы на ведущем устройстве становится возможно вырасти больше, чем ее коллега на ведомом устройстве, что может привести к ошибке Table is full. Это известная проблема (Bug #48666). В таких случаях Вы должны установить глобальное значение max_heap_table_size на ведомом устройстве так же, как на ведущем устройстве, затем перезапустите репликацию. Также рекомендуется, чтобы Вы перезапустили основные и ведомые серверы MySQL, чтобы обеспечить, чтобы новое значение имело эффект на каждом из них.

    См. раздел 17.3.

    19.4.1.24. Репликация и временные таблицы

    Обсуждение в следующих параграфах не применяется, когда binlog_format=ROW потому что, в этом случае временные таблицы не копируются, это означает, что никогда нет никаких временных таблиц на ведомом устройстве, которые будут потеряны в случае незапланированного завершения работы ведомым устройством. Остаток от этого раздела применяется только, используя основанную на запросе или репликацию смешанного формата. Потеря копируемых временных таблиц на ведомом устройстве может быть проблемой, всякий раз, когда binlog_format STATEMENT или MIXED для запросов, вовлекающих временные таблицы, которые могут быть зарегистрированы безопасно, используя основанный на запросе формат.

    Безопасное ведомое завершение работы, используя временные таблицы. Временные таблицы копируются кроме случая, когда Вы останавливаете ведомый сервер (не только ведомые потоки), и Вы копировали временные таблицы, которые открыты для использования в обновлениях, которые еще не были выполнены на ведомом устройстве. Если Вы останавливаете ведомый сервер, временные таблицы, необходимые тем обновлениям, больше недоступны, когда ведомое устройство перезапущено. Чтобы избежать этой проблемы, не закрывайте ведомое устройство, в то время как у этого есть временные открытые таблицы. Вместо этого используйте следующую процедуру:

    1. Выполните STOP SLAVE SQL_THREAD.

    2. Используйте SHOW STATUS, чтобы проверять значение переменной Slave_open_temp_tables.
    3. Если значение не 0, перезапустите ведомый поток SQL с помощью START SLAVE SQL_THREAD и повторите процедуру позже.
    4. Когда значение 0, выполните mysqladmin shutdown, чтобы остановить ведомое устройство.

    Временные таблицы и опции репликации. По умолчанию, все временные таблицы копируются, это происходит безотносительно того, есть ли какое-либо соответствие --replicate-do-db, --replicate-do-table или --replicate-wild-do-table. Однако, опции --replicate-ignore-table и --replicate-wild-ignore-table соблюдают для временных таблиц.

    Рекомендуемая практика, используя основанную на запросе или смешанную репликацию должна определять приставку для исключительного использования в обозначении временных таблиц, которые Вы не хотите копировать, затем использовать --replicate-wild-ignore-table, чтобы соответствовать. Например, Вы могли бы дать все такие табличные имена с norep, затем применить --replicate-wild-ignore-table=norep%, чтобы препятствовать тому, чтобы они копировались.

    19.4.1.25. Репликация системной базы данных mysql

    Запросы модификации данных, сделанные к таблицам в базе данных mysql, копируются согласно значению binlog_format, если это значение MIXED, эти запросы копируются, используя основанный на строке формат. Однако, запросы, которые обычно обновляли бы эту информацию косвенно, например, GRANT , REVOKE и запросы, управляющие сохраненными подпрограммами, триггерами и представлениями, копируются к ведомым устройствам, используя основанную на запросе репликацию.

    19.4.1.26. Репликация и оптимизатор запросов

    Для данных по ведущему и ведомому устройствам возможно стать отличающимся, если запрос написано таким способом, которым модификация данных недетерминирована благодаря оптимизации запроса. Вообще это не хорошая практика, даже за пределами репликации. Примеры недетерминированных запросов включают DELETE или UPDATE, которые применяют LIMIT без ORDER BY, см. раздел 19.4.1.17.

    19.4.1.27. Репликация и зарезервированные слова

    Вы можете столкнуться с проблемами, когда Вы пытаетесь копировать от ведущего устройства старшего возраста к более новому ведомому устройству, и Вы используете идентификаторы на ведущем устройстве, которые являются зарезервированными словами в более новой версии MySQL, работающей на ведомом устройстве. Пример этого использует столбец таблицы названный virtual на 5.6 ведущих устройствах, которые копируются к 5.7 или более новому ведомому устройству, потому что VIRTUAL зарезервированное слово, начиная с MySQL 5.7. Репликация может потерпеть неудачу в таких случаях с Error 1064 You have an error in your SQL syntax..., даже если база данных или таблица, названная с использованием зарезервированного слова, исключена из репликации. Это следствие того, что каждое событие SQL должно быть разобрано ведомым устройством до выполнения, чтобы ведомое устройство знало, какой объект базы данных или объекты были бы затронуты, только после того, как событие разобрано, ведомое устройство может применять любые правила фильтрации, определенные --replicate-do-db, --replicate-do-table, --replicate-ignore-db и --replicate-ignore-table.

    Чтобы работать вокруг проблемы базы данных, таблицы или имен столбцов на ведущем устройстве, которые были бы расценены как зарезервированные слова ведомым устройством, делается одно из следующего:

    Для списков зарезервированных слов в версии MySQL см. Reserved Words, в MySQL Server Version Reference. Для правил заключения в кавычки идентификатора см. раздел 10.2.

    19.4.1.28. Ведомые ошибки во время репликации

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

    Если запрос производит различные ошибки на ведущем и ведомом устройствах, ведомый поток SQL заканчивается, ведомое устройство пишет сообщение своему журналу ошибок и ждет администратора базы данных, чтобы решить, что сделать. Это включает случай, что запрос производит ошибку на ведущем или ведомом устройстве, но не на обоих. Чтобы обратиться к проблеме, соединитесь с ведомым устройством вручную и определите причину проблемы. SHOW SLAVE STATUS полезно для этого. После ремонта выполните START SLAVE. Например, Вы, возможно, должны были бы составить несуществующую таблицу прежде, чем Вы сможете запустить ведомое устройство снова.

    Если это поведение проверки допустимости кода ошибки нежелательно, некоторые или все ошибки могут быть проигнорированы с помощью опции --slave-skip-errors.

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

    Если Вы копируете между таблицами, которые используют различные механизмы хранения на ведущем и ведомом устройствах, имейте в виду, что тот же самый запрос мог бы произвести различную ошибку, когда выполнен против одной версии таблицы, но не другой, или мог бы вызвать ошибку для одной версии таблицы, но не другой. Например, с тех пор как MyISAM игнорирует ограничения внешнего ключа, INSERT или UPDATE, получающие доступ к InnoDB на ведущем устройстве могли бы вызвать нарушение внешнего ключа, но тот же самый запрос, выполненный на версии MyISAM той же самой таблицы на ведомом устройстве не произвел бы такой ошибки, заставляя репликацию остановиться.

    19.4.1.29. Репликация серверных таблиц справки

    Сервер поддерживает таблицы в базе данных mysql, которые хранят информацию для HELP (см. раздел 14.8.3. Эти таблицы могут быть загружены вручную как описано в разделе 6.1.10.

    Табличный контент справки получен из MySQL Reference Manual. Есть версии руководства, определенные для каждого ряда выпуска MySQL, таким образом, контент справки является определенным для каждого ряда также. Обычно Вы загружаете версию контента справки, которая соответствует версии сервера. У этого есть значения для репликации. Например, Вы загрузили бы контент справки MySQL 5.6 в главный сервер MySQL 5.6, но не обязательно копировали бы тот контент к ведомому серверу MySQL 5.7, для которого контент справки 5.7 является более подходящим.

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

    Предположите, что контент справки сохранен в файле названном fill_help_tables.sql. В MySQL этот файл расположен в каталоге share или share/mysql, новая версия всегда доступна для скачивания с http://dev.mysql.com/doc/index-other.html.

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

    1. Обновите свои серверы через mysql_upgrade , сначала на ведомых устройствах и затем на ведущем устройстве. Это обычный принцип обновления ведомых устройств сначала.

    2. Решите, хотите ли Вы копировать табличный контент справки от ведущего устройства к его ведомым устройствам. В противном случае загрузите контент на ведущем устройстве и на каждом ведомом устройстве индивидуально. Иначе, проверьте и решите любые несовместимости между структурой таблицы справки на ведущем устройстве и ведомых, затем загрузите контент в ведущее устройство и позвольте этому копировать к ведомым устройствам.

    Загрузка табличного контента справки без репликации к ведомым устройствам

    Чтобы загрузить табличный контент справки без репликации, выполните эту команду на ведущем устройстве и на каждом ведомом устройстве индивидуально, используя файл fill_help_tables.sql, содержащий контент для нужной версии:

    mysql mysql < fill_help_tables.sql
    
    Загрузка табличного контента справки с репликацией к ведомым устройствам

    Если Вы действительно хотите копировать табличный контент справки, проверьте на табличные несовместимости справки между Вашим ведущим устройством и ведомыми устройствами. Столбец url в таблицах help_category и help_topic изначально CHAR(128), но TEXT в более новых версиях MySQL, чтобы приспособить более длинные URL. Чтобы проверить структуру таблицы справки, используйте этот запрос:

    SELECT TABLE_NAME, COLUMN_NAME, COLUMN_TYPE
           FROM INFORMATION_SCHEMA.COLUMNS
           WHERE TABLE_SCHEMA = 'mysql' AND COLUMN_NAME = 'url';
    

    Для таблиц со старой структурой запрос приводит к этому результату:

    +---------------+-------------+-------------+
    | TABLE_NAME    | COLUMN_NAME | COLUMN_TYPE |
    +---------------+-------------+-------------+
    | help_category | url         | char(128)   |
    | help_topic| url             | char(128)   |
    +---------------+-------------+-------------+
    

    Для таблиц с новой структурой запрос приводит к этому результату:

    +---------------+-------------+-------------+
    | TABLE_NAME    | COLUMN_NAME | COLUMN_TYPE |
    +---------------+-------------+-------------+
    | help_category | url         | text        |
    | help_topic    | url         | text        |
    +---------------+-------------+-------------+
    

    Если у ведущего и ведомого устройств есть старая структура или у обоих есть новая структура, они совместимы, и Вы можете копировать табличный контент справки, выполняя эту команду на ведущем устройстве:

    mysql mysql < fill_help_tables.sql
    

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

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

    19.4.1.30. Репликация и режим SQL сервера

    Используя различные настройки режима SQL на ведущем и ведомом устройстве можно обработать тот же самый INSERT по-другому. Для лучших результатов Вы должны всегда использовать тот же самый режим SQL на ведущем и ведомом устройствах. Этот совет применяется, используете ли Вы основанную на запросе или строке репликацию.

    Если Вы копируете разделенные таблицы, используя различные режимы SQL на ведущем и ведомое устройствах, это, вероятно, вызовет проблемы. Как минимум, это, вероятно, заставит распределение данных среди разделения отличаться в копиях ведущего и ведомого устройств данной таблицы. Это может также вызвать вставки в разделенные таблицы, которые преуспевают на ведущем устройстве, чтобы потерпеть неудачу на ведомом устройстве.

    19.4.1.31. Повторения репликации и тайм-ауты

    Глобальная системная переменная slave_transaction_retries влияет на репликацию так: если ведомый поток SQL не в состоянии выполнить транзакцию из-за тупика InnoDB или потому что это превысило значение InnoDB innodb_lock_wait_timeout (или значения or the NDB TransactionDeadlockDetectionTimeout или TransactionInactiveTimeout), то ведомое устройство автоматически повторяет транзакцию slave_transaction_retries раз прежде, чем остановиться с ошибкой. Значение по умолчанию 10. Полное количество повторных попыток может быть найдено в выводе SHOW STATUS , см. раздел 6.1.7.

    19.4.1.32. Репликация и часовые пояса

    По умолчанию основные и ведомые серверы предполагают, что находятся в том же самом часовом поясе. Если Вы копируете между серверами в различных часовых поясах, часовой пояс должен быть установлен на ведущем и на ведомом устройствах. Иначе запросы в зависимости от местного времени на ведущем устройстве не копируются должным образом, такие как запросы, которые используют NOW() или FROM_UNIXTIME(). Установите часовой пояс, в котором сервер MySQL работает, при использовании опции --timezone= timezone_name скрипта mysqld_safe или через переменную окружения TZ. См. также раздел 19.4.1.16 .

    19.4.1.33. Репликация и транзакции

    Смешивание транзакционных и нетранзакционных запросов в пределах той же самой транзакции. Вообще Вы должны избежать транзакций, которые обновляют транзакционные и нетранзакционные таблицы в окружающей среде репликации. Вы должны также избегать использования любого запроса, который обращается к транзакционным (или временным) и нетранзакционным таблицам и пишет любую из них.

    Сервер использует эти правила для двоичного журналирования:

    Транзакционные, нетранзакционные и смешанные запросы. Чтобы применить эти правила, сервер считает запрос нетранзакционным, если он изменяет только нетранзакционные таблицы, и транзакционным, если он изменяет только транзакционные таблицы. В MySQL 8.0 запрос, который использует нетранзакционные и транзакционные таблицы и обновляет любые из вовлеченных таблиц, считается смешанным. В предыдущем ряду выпуска MySQL запрос, который менял нетранзакционные и транзакционные таблицы, считали смешанным. Смешанные запросы, как транзакционные запросы, кэшируются и зарегистрированы, когда транзакция передается.

    Смешанный запрос, который обновляет транзакционную таблицу, считают опасным, если запрос также выполняет любое из следующих действий:

    Смешанный запрос после обновления транзакционной таблицы в пределах транзакции считают опасным, если это выполняет любое из следующих действий:

    См. раздел 19.2.1.3.

    Смешанный запрос не связан со смешанным двоичным форматом журналирования.

    В ситуациях, где операционные обновления соединяют транзакционные и нетранзакционные таблицы, порядок запросов в двоичном журнале правилен, и все необходимые запросы, написаны двоичному журналу даже в случае ROLLBACK. Однако, когда второе соединение обновляет нетранзакционную таблицу прежде, чем первая транзакция соединения будет полна, запросы могут быть зарегистрированы не в том порядке, потому что второе обновление соединения немедленно написано после того, как это выполнено, независимо от статуса транзакции, выполняемой первым соединением.

    Используя различные механизмы хранения на ведущем и ведомом устройствах. Возможно копировать транзакционные таблицы на ведущем устройстве, используя нетранзакционные таблицы на ведомом устройстве. Например, Вы можете копировать InnoDB в MyISAM. Однако, если Вы делаете это, есть проблемы, если ведомое устройство остановлено в середине блока BEGIN ... COMMIT, потому что ведомое устройство перезапускается в начале блока BEGIN.

    В MySQL 8.0 также безопасно копировать транзакции от MyISAM на ведущем устройстве к транзакционной таблицк, например, InnoDB на ведомом. В таких случаях AUTOCOMMIT=1 на ведущем устройстве, копируется, таким образом проводя в жизнь AUTOCOMMIT на ведомом устройстве.

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

    Изменение формата двоичного журналирования в пределах транзакций. binlog_format только для чтения, пока транзакция происходит.

    Каждая транзакция (включая autocommit) зарегистрирована в двоичном журнале, как если она запускается с BEGIN и заканчивается COMMIT или ROLLBACK. В MySQL 8.0 это истина даже для запросов, затрагивающих таблицы, которые используют нетранзакционный механизм хранения (такой как MyISAM).

    19.4.1.34. Репликация и операционные несогласованности

    Несогласованности в последовательности транзакций, которые были выполнены из журнала реле, могут произойти в зависимости от Вашей конфигурации репликации. Этот раздел объясняет, как избежать несогласованностей и решить любые проблемы, которые они вызывают.

    Следующие типы несогласованностей могут существовать:

    Следующие сценарии относятся к существованию полуприкладных транзакций, промежутков и несогласованностей позиции низкой отметки без промежутков:

    1. В то время как ведомые потоки работают, могут быть промежутки и полупримененные транзакции.

    2. mysqld закрывается. Чистое и грязное завершение работы прерывает продолжающиеся транзакции и может оставить промежутки и полупримененные транзакции.
    3. KILL для потоков репликации (поток SQL, используя однопоточное ведомое устройство, поток координатора, используя мультипоточное ведомое устройство). Это прерывает продолжающиеся транзакции и может оставить промежутки и полупримененные транзакции.
    4. Ошибка в потоках. Это может оставить промежутки. Если ошибка находится в смешанной транзакции, та транзакция полуприменена. Используя мультипоточное ведомое устройство, рабочие потоки, которые не получили ошибку, завершают свои очереди, таким образом, это может занять время, чтобы остановить все потоки.
    5. STOP SLAVE, используя мультипоточное ведомое устройство. После STOP SLAVE ведомое устройство ждет заполнения любых промежутков и затем обновляет Exec_master_log_pos. Это гарантирует, что никогда не оставляет промежутки или позиции низкой отметки без промежутков, если любой из случаев выше не применяется (другими словами, прежде завершения STOP SLAVE, ошибки, получением от другого потока KILL или перезапуска сервера. В этих случаях STOP SLAVE успешно отработает.
    6. Если последняя транзакция в журнале реле только полуполучена, и мультипоточный ведомый координатор начал намечать транзакцию рабочему, то STOP SLAVE ждет 60 секунд для транзакции, которая будет получена. После этого тайм-аута координатор сдается и прерывает транзакцию. Если транзакция смешана, это может остаться полузавершенным.
    7. STOP SLAVE, используя однопоточное ведомое устройство. Если продолжающаяся транзакция только обновляет транзакционные таблицы, она отменена и STOP SLAVE остановлен сразу. Если продолжающаяся транзакция смешана, STOP SLAVE ждет 60 секунд для транзакции, чтобы завершиться. После этого тайм-аута это прерывает транзакцию, таким образом, это может оставить ее полузавершенной.

    Глобальная переменная rpl_stop_slave_timeout не связана с процессом остановки потоков репликации. Это только делает клиенту, который вызвал STOP SLAVE, возврат управления к клиенту, но потоки репликации продолжают пытаться остановиться.

    Если у канала репликации есть промежутки, у него есть следующие последствия:

    1. Ведомая база данных находится в статусе, которое никогда, возможно, не существовало на ведущем устройстве.

    2. Поле Exec_master_log_pos в SHOW SLAVE STATUS только "low-watermark". Другими словами, транзакции, появляющиеся перед позицией, как гарантируют, переданы, но транзакции после позиции, возможно, переданы или нет.
    3. CHANGE MASTER TO для того канала терпят неудачу с ошибкой, если потоки применения не работают и CHANGE MASTER TO только устанавливает опции получателя.
    4. Если mysqld запущен с --relay-log-recovery, никакое восстановление не сделано для того канала, и предупреждение напечатано.
    5. Если mysqldump используется с --dump-slave, это не делает запись существования промежутков, таким образом это печатает CHANGE MASTER TO с RELAY_LOG_POS, установленным к позиции низкой отметки в Exec_master_log_pos.

      После применения дампа на другом сервере и запуска потоков репликации, транзакции, появляющиеся после позиции, копируются снова. Отметьте, что это безопасно, если GTID включены (однако, в этом случае не рекомендуется использовать --dump-slave).

    Если у канала репликации есть позиция низкой отметки без промежутков, случаи 2-5 выше применяются, но случай 1 нет.

    Информация о положении низкой отметки без промежутков сохранена в двоичном формате во внутренней таблице mysql.slave_worker_info. START SLAVE [SQL_THREAD] всегда консультируется с этой информацией так, чтобы она применила только правильные транзакции. Это остается истиной, даже если slave_parallel_workers был изменен на 0 до START SLAVE и даже если START SLAVE применен с UNTIL. START SLAVE UNTIL SQL_AFTER_MTS_GAPS применяет так много транзакций как необходимо, чтобы заполнить промежутки. Если START SLAVE применен с UNTIL, который говорит этому останавливаться прежде, чем это потребит все промежутки, тогда это оставляет промежутки.

    RESET SLAVE удаляет журналы реле и сбрасывает позицию репликации. Таким образом на ведомом устройстве с промежутками ведомое устройство после RESET SLAVE теряет любую информацию о промежутках, не исправляя промежутки.

    slave-preserve-commit-order гарантирует, что нет никаких промежутков. Однако, все еще возможно, что Exec_master_log_pos только позиция низкой отметки без промежутков в сценариях 1-4 выше. Таким образом, после Exec_master_log_pos могут быть транзакции, которые были применены. Поэтому случаи 2-5 (но не 1) применяются, даже когда включена slave-preserve-commit-order.

    19.4.1.35. Репликация и триггеры

    С основанной на запросе репликацией триггеры, выполненные на ведущем устройстве, также выполняются на ведомом устройстве. С основанной на строке репликацией триггеры, выполненные на ведущем устройстве, не выполняются на ведомом устройстве. Вместо этого строка изменяется на ведущем устройстве, следуя из выполнения, копируется и применяется на ведомое устройство.

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

    Если Вы хотите, чтобы триггеры выполнились на ведущем устройстве и на ведомом, возможно, потому что у Вас есть различные триггеры на ведущем и на ведомом, Вы должны использовать основанную на запросе репликацию. Однако, чтобы включить триггеры ведомой стороны, не надо использовать основанную на запросе репликацию исключительно. Достаточно переключиться на основанную на запросе репликацию только для тех запросов, где Вы хотите этот эффект, и использовать основанную на строке репликацию остальную часть времени.

    Запрос, вызывающий триггер (или функцию), который вызывает обновление AUTO_INCREMENT не копируется правильно, используя основанную на запросе репликацию. MySQL 8.0 отмечает такие запросы как опасные (Bug #45677).

    У триггера могут быть триггеры для различных комбинаций событий (INSERT, UPDATE, DELETE) и время действия (BEFORE, AFTER), многократные триггеры разрешены.

    Для краткости многократные триггеры это сокращение для многократные триггеры, у которых есть то же самое событие и время действия.

    Обновления. Предположите, что Вы обновляете старый сервер, который не поддерживает многократные триггеры (до 5.7.2) к версии, которая это уже делает (MySQL 5.7.2 или выше). Если новый сервер это ведущее устройство репликации и имеет старые ведомые устройства, которые не поддерживают многократные триггеры, ошибка происходит на тех ведомых устройствах, если триггер создается на ведущем устройстве для таблицы, у которой уже есть триггер с тем же самым событием и временем действия. Чтобы избежать этой проблемы, обновите ведомые устройства сначала, затем обновите ведущее.

    Откат. Если Вы понижаете сервер, который поддерживает многократные триггеры к более старой версии, которая этого не делает, откат имеет эти эффекты:

    Чтобы избежать этих проблем, измените свои триггеры перед откатом. Для каждой таблицы, у которой есть многократные триггеры на комбинацию события и времени, преобразуйте каждый такой набор триггеров к единственному триггеру следующим образом:

    1. Для каждого триггера, создайте сохраненную подпрограмму, которая содержит весь код триггера. Значения с доступом к использованию NEW и OLD могут быть переданы к обычным параметрам использования. Если триггер нуждается в единственном значении результата от кода, Вы можете поместить код в сохраненную функцию и иметь возвращенное функцией значение. Если триггер нуждается в многократных значениях результата от кода, Вы можете поместить код в хранимую процедуру и возвратить с использованием значений параметров OUT.

    2. Удалите все триггеры для таблицы.
    3. Создайте один новый триггер для таблицы, который вызывает сохраненные подпрограммы. Эффект для этого триггера то же самое, как многократные триггеры, которые это заменяет.

    19.4.1.36. Репликация и TRUNCATE TABLE

    TRUNCATE TABLE обычно расценивается как запрос DML и будет зарегистрирован и скопирован, используя основанный на строке формат, когда двоичной режим журналирования ROW или MIXED. Однако это вызвало проблемы регистрируя или копируя, в режимах STATEMENT или MIXED таблицы, которые использовали транзакционные механизмы хранения, когда операционный уровень изоляции был READ COMMITTED или READ UNCOMMITTED, который устраняет основанное на запросе журналирование.

    TRUNCATE TABLE в целях регистрации и репликации работает как DDL, а не DML так, чтобы это могло быть зарегистрировано и копироваться как запрос. Однако, эффекты запроса применимо к InnoDB и другим транзакционным таблицам на ведомых устройствах репликации все еще следуют правилам, описанным в разделе 14.1.30 (Bug #36763).

    19.4.1.37. Репликация и длина имени пользователя

    Максимальная длина имен пользователя MySQL 32 символа в MySQL 5.7.8 или выше. Репликация имен пользователя длинней 16 символов к ведомому устройству, которое поддерживает только более короткие имена пользователя, потерпит неудачу. Однако, это должно произойти только, копируя от более нового ведущего устройства к более старому ведомому устройству, которое не является рекомендуемой конфигурацией.

    19.4.1.38. Репликация и переменные

    Системные переменные не копируются правильно, используя режим STATEMENT, за исключением следующих переменных, когда они используются с контекстом сеанса:

    Когда используется режим MIXED, переменные в предыдущем списке, когда используются с контекстом сеанса, вызывают переключение от основанного на запросе до основанного на строке журналирования. См. раздел 6.4.4.3.

    sql_mode также копируется за исключением NO_DIR_IN_CREATE , ведомое устройство всегда сохраняет свое собственное значение для NO_DIR_IN_CREATE , независимо от изменений этого на ведущем устройстве. Это истина для всех форматов репликации.

    Однако, когда mysqlbinlog разбирает запрос SET @@sql_mode = mode, полное значение mode value, включая NO_DIR_IN_CREATE , передано к серверу получения. Поэтому репликация такого запроса, возможно, не безопасна, когда применен режим STATEMENT.

    default_storage_engine не копируется, независимо от режима журналирования, это предназначено, чтобы облегчить репликацию между различными механизмами хранения.

    read_only не копируется. Кроме того, включение этой переменной имеет различные эффекты относительно временных таблиц, табличной блокировки и SET PASSWORD в различных версиях MySQL.

    max_heap_table_size не копируется. Увеличение значения этой переменной на ведущем устройстве, не делая так на ведомом устройстве может привести в конечном счете к ошибке Table is full на ведомом устройстве, пытаясь выполнить INSERT на таблице MEMORY на ведущем устройстве, которой таким образом разрешают вырасти больше, чем ее коллеге на ведомом устройстве. Для получения дополнительной информации см. раздел 19.4.1.23.

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

    SET max_join_size=1000;
    INSERT INTO mytable VALUES(@@max_join_size);
    

    Это не относится к общей последовательности:

    SET time_zone=...;
    INSERT INTO mytable VALUES(CONVERT_TZ(..., ..., @@time_zone));
    

    Репликация переменных сеанса не проблема, когда основанная на строке репликация используется, тогда переменные сеанса всегда копируются безопасно. См. раздел 19.2.1.

    В MySQL 8.0 следующие переменные сеанса написаны в двоичный журнал и соблюдаются ведомым устройством репликации, разбирая двоичной журнал, независимо от формата журналирования:

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

    Чтобы помочь уменьшить возможный беспорядок, мы рекомендуем, чтобы Вы всегда использовали ту же самую установку для lower_case_table_names на ведущем и на ведомом устройствах, особенно когда Вы выполняете MySQL на платформах с чувствительными к регистру файловыми системами.

    19.4.1.39. Репликация и представления

    Представления всегда копируются к ведомым устройствам. Представления фильтруются по их собственному имени, не по таблицам, к которым они обращаются. Это означает, что представление может копироваться к ведомому устройству, даже если содержит таблицу, которая обычно отфильтровывалась бы правилами replication-ignore-table. Забота должна поэтому быть проявлена, чтобы гарантировать, что представления не копируют табличные данные, которые обычно фильтровались бы из соображений безопасности.

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

    19.4.2. Совместимость репликации между версиями MySQL

    MySQL поддерживает Репликация от одного ряда выпуска до следующей более высокой серии выпуска. Например, Вы можете копировать от ведущего с MySQL 5.6 к ведомому с MySQL 5.7, с ведущего с MySQL 5.7 к ведомому с MySQL 8.0 и т.д.

    Однако, Вы можете столкнуться с трудностями, копируя от ведущего устройства старшего возраста к более новому ведомому устройству, если ведущее устройство использует запросы или полагается на поведение, больше не поддержанное в версии MySQL на ведомом устройстве. Например, в MySQL 5.5 CREATE TABLE ... SELECT разрешают изменить таблицы кроме создаваемой, но больше это не позволено в MySQL 5.6 (см. раздел 19.4.1.6).

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

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

    Репликация от более новых ведущих устройств к более старым ведомым может быть возможна, но вообще не поддержан. Это происходит из-за многих факторов:

    См. раздел 19.4.1.

    19.4.3. Обновление установки репликации

    Когда Вы обновляете серверы, которые участвуют в установке репликации, процедура для того, чтобы обновить, зависит от текущих версий сервера и версии, до которой Вы обновляете. Этот раздел предоставляет информацию о том, как обновление репликации может повлиять на работу. Для общей информации об обновлении MySQL см. раздел 2.10.1.

    Когда Вы обновляете ведущее устройство до 8.0 от более раннего ряда выпуска MySQL, Вы должны сначала гарантировать, что все ведомые устройства этого ведущего устройства используют тот же самый выпуск 8.0.x. Если дело обстоит не так, Вы должны сначала обновить ведомые устройства. Чтобы обновить каждое ведомое устройство, закройте это, обновите до соответствующей версии 8.0.x, перезапустите сервер и репликацию. Журналы реле, создаваемые ведомым устройством после обновления, находятся в форматах 8.0.

    Изменения, затрагивающие операции в строгом режиме SQL, могут привести к отказу репликации на обновленном ведомом устройстве. Например, сервер ограничивает вставку DEFAULT значения 0 для временных типов данных в строгом режиме (STRICT_TRANS_TABLES или STRICT_ALL_TABLES). Получающаяся несовместимость для репликации, если Вы используете основанное на запросе журналирование (binlog_format=STATEMENT ) это, если ведомое устройство будет обновлено, то необновленное ведущее устройство выполнит запросы без ошибки, которая может потерпеть неудачу на ведомом устройстве, и репликация остановится. Чтобы иметь дело с этим, остановите все новые запросы на ведущем устройстве и ждите, пока ведомые устройства его не нагонят. Тогда обновите ведомые устройства. Альтернативно, если Вы не можете остановить новые запросы, временно измените на основанный на строке формат журналирования ведущего устройства ( binlog_format=ROW) и ждите, пока все ведомые устройства не обработают все двоичные журналы, произведенные на грани этого изменения. Тогда обновите ведомые устройства.

    После того, как ведомые устройства были обновлены, закройте ведущее устройство, обновите до того же самого выпуска 8.0.x, как ведомые устройства, и перезапустите. Если Вы временно изменили ведущее устройство на основанное на строке журналирование, измените его назад на основанное на запросе журналирование. Ведущие устройства 8.0 в состоянии читать старые двоичные журналы, написанные до обновления и послать их в эти ведомые устройства 8.0. Ведомые устройства признают старый формат и обрабатывают его должным образом. Двоичные журналы, создаваемые ведущим устройством после обновления, находятся в форматах 8.0. Они также признаны ведомыми устройствами 8.0.

    Другими словами, обновляя до MySQL 8.0, ведомые устройства должны быть MySQL 8.0 прежде, чем Вы сможете обновить ведущее устройство до 8.0. Отметьте, что откат от 8.0 до более старых версий не работает так просто: Вы должны гарантировать, что любые двоичные журналы 8.0 или журналы реле 8.0 были полностью обработаны, так, чтобы Вы могли удалить их перед продолжением отката.

    Откат установки репликации к предыдущей версии не может быть сделан, как только Вы переключились от основанной на запросе на основанную на строке репликации, и после того, как первый основанный на строке запрос был написан в двоичный журнал. См. раздел 19.2.1.

    Некоторые обновления могут потребовать, чтобы Вы удалили и обновили объекты базы данных, когда Вы перемещаетесь от одного ряда MySQL до следующего. Например, изменения сопоставления могли бы потребовать пересоздания индексов таблицы. Такие операции, в случае необходимости, детализированы в разделе 2.10.1.1. Является самым безопасным выполнить эти операции отдельно на ведомых устройствах и ведущем устройстве и отключить репликацию этих операций от ведущего устройства к ведомому. Чтобы достигнуть этого, используйте следующую процедуру:

    1. Остановите все ведомые устройства и обновите их. Перезапустите их с --skip-slave-start, чтобы они не соединились с ведущим устройством. Выполните любые операции ремонта или восстановления таблицы, которые должны были обновить объекты базы данных, такие как использование REPAIR TABLE, ALTER TABLE или дамп и перезагрузка таблиц или триггеров.

    2. Отключите двоичный журнал ведущего устройства. Чтобы сделать это, не перезапуская ведущее устройство, выполните SET sql_log_bin = 0. Альтернативно, остановите ведущее устройство и перезапустите это без опции --log-bin. Если Вы перезапускаете ведущее устройство, Вы могли бы также хотеть отвергнуть соединения клиента. Например, если все клиенты соединяются с использованием TCP/IP, используйте --skip-networking , когда Вы перезапускаете ведущее устройство.
    3. С отключенным двоичным журналом выполните любые операции ремонта или восстановления таблицы, которые должны были обновить объекты базы данных. Двоичный журнал должен быть отключен во время этого шага, чтобы препятствовать тому, чтобы эти операции были зарегистрированы и посланы в ведомые устройства позже.
    4. Повторно включите двоичный журнал нга ведущем устройстве. Если Вы устанавливаете sql_log_bin = 0, выполните SET sql_log_bin = 1. Если Вы перезапускали ведущее устройство, чтобы отключить двоичной журнал, перезапустите его с --log-bin и без --skip-networking, чтобы клиенты и ведомые устройства могли соединиться.
    5. Перезапустите ведомые устройства, на сей раз без опции --skip-slave-start.

    Если Вы обновляете существующую установку репликации от версии MySQL, которая не поддерживает глобальные операционные идентификаторы к версии, которая это делает, Вы не должны включить GTID на ведущем или на ведомом устройстве прежде, чем удостоверитесь, что установка отвечает всем требованиям для GTID-репликации. Например, server_uuid, который был добавлен в MySQL 5.6, должен существовать для GTID, чтобы функционировать правильно. См. раздел 19.1.3.2, который содержит информацию о преобразовании существующих установок репликации, чтобы использовать GTID-репликацию.

    19.4.4. Поиск неисправностей репликации

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

    Если Вы не можете сказать из журнала ошибок, какова проблема, попробуйте следующие методы:

    19.4.5. Как сообщить об ошибках или проблемах репликации

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

    Если у Вас есть повторимый прецедент, который демонстрирует ошибку, пожалуйста, введите ее в нашу базу данных ошибок, используя инструкции, данные в разделе 1.7. Если у Вас есть призрак проблемы (который Вы не можете дублировать по желанию), используйте следующую процедуру:

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

    2. Выполните ведомое устройство с опциями --log-slave-updates и --log-bin. Эти опции заставляют ведомое устройство регистрировать обновления, которые оно получает от ведущего устройства в его собственные двоичные журналы.
    3. Сохраните все доказательства прежде, чем сбросить статус репликации. Если у нас нет никакой информации или она только отрывочна, становится трудным или невозможным для нас разыскать проблему. Доказательства, которые Вы должны собрать:

      • Все двоичные файлы системного журнала от ведущего устройства.

      • Все двоичные файлы системного журнала от ведомого устройства.
      • Вывод SHOW MASTER STATUS от ведущего устройства в то время, когда Вы обнаружили проблему.
      • Вывод SHOW SLAVE STATUS от ведомого устройства в то время, когда Вы обнаружили проблему.
      • Журналы ошибок от ведущего и ведомого устройств.

    4. Примените mysqlbinlog , чтобы исследовать двоичные журналы. Следующее должно быть полезным, чтобы найти проблемный запрос. log_file и log_pos это значения Master_Log_File и Read_Master_Log_Pos из SHOW SLAVE STATUS.
      shell> mysqlbinlog --start-position=log_pos log_file | head
      

    После того, как Вы собрали доказательства для проблемы, попытайтесь изолировать это как отдельный прецедент сначала. Тогда введите проблему с такой большой информацией насколько возможно в нашу базу данных ошибок, используя инструкции в разделе 1.7.