WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 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.2 имеет дело с конфигурацией серверов и обеспечивает методы для того, чтобы они скопировали данные между ведущим устройством и ведомыми устройствами. Для руководства по созданию двух или больше серверов для репликации, используя транзакции GTID раздел 19.1.3 имеет дело с конфигурацией серверов. События в двоичном журнале зарегистрированы, используя много форматов. Они упоминаются как основанная на запросе репликация (SBR) или основанная на строке репликация (RBR). Третий тип, репликация смешанного формата (MIXED), использует SBR или RBR автоматически, чтобы использовать в своих интересах выгоду форматов SBR и RBR. Различные форматы обсуждены в разделе 19.2.1. Подробная информация о различных параметрах конфигурации и переменных, которые относятся к репликации, обеспечена в разделе 19.1.6. После того, как запущен, процесс репликации должен потребовать небольшого контроля. Для советов относительно общих задач, которые Вы можете хотеть выполнить, см. раздел 19.1.7 . 19.1.1. Краткий обзор конфигурации репликации на основе двоичной позиции файла системного журнала Этот раздел описывает репликацию между серверами MySQL, основанными на двоичном методе позиции файла системного журнала, где случай MySQL, действующий в качестве ведущего устройства (источник изменений базы данных), пишет обновления и изменения как события в двоичный журнал. Информация в двоичном журнале хранится в различных форматах журналирования согласно зарегистрированным изменениям базы данных. Ведомые устройства сконфигурированы, чтобы считать двоичной журнал от ведущего устройства, и запускать события в местной базе данных ведомого устройства. Каждое ведомое устройство получает копию всего содержания двоичного журнала. Обязанность ведомого устройства решить, какие запросы в двоичном журнале должны быть выполнены. Если Вы не определяете иначе, все события в основном двоичном журнале запущены на ведомом устройстве. Если требуется, Вы можете сконфигурировать ведомое устройство, чтобы обработать только события, которые относятся к особым базам данных или таблицам. Вы не можете сконфигурировать ведущее устройство, чтобы зарегистрировать только определенные события. Каждое ведомое устройство ведет учет двоичных координат журнала: имя файла и позиция в пределах файла, который это считало и обработало от ведущего устройства. Это означает, что многократные ведомые устройства могут быть соединены с ведущим устройством и выполнять различные части того же самого двоичного журнала. Поскольку ведомые устройства управляют этим процессом, отдельные ведомые устройства могут быть соединены и разъединены от сервера, не затрагивая работу ведущего устройства. Кроме того, потому что каждое ведомое устройство делает запись текущей позиции в пределах двоичного журнала, для ведомых устройств возможно быть разъединенным, повторно соединиться и затем продолжить обрабатывать. Ведущее устройство и каждое ведомое устройство должны быть сконфигурированы с уникальным ID (используя опцию server-id). Кроме того, каждое ведомое устройство должно быть сконфигурировано с информацией об основном имени хоста, имени файла системного журнала и позиции в пределах того файла. Этими деталями можно управлять изнутри сеанса MySQL, используя команду CHANGE MASTER TO на ведомом устройстве. Детали сохранены в пределах основного репозитария информации ведомого устройства, который может быть файлом или таблицей (см. раздел 19.2.4). 19.1.2. Установка двоичной позиции файла системного журнала Этот раздел описывает, как настроить сервер MySQL, чтобы использовать позиции двоичного файла системного журнала. Есть много различных методов для того, чтобы настроить репликацию, и точный метод, чтобы использовать, зависит от того, как Вы настраиваете репликацию, и есть ли у Вас уже данные в пределах Вашей основной базы данных. Есть некоторые задачи, которые характерны для всех установок: На ведущем устройстве Вы должны включить двоичное журналирование и сконфигурировать уникальный ID сервера. Это могло бы потребовать перезапуска сервера. См. раздел 19.1.2.1. На каждом ведомом устройстве, которое Вы хотите соединить с ведущим устройством, Вы должны сконфигурировать уникальный ID сервера. Это могло бы потребовать перезапуска сервера. См. раздел 19.1.2.2. Произвольно, создайте отдельного пользователя для своих ведомых устройств, чтобы использовать во время аутентификации с ведущим устройством, читая двоичной журнал для репликации. См. раздел 19.1.2.3. Прежде, чем создать снимок данных или запустить процесс репликации на ведущем устройстве Вы должны сделать запись текущей позиции в двоичном журнале. Вы нуждаетесь в этой информации, конфигурируя ведомое устройство так, чтобы ведомое устройство знало, где в пределах двоичного журнала начинать запускать события. См. раздел 19.1.2.4. Если Вы уже имеете данные по ведущему устройству и хотите использовать их, чтобы синхронизировать ведомое устройство, Вы должны создать снимок данных, чтобы скопировать данные к ведомому устройству. Механизм хранения, который Вы используете, оказывает влияние на то, как Вы создаете снимок. Когда Вы используете MyISAM , Вы должны прекратить обрабатывать запросы, чтобы получить блокировку чтения, затем получить текущие двоичные координаты журнала и вывести в дамп данные прежде, чем разрешить ведущему устройству продолжать выполнять запросы. Если Вы не остановите выполнение запросов, то дамп данных и основная информация о статусе не будут соответствовать, приводя к непоследовательным или поврежденным базам данных на ведомых устройствах. Для получения дополнительной информации о мультиплицировании см. раздел 19.1.2.4. Если Вы используете InnoDB, Вы не нуждаетесь в блокировке чтения, снимок данных достаточен. Для получения дополнительной информации см. раздел 16.18. Сконфигурируйте ведомое устройство с настройками для того, чтобы соединиться с ведущим устройством, такими как имя хоста, параметры входа в систему, двоичное имя файла системного журнала и позиция. См. раздел 19.1.2.7. Определенные шаги в пределах процесса установки требуют привилегии SUPER. Если у Вас нет этой привилегии, может быть невозможно включить репликацию. После конфигурирования основных опций, выберите свой сценарий: Чтобы настроить репликацию для новой установки ведущего устройства и ведомых устройств, которые не содержат данных, см. раздел 19.1.2.6.1. Чтобы настроить репликацию нового ведущего устройства, использующего данные от существующего сервера MySQL, см. раздел 19.1.2.6.2. Чтобы добавить ведомые устройства репликации существующей окружающей среды репликации, см. раздел 19.1.2.8. Прежде, чем управлять серверами репликации 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 После произведения изменений, перезапустите сервер. Следующие опции оказывают влияние на эту процедуру: Если Вы опускаете server-id (или ставите это явно к его значению по умолчанию 0), ведущее устройство отказывается от любых соединений от ведомых устройств. Для самой большой длительности и последовательности в использовании установки репликации InnoDB с транзакциями Вы должны использовать innodb_flush_log_at_trx_commit=1 и sync_binlog=1 в my.cnf на ведущем устройстве. Гарантируйте, что skip-networking не включена на Вашем ведущем устройстве репликации. Если сеть была отключена, ведомое устройство не может общаться с ведущим устройством, и репликация терпит неудачу. 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. Чтобы получить основные двоичные координаты журнала, следуйте этим шагам: Запустите сеанс на ведущем устройстве, соединяясь с этим клиентом командной строки, сбросьте все таблицы и заблокируйте запросы записи, выполняя FLUSH TABLES WITH READ LOCK : mysql> FLUSH TABLES WITH READ LOCK; Оставьте клиента, от которого Вы выполнили FLUSH TABLES, так, чтобы блокировка чтения осталась в силе. Если Вы выходите из клиента, блокировка будет снята. В другом сеансе на ведущем устройстве, используйте 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.6.1. 19.1.2.5. Выбор метода для снимков данных Если основная база данных содержит существующие данные, необходимо скопировать эти данные к каждому ведомому устройству. Есть различные способы вывести данные от основной базы данных. Следующие разделы описывают возможные варианты. Чтобы выбрать соответствующий метод дампа базы данных, выберите между этими опциями: Используйте mysqldump, чтобы создать дамп всех баз данных, которые Вы хотите копировать. Это рекомендуемый метод, особенно используя InnoDB. Если Ваша база данных сохранена в двоичных портативных файлах, Вы можете скопировать файлы необработанных данных к ведомому устройству. Это может быть более эффективным, чем использование mysqldump и импортирование файла на каждом ведомом устройстве, потому что это пропускает обновления индексов, когда переигрываются запросы INSERT. С такими механизмами хранения, как InnoDB это не рекомендуется. 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. Выберите одну из этих опций: Исключите все таблицы базы данных опцией --ignore-table . Назовите только те базы данных, которые Вы хотите вывести, опцией --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. Следующие файлы не требуются для репликации: Файлы, касающиеся базы данных mysql. Основной файл репозитария информации, если используется (см. раздел 19.2.4). Двоичные файлы системного журнала ведущего устройства. Любые файлы системного журнала реле. В зависимости от того, используете ли Вы InnoDB или нет, выберите одно из следующего: Если Вы используете InnoDB, чтобы получить самые последовательные результаты со снимком необработанных данных, закрывайте главный сервер следующим образом: Приобретите блокировку чтения и получите состояние ведущего устройства. См. раздел 19.1.2.4. В отдельном сеансе закройте главный сервер: shell> mysqladmin shutdown Сделайте копию файлов с данными MySQL. Следующие примеры показывают распространенные способы сделать это. Вы должны выбрать только один из них: shell> tar cf /tmp/db.tar ./data shell> zip -r /tmp/db.zip ./data shell> rsync --recursive ./data /tmp/dbdata Перезапустите главный сервер. Если Вы не используете InnoDB, Вы можете получить снимок системы от ведущего устройства, не закрывая сервер как описано в следующих шагах: Приобретите блокировку чтения и получите состояние ведущего устройства. См. раздел 19.1.2.4. Сделайте копию файлов с данными MySQL. Следующие примеры показывают распространенные способы сделать это. Вы должны выбрать только один из них: shell> tar cf /tmp/db.tar ./data shell> zip -r /tmp/db.zip ./data shell> rsync --recursive ./data /tmp/dbdata В клиенте, где Вы приобретали блокировку чтения, выпустите блокировку: mysql> UNLOCK TABLES; Как только Вы создали архив или копию базы данных, скопируйте файлы к каждому ведомому устройству прежде, чем запустить ведомый процесс репликации. 19.1.2.6. Установка ведомых устройств репликации Следующие разделы описывают, как настроить ведомые устройства. Прежде, чем Вы продолжите гарантируйте, что имеете: Сконфигурированное ведущее устройство MySQL с необходимыми свойствами конфигурации. См. раздел 19.1.2.1. Полученную основную информацию о статусе. См. раздел 19.1.2.4. На ведущем устройстве освобожденную блокировку чтения: mysql> UNLOCK TABLES; На ведомом устройстве отредактированную конфигурация MySQL. См. раздел 19.1.2.2. Следующие шаги зависят от того, есть ли у Вас существующие данные, чтобы импортировать к ведомому устройству или нет. См. раздел 19.1.2.5 для получения дополнительной информации. Выберите одно из следующего: Если у Вас нет снимка базы данных, чтобы импортировать, см. раздел 19.1.2.6.1. Если у Вас есть снимок базы данных, чтобы импортировать, см. раздел 19.1.2.6.2. 19.1.2.6.1. Установка репликации с новыми ведущим и ведомым устройствами Когда нет никакого снимка предыдущей базы данных, чтобы импортировать, сконфигурируйте ведомое устройство, чтобы запустить репликацию от нового ведущего устройства. Настройте репликацию между ведущим и новым ведомым устройствами: Запустите ведомое устройство MySQL. Выполните CHANGE MASTER TO , чтобы установить основную конфигурацию сервера репликации. См. раздел 19.1.2.7. Выполните эти шаги установки на каждом ведомом устройстве. Этот метод может также использоваться, если Вы настраиваете новые серверы, но имеете существующий дамп баз данных от различного сервера, который Вы хотите загрузить в Вашу конфигурацию репликации. Загружая данные в новое ведущее устройство, данные автоматически копируются ведомым устройствам. Если Вы настраиваете новую окружающую среду репликации, используя данные от различного существующего сервера базы данных, чтобы создать новое ведущее устройство, то выполняете файл дампа, произведенный от того сервера на новом ведущем устройстве. Обновления базы данных автоматически размножены к ведомым устройствам: shell> mysql -h master < fulldb.dump 19.1.2.6.2. Установка репликации с существующими данными Настраивая репликацию с существующими данными, передайте снимок от ведущего устройства к ведомому устройству перед запуском репликации. Процесс для того, чтобы импортировать данные к ведомому устройству зависит от того, как Вы создали снимок данных ведущего устройства. Выберите одно из следующего: Если Вы использовали mysqldump: Запустите ведомое устройство, используя опцию --skip-slave-start так, чтобы репликация не запустилась. Импортируйте файл дампа: shell> mysql < fulldb.dump Если Вы создали снимок, используя файлы необработанных данных: Извлеките файлы с данными в свой ведомый каталог данных. Например: shell> tar xvf dbdump.tar Вы, возможно, должны установить разрешения и собственность на файлах так, чтобы ведомый сервер мог получить доступ и изменить их. Запустите ведомое устройство, используя опцию --skip-slave-start , чтобы репликация не запустилась. Сконфигурируйте ведомое устройство с координатами репликации от ведущего устройства. Это говорит ведомому устройству двоичный файл системного журнала и позицию в пределах файла, где репликация должна запуститься. Кроме того, сконфигурируйте ведомое устройство с параметрами входа в систему и именем хоста ведущего устройства. Для получения дополнительной информации о CHANGE MASTER TO см. раздел 19.1.2.7. Запустите ведомые потоки: 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. Дублировать существующее ведомое устройство: Закройте существующее ведомое устройство: shell> mysqladmin shutdown Скопируйте каталог данных от существующего ведомого устройства на новое ведомое устройство. Вы можете сделать это, создавая архив, используя 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. Альтернативно, если Вы уже попытались запустить новое ведомое устройство и столкнулись с ошибками, как описанные ранее, то выполните следующие шаги: Если Вы еще этого не сделали, выполните STOP SLAVE на новом ведомом устройстве. Если Вы уже запустили существующее ведомое устройство снова, выполните STOP SLAVE на существующем ведомом устройстве также. Скопируйте содержание индексного файла журнала реле существующего ведомого устройства в индексный файл журнала реле нового ведомого устройства, перезаписывая любой контент в файле. Возобновите остающиеся шаги в этом разделе. Скопируйте основную информацию и репозитарии информации журнала реле (см. раздел 19.2.4) от существующего ведомого устройства на новое ведомое устройство. Они содержат текущие координаты журнала для двоичного журнала ведущего устройства и журнала реле ведомого устройства. Запустите существующее ведомое устройство. На новом ведомом устройстве отредактируйте конфигурацию и дайте новому ведомому устройству уникальный server-id не используемый ведущим устройством или любым из существующих ведомых устройств. Запустите новое ведомое устройство. Ведомое устройство использует информацию в своем основном репозитарии информации, чтобы запустить процесс репликации. 19.1.3. Репликация с глобальными операционными идентификаторами Этот раздел объясняет основанную на транзакции репликацию, используя global transaction identifiers (GTID). Используя GTID, каждая транзакция может быть идентифицирована и прослежена, поскольку это передано на сервере и применено любыми ведомыми устройствами, это означает, что не надо, используя GTID, обращаться к файлам системного журнала или позициям в пределах тех файлов, запуская новое ведомое устройство, что очень упрощает эти задачи. Поскольку GTID-репликация основана на транзакции, просто определить, последовательны ли ведущие устройства и ведомые устройства: пока все транзакции, переданные на ведущем устройстве, также переданы на ведомом устройстве, последовательность между этими двумя гарантируется. Вы можете использовать основанную на запросе или на строке репликацию с GTID (см. раздел 19.2.1), однако, для лучших результатов, мы рекомендуем, чтобы Вы использовали основанный на строке формат. Этот раздел обсуждает следующие темы: Как GTID определены и созданы и как они представлены в MySQL Server (см. раздел 19.1.3.1). Общая процедура для установки и запуска GTID-репликации (см. раздел 19.1.3.2). Предложенные методы для того, чтобы обеспечить новые серверы репликации, используя GTID (см. раздел 19.1.3.3). Ограничения и лимиты о которых Вы должны знать, используя GTID (см. раздел 19.1.3.4). Для информации о параметрах сервера MySQL и переменных, касающихся GTID, см. раздел 19.1.6.5. См. также раздел 13.17, который описывает функции SQL, поддержанные MySQL 8.0 для использования с GTID. 19.1.3.1. Понятия GTID Глобальный операционный идентификатор (GTID) является уникальным идентификатором, создаваемым и связанным с каждой транзакцией, переданной на сервере происхождения (ведущее устройство). Этот идентификатор уникален не только для сервера, на котором он произошел, но и уникален через все серверы в данной установке репликации. Есть 1 к 1 отображение между всеми транзакциями и всеми GTID. Следующие параграфы обеспечивают основное описание GTID: Наборы GTID. Таблица mysql.gtid_executed. Табличное сжатие mysql.gtid_executed. 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 состоят из следующих шагов: Транзакция выполнена и передана на ведущем устройстве. Этой транзакции назначают GTID с использованием UUID ведущего устройства и самого маленького операционного порядкового номера, отличного от нуля, используемого на этом сервере, GTID написан в двоичный журнал ведущего устройства (немедленно перед транзакцией непосредственно в журнале). После того, как двоичные данные о журнале переданы к ведомому устройству и хранятся в журнале реле ведомого устройства (используя установленные механизмы для этого, см. раздел 19.2), ведомое устройство читает GTID и устанавливает значение gtid_next в этот GTID. Это говорит ведомому устройству, что следующая транзакция должна быть зарегистрирована, используя этот GTID. Важно отметить, что ведомое устройство устанавливает gtid_next в контексте сеанса. Ведомое устройство проверяет, что этот GTID не использовался, чтобы зарегистрировать транзакцию в собственном двоичном журнале. Если этот GTID не использовался, ведомое устройство пишет GTID, применяет транзакцию и пишет транзакцию в свой двоичный журнал. Читая и проверяя GTID транзакции сначала, прежде, чем обработать транзакцию непосредственно, ведомое устройство гарантирует не только, что никакая предыдущая транзакция, имеющая этот GTID, не была применена на ведомом устройстве, но также и что никакой другой сеанс, который уже считал этот GTID, еще не передал связанную транзакцию. Другими словами, многим клиентам не разрешают применить ту же самую транзакцию одновременно. Так как 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: Если двоичное журналирование отключено (log_bin = OFF), сервер хранит GTID, принадлежащий каждой транзакции, вместе с транзакцией в таблице. Кроме того, когда двоичное журналирование отключено, эта таблица периодически сжимается на конфигурируемом пользователем уровне. Если двоичное журналирование включено (log_bin = ON), тогда в дополнение к хранению GTID в mysql.gtid_executed, всякий раз, когда двоичной журнал ротируется, или сервер закрыт, сервер пишет GTID для всех транзакций, которые были написаны в предыдущий двоичной журнал, в новый двоичной журнал. В случае сервера, останавливающегося неожиданно, набор GTID от предыдущего двоичного журнала не сохранен в mysql.gtid_executed. В этом случае эти GTID добавлены к таблице и к набору GTID в переменной gtid_executed во время восстановления. Таблица 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 из одного ведущего устройства и одного ведомого следующие: Если репликация уже работает, синхронизируйте оба сервера, делая их только для чтения. Остановите оба сервера. Перезапустите оба сервера с включенным GTID и правильно сконфигурированными опциями. Опции mysqld , необходимые, чтобы запустить серверы как описано, обсуждены в примере, который следует позже в этом разделе. server_uuid должен существовать для GTID, чтобы функционировать правильно. Проинструктируйте ведомое устройство использовать ведущее устройство в качестве хранилища данных репликации и использовать авторасположение, затем запустите ведомое устройство. Запросы SQL, чтобы достичь этого шага, описаны в примере, который следует позже в этом разделе. Включите режим чтения снова на обоих серверах, так, чтобы они могли принять обновления. В следующем примере уже работают два сервера, ведущее устройство и ведомое, используя двоичный журнал и основанный на позиции протокол репликации. Если Вы запускаете с новых серверов, см. разделы 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, чтобы запустить репликацию. Когда Вы включили многократным каналы на ведомом устройстве, Вы можете хотеть запускать все каналы или выбирать определенный канал, чтобы запустить. Чтобы запустить все в настоящее время сконфигурированные каналы репликации: START SLAVE thread_types; Чтобы запустить только названный канал, используйте FOR CHANNEL channel: START SLAVE thread_types FOR CHANNEL channel; Используйте опцию thread_types, чтобы выбрать определенные потоки, которые Вы хотите запустить на ведомом устройстве. См. раздел 14.4.2.6. 19.1.4.2.5. Остановка ведомых устройств мультирепликации STOP SLAVE может использоваться, чтобы остановить ведомое устройство репликации. По умолчанию, если Вы используете STOP SLAVE на ведомом устройстве мультирепликации, все каналы остановлены. Произвольно используйте FOR CHANNEL channel, чтобы остановить только определенный канал. Чтобы остановить все в настоящее время сконфигурированные каналы репликации: STOP SLAVE thread_types; Чтобы остановить только названный канал, используйте FOR CHANNEL channel: STOP SLAVE thread_types FOR CHANNEL channel; Используйте опцию thread_types, чтобы выбрать определенные потоки, которые Вы хотите остановилить на ведомом устройстве. См. раздел 14.4.2.7. 19.1.4.2.6. Сброс ведомых устройств мультирепликации RESET SLAVE может использоваться, чтобы сбросить ведомое устройство репликации. По умолчанию, если Вы используете RESET SLAVE на ведомом устройстве репликации, все каналы сброшены. Произвольно, используйте FOR CHANNEL channel , чтобы сбросить только определенный канал. Сбросить все в настоящее время сконфигурированные каналы репликации: RESET SLAVE; Чтобы сбросить только названный канал, используйте FOR CHANNEL channel: RESET SLAVE FOR CHANNEL channel; См. раздел 14.4.2.4. 19.1.4.3. Контроль за мультирепликацией Чтобы контролировать состояние репликации есть варианты: Используя таблицы Performance Schema. Первый столбец этих таблиц Channel_Name. Это позволяет Вам написать сложные запросы, основанные на Channel_Name как на ключе. См. раздел 23.9.11 . Используя SHOW SLAVE STATUS FOR CHANNEL channel_name. По умолчанию, если FOR CHANNEL channel_name не используется, эта команда показывает ведомое состояние для всех каналов с одной строкой на канал. Идентификатор channel_name добавлен как столбец в наборе результатов. Если FOR CHANNEL channel_name обеспечен, результаты показывают состояние только названного канала репликации. 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 идентифицированы глобальным операционным идентификатором (GTID) в форме UUID:NUMBER. Каждой транзакции GTID в журнале всегда предшествует Gtid_log_event. Транзакции GTID могут быть адресованы, используя GTID или имя файла и позицию. Анонимным транзакциям не назначают GTID, и MySQL гарантирует, что каждой анонимной транзакции в журнале предшествует Anonymous_gtid_log_event. В предыдущих версиях анонимным транзакциям не предшествовало никакое особое событие. Анонимные транзакции могут быть адресованы только используя имя файла и позицию. Используя 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 следующие и в этом порядке: OFF OFF_PERMISSIVE ON_PERMISSIVE ON Важно отметить что статус 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* В вышеупомянутой таблице записи: Y: gtid_mode ведущего и ведомого устройств совместимы. N: gtid_mode ведущего и ведомого устройств несовместимы. *: авторасположение может использоваться. В настоящее время выбираемое 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 В вышеупомянутой таблице записи: ANONYMOUS: произведет анонимную транзакцию. Ошибка: произведет ошибку и не в состоянии выполнить SET GTID_NEXT. UUID:NUMBER: произведет GTID с указанным UUID:NUMBER. Новый GTID: произведет GTID с автоматически произведенным числом. Когда двоичной журнал выключен и gtid_next = AUTOMATIC, GTID не произведен. Это совместимо с поведением предыдущих версий. 19.1.5.2. Включение транзакции GTID онлайн Этот раздел описывает, как включить транзакции GTID и произвольно авторасположение на серверах, которые уже используют анонимныме транзакции. Эта процедура не требует останова сервера и подходит для использования в производстве. Однако, если у Вас есть возможность остановить сервер, включая транзакциям GTID, этот процесс легче. Прежде, чем Вы начнете, гарантируйте, что серверы удовлетворяют следующим предварительным условиям: ВСЕ серверы в Вашей топологии должны использовать MySQL 5.7.6 или позже. Вы не можете включить транзакциям GTID онлайн на любом единственном сервере, если не все серверы, которые находятся в топологии, используют эту версию. Все серверы имеют gtid_mode в значении по умолчанию OFF. Следующая процедура может быть поставлена на паузу в любое время и позже возобновлена или отменена, чтобы отключить GTID. Это делает процедуру отказоустойчивой, потому что любые несвязанные проблемы, которые могут появиться в середине процедуры, могут быть обработаны как обычно, а затем процедура продолжена. Крайне важно, чтобы Вы завершили каждый шаг прежде, чем перейти к следующему шагу. Чтобы включить транзакции GTID: На каждом сервере выполните: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN; Позвольте серверу работать некоторое время с Вашей нормальной рабочей нагрузкой и контролируйте журналы. Если этот шаг вызывает какие-либо предупреждения в журнале, скорректируйте свое приложение так, чтобы это использовало только GTID-совместимые функции и не произвело предупреждений. Это первый важный шаг. Вы должны гарантировать, что никакие предупреждения не производятся в журналах ошибок прежде, чем идти дальше. На каждом сервере выполните: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON; На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE; Не имеет значения, какой сервер выполняет этот запрос сначала, но важно, чтобы все серверы завершили этот шаг прежде, чем любой сервер начнет следующий шаг. На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE; Не имеет значения, какой сервер выполняет этот запрос сначала. На каждом сервере ждите, пока переменная ONGOING_ANONYMOUS_TRANSACTION_COUNT не станет 0. Это может быть проверено, используя: SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT'; На ведомом устройстве репликации теоретически возможно, что это показывает ноль и затем отличное от нуля значение снова. Это не проблема, достаточно, что переменная показывает ноль однажды. Ждите всех транзакций, произведенных к шагу 5, чтобы копировать ко всем серверам. Вы можете сделать это, не останавливая обновления: единственная важная вещь состоит в том, что копируются все анонимные транзакции. См. раздел 19.1.5.4 для одного метода проверки, что все анонимные транзакции скопировались ко всем серверам. Если Вы используете двоичные журналы для чего-нибудь кроме репликации, например, резервного копирования момента времени и восстановления, ждете, пока Вы не нуждаетесь в старых двоичных журналах, имеющих транзакции без GTID. Например, после того, как шаг 6 завершился, Вы можете выполнить FLUSH LOGS на сервере, где Вы берете резервные копии. Тогда явно выполните резервное копирование или ждите следующей итерации любой периодической резервной подпрограммы, которую Вы, возможно, настроили. Идеально надо произвести чистку всех двоичных журналов, которые существовали, когда шаг 6 был завершен. Также ждите любого резервного копирования перед шагом 6. Это второй важный момент. Жизненно важно понять, что двоичные журналы, содержащие анонимные транзакции без GTID, не могут использоваться после следующего шага. После этого шага Вы должны убедиться, что транзакции без GTID не существуют нигде в топологии. На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = ON; На каждом сервере добавьте 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, когда сервер онлайн, но с изменением шагов. Единственной вещью, которая отличается, является пункт, в котором Вы ждете копирования зарегистрированных транзакций. Прежде, чем Вы начнете, гарантируйте, что серверы удовлетворяют следующим предварительным условиям: ВСЕ серверы в Вашей топологии должны использовать MySQL 5.7.6 или позже. Вы не можете включить транзакциям GTID онлайн на любом единственном сервере, если не все серверы, которые находятся в топологии, используют эту версию. Все серверы имеют gtid_mode в значение ON. Выполните следующее для каждого ведомого устройства, и если Вы используете мультирепликацию, сделайте это для каждого канала и включите 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']; На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE; На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE; На каждом сервере ждите, пока переменная @@GLOBAL.GTID_OWNED не станет пустой строкой, проверить это можно так: SELECT @@GLOBAL.GTID_OWNED; На ведомом устройстве репликации теоретически возможно, что это пусто и затем не пусто снова. Это не проблема, достаточно, что это пусто однажды. Ждите копирования всех транзакций, которые в настоящее время существуют в любом двоичном журнале, ко всем ведомым устройствам. См. раздел 19.1.5.4 для одного метода проверки, что все анонимные транзакции скопировались ко всем серверам. Если Вы используете двоичные журналы для чего-либо еще, кроме репликации, например, чтобы сделать копию момента времени, ждите, пока Вы не нуждаетесь в старых двоичных журналах, имеющих транзакции GTID. Например, после того, как шаг 5 завершился, Вы можете выполнить FLUSH LOGS на сервере, где Вы делаете резервное копирование. Тогда явно выполните резервное копирование или ждите следующей итерации любой периодической резервной подпрограммы, которую Вы, возможно, настроили. Идеально произведите чистку всех двоичных журналов, которые существовали, когда шаг 5 был завершен. Это важный момент во время этой процедуры. Важно понять, что журналы, содержащие транзакции GTID, не могут использоваться после следующего шага. Прежде чем продолжить, Вы должны убедиться, что транзакции GTID не существуют нигде в топологии. На каждом сервере выполните: SET @@GLOBAL.GTID_MODE = OFF; На каждом сервере установите в my.cnf gtid-mode=OFF. Если Вы хотите установить enforce_gtid_consistency=OFF, Вы можете сделать это теперь. После установки этого Вы должны добавить enforce_gtid_consistency=OFF к Вашему конфигурационному файлу. Если Вы хотите откатиться к более ранней версии MySQL, Вы можете сделать это теперь, используя нормальную процедуру. 19.1.5.4. Подтверждение репликации анонимных транзакций Этот раздел объясняет, как контролировать топологию репликации и проверить, что скопировались все анонимные транзакции. Это полезно, изменяя режим репликации онлайн, поскольку Вы можете проверить, что безопасно измениться на транзакции GTID. Есть несколько возможных способов ждать, чтобы скопировать транзакции: -Самый простой метод, который работает независимо от Вашей топологии, но полагается на синхронизацию, следующий: если Вы уверены, что ведомое устройство никогда не задерживается больше, чем на N секунд, только ждите некоторое время больше, чем N секунд. Или ждите в течение дня, или безотносительно периода времени, который Вы считаете безопасным для Вашего развертывания. Более безопасный метод в том смысле, что это не зависит от синхронизации: если у Вас есть ведущее устройство с одним или более ведомыми устройствами, сделайте следующее: На ведущем устройстве выполните: SHOW MASTER STATUS; Запишите значения в столбцах File и Position. На каждом ведомом устройстве, используйте информацию от ведущего устройства, чтобы выполнить: SELECT MASTER_POS_WAIT(file, position); Если у Вас есть ведущее устройство и несколько уровней ведомых устройств, или другими словами Вы имеете ведомые устройства ведомых устройств, повторите шаг 2 на каждом уровне. Если Вы используете круговую топологию репликации, где много серверов могут иметь много пишущих клиентов, выполните шаг 2 для каждого основного ведомого соединения, пока Вы не завершили полный круг. Повторите процесс так, чтобы Вы сделали полный круг дважды. Например, предположите, что у Вас есть три сервера A, B и C, копирующие по кругу так, чтобы A -> B -> C -> A. Процедура тогда: Сделайте шаг 1 на A и шаг 2 на B. Сделайте шаг 1 на B и шаг 2 на C. Сделайте шаг 1 на C и шаг 2 на A. Сделайте шаг 1 на A и шаг 2 на B. Сделайте шаг 1 на B и шаг 2 на C. Сделайте шаг 1 на C и шаг 2 на 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 следующим образом: Попытаться считать и использовать UUID, написанный в файле data_dir/auto.cnf (data_dir это каталог данных сервера). Если 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. Кроме того, ведомый поток ввода/вывода производит предупреждение, если любое из следующего истина: Не найдено никакое ведущее устройство, имеющее ожидаемый server_uuid. server_uuid ведущего устройства изменился, хотя не было запроса CHANGE MASTER TO. 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. Системные переменные, используемые на ведущих устройствах репликации Следующие системные переменные используются, чтобы управлять ведущими устройствами репликации: auto_increment_increment Системная Имя auto_increment_increment Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1 Минимум 1 Максимум 65535 auto_increment_increment и auto_increment_offset предназначены для использования с репликацией от ведущего устройства к ведущему устройству и могут использоваться, чтобы управлять работой столбцов AUTO_INCREMENT. Обе переменные имеют значения глобальное и сеанса, каждая может принять целочисленное значение между 1 и 65535 включительно. Установка значения любой из этих двух переменных к 0 установит значение в 1 вместо этого. Попытка установить значение любой из этих двух переменных к целому числу, больше 65535 или меньше 0 установит значение 65535. Попытка установить значение auto_increment_increment или auto_increment_offset к нецелому числу производит ошибку, и фактическое значение переменной остается неизменным. auto_increment_increment предназначена для использования с MySQL Cluster, который в настоящее время не поддерживается в MySQL 8.0. Эти две переменные влияют на поведение столбца AUTO_INCREMENT следующим образом: auto_increment_increment управляет интервалом между последовательными значениями столбца. Например: mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 1 | | auto_increment_offset | 1 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE autoinc1 -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY); Query OK, 0 rows affected (0.04 sec) mysql> SET @@auto_increment_increment=10; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 1 | +--------------------------+-------+ 2 rows in set (0.01 sec) mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | +-----+ 4 rows in set (0.00 sec) auto_increment_offset определяет начальную точку для значения AUTO_INCREMENT. Рассмотрите следующее, предполагая, что эти запросы выполнены во время того же самого сеанса, как пример, данный в описании auto_increment_increment: mysql> SET @@auto_increment_offset=5; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 5 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE autoinc2 -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY); Query OK, 0 rows affected (0.06 sec) mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc2; +-----+ | col | +-----+ | 5 | | 15 | | 25 | | 35 | +-----+ 4 rows in set (0.02 sec) Когда значение auto_increment_offset больше, чем auto_increment_increment, значение auto_increment_offset проигнорировано. Если любая из этих переменных изменена, а затем новые строки, вставлены в таблицу, содержащую AUTO_INCREMENT, результаты могут казаться парадоксальными потому, что серия AUTO_INCREMENT вычислены без отношения к любым значениям, уже существующим в столбце, и следующее вставленное значение является наименьшим в ряду, который больше, чем максимальное существующее значение в AUTO_INCREMENT. Ряд вычислен так: auto_increment_offset + N * auto_increment_increment где N положительное целочисленное значение в ряду [1, 2, 3, ...]: mysql> SHOW VARIABLES LIKE 'auto_inc%'; +--------------------------+-------+ | Variable_name | Value | +--------------------------+-------+ | auto_increment_increment | 10 | | auto_increment_offset | 5 | +--------------------------+-------+ 2 rows in set (0.00 sec) mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | +-----+ 4 rows in set (0.00 sec) mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL); Query OK, 4 rows affected (0.00 sec) Records: 4 Duplicates: 0 Warnings: 0 mysql> SELECT col FROM autoinc1; +-----+ | col | +-----+ | 1 | | 11 | | 21 | | 31 | | 35 | | 45 | | 55 | | 65 | +-----+ 8 rows in set (0.00 sec) Значения, показанные для auto_increment_increment и auto_increment_offset производят ряд 5 + N * 10, то есть, [5, 15, 25, 35, 45, ...]. Самое высокое значение, существующее в столбце col до INSERT 31, следующее доступное значение в AUTO_INCREMENT 35, таким образом, вставленные значения для col начнутся в этом пункте, результаты показаны для SELECT . Невозможно ограничить эффекты этих двух переменных единственной таблицей, эти переменные управляют поведением всех столбцов AUTO_INCREMENT во всех таблицах на сервере MySQL. Если глобальное значение переменной установлено, ее эффекты сохраняются, пока глобальное значение не изменено или переопределено, устанавливая значение сеанса, или пока mysqld не перезапущен. Если местное значение установлено, новые значения AUTO_INCREMENT действуют для всех таблиц, в которые новые строки вставлены текущим пользователем в сеансе, если значения не изменены во время сеанса. Значение по умолчанию auto_increment_increment 1. См. раздел 19.4.1.1 . auto_increment_offset Системная Имя auto_increment_offset Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1 Минимум 1 Максимум 65535 У этой переменной есть значение по умолчанию 1. Для получения дополнительной информации см. описание для auto_increment_increment. auto_increment_offset предназначена для использования с MySQL Cluster, который в настоящее время не поддерживается в MySQL 8.0. 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-* могут быть установлены только, когда ведомый сервер запускается. Связанные с репликацией системные переменные обсуждены позже в этом разделе. --log-slave-updates Командная строка --log-slave-updates Системная Имя log_slave_updates Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию OFF Обычно ведомое устройство не пишет обновлений, которые получены от главного сервера в собственный двоичный журнал. Эта опция заставляет ведомое устройство писать обновления, выполненные его потоком SQL к его собственному двоичному журналу. Для работы этой опции ведомое устройство должно быть запущено также с опцией --log-bin, чтобы включить двоичное журналирование. --log-slave-updates используется, когда Вы хотите объединить серверы репликации в цепочку. Например, Вы могли бы хотеть настроить серверы репликации, используя это расположение: A -> B -> C Здесь A служит ведущим устройством для ведомого устройства B, B служит ведущим устройством для ведомого устройства C. Для того, чтобы работать, B должно быть ведущим и ведомым устройством. Вы должны запустить A и B с --log-bin, чтобы включить двоичное журналирование, и B с --log-slave-updates так, чтобы обновления из A были зарегистрированы B в его двоичном журнале. --log-warnings[=level] Устаревшая 5.7.2 Командная строка --log-warnings[=#] Системная Имя log_warnings Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 2 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 2 Минимум 0 Максимум 18446744073709551615 log_error_verbosity должна использоваться вместо опции --log-warnings или переменной log_warnings. См. описания log_error_verbosity и log_warnings . Опция --log-warnings и переменная log_warnings устарели и будут удалены в будущем выпуске MySQL. Заставляет сервер делать запись большего количества сообщений в журнал ошибок о том, что это делает. Относительно репликации сервер производит предупреждения, что это преуспело в том, чтобы повторно соединиться после отказа сети или соединения и предоставляет информацию о том, как каждый ведомый поток запускался. Эта переменная включена по умолчанию со значением 2. Чтобы отключить это, установите в 0. Сервер регистрирует сообщения о запросах, которые опасны для основанного на запросе журналирования, если значение больше 0. Прерванные соединения и ошибки запрета доступа для новых попыток соединения зарегистрированы, если значение больше 1. См. раздел B.5.2.10. Эффекты этой опции не ограничены репликацией. Это производит предупреждения для разных действий сервера. --master-info-file=file_name Командная строка --master-info-file=file_name Допустимые значения Тип file name Значение по умолчанию master.info Имя, чтобы использовать для файла, в котором ведомое устройство делает запись информации о ведущем устройстве. Имя по умолчанию master.info в каталоге данных. Для информации о формате этого файла см. раздел 19.2.4.2. --master-retry-count=count Устаревшая 5.6.1 Командная строка --master-retry-count=# Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 86400 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 86400 Минимум 0 Максимум 18446744073709551615 Число раз, которое ведомое устройство пытается соединиться с ведущим устройством перед отказом. Повторные соединения предприняты с промежутками, установленными опцией MASTER_CONNECT_RETRY в CHANGE MASTER TO (по умолчанию 60). Повторное соединение вызвано, когда данные читаются ведомым согласно опции --slave-net-timeout. Значение по умолчанию 86400. Значение 0 указывает, что ведомое устройство пытается соединиться всегда. Эта опция устарела и будет удалена в будущем выпуске MySQL. Приложения должны быть обновлены, чтобы использовать MASTER_RETRY_COUNT в CHANGE MASTER TO. --max-relay-log-size=size Командная строка --max_relay_log_size=# Системная Имя max_relay_log_size Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 1073741824 Размер, в котором сервер ротирует файлы системного журнала реле автоматически. Если это значение является отличным от нуля, журнал реле ротируется автоматически, когда его размер превышает это значение. Если это значение ноль (значение по умолчанию), размер, в котором происходит ротация журнала реле, определен значением max_binlog_size . См. раздел 19.2.4.1. --relay-log=file_name Командная строка --relay-log=file_name Системная Имя relay_log Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Базовое имя для журнала реле. Для канала репликации по умолчанию базовое имя по умолчанию для журналов реле host_name-relay-bin. Для каналов репликации не по умолчанию базовое имя по умолчанию для журналов реле host_name-channel-relay-bin, где channel название канала репликации, зарегистрированного в этом журнале реле. Сервер пишет файл в каталоге данных, если базовое имя не дано с ведущим абсолютным путем, чтобы определить отличный каталог. Сервер создает файлы системного журнала реле в последовательности, добавляя числовой суффикс к базовому имени. Из-за манеры, в которой MySQL разбирает параметры сервера, если Вы определяете эту опцию, Вы должны поставлять значение, базовое имя по умолчанию используется, только если опция фактически не определена. Если Вы используете --relay-log не определяя значение, неожиданное поведение, вероятно, будет, это поведение зависит от других используемых опций, порядка, в котором они определены, и определены ли они на командной строке или в файле опции. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера см. раздел 5.2.3. Если Вы определяете эту опцию, определенное значение также используется как базовое имя для индексного файла журнала реле. Вы можете переопределить это поведение, определяя другое базовое имя индексного файла, используя опцию --relay-log-index . Когда сервер читает запись из индексного файла, он проверяет, содержит ли она относительный путь. Если это так, относительная часть пути заменена абсолютным путем, используя --relay-log. Абсолютный путь остается неизменным, в таком случае индексирование должно быть отредактировано вручную, чтобы позволить новому пути или путям использоваться. Ранее ручное вмешательство требовалось, перемещая двоичный журнал или файлы системного журнала реле (Bug #11745230, Bug #12133). Вы можете найти опцию --relay-log полезной в выполнении следующих задач: Создание журналов реле, чьи имена независимы от имен хоста. Если Вы должны поместить журнал реле в некоторую область кроме каталога данных, потому что Ваши журналы реле имеют тенденцию быть очень большими, и Вы не хотите уменьшать max_relay_log_size. Увеличить скорость при использовании балансирования загрузки между дисками. Вы можете получить имя файла системного журнала реле (и путь) из переменной relay_log_basename. --relay-log-index=file_name Командная строка --relay-log-index=file_name Системная Имя relay_log_index Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Имя, чтобы использовать для индексного файла журнала реле. Имя по умолчанию host_name-relay-bin.index в каталоге данных, где host_name название сервера. Для канала репликации по умолчанию имя по умолчанию host_name-relay-bin.index. Для каналов репликации не по умолчанию имя по умолчанию host_name-channel-relay-bin.index, где channel название канала репликации, зарегистрированного в этом журнале реле. Из-за манеры, в которой MySQL разбирает параметры сервера, если Вы определяете эту опцию, Вы должны поставлять значение, базовое имя значения по умолчанию используется, только если опция фактически не определена. Если Вы используете опцию --relay-log-index не определяя значение, неожиданное поведение, вероятно, будет, это поведение зависит от других используемых опций, порядка, в котором они определены, и определены ли они в командной строке или в файле опции. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера см. раздел 5.2.3. Если Вы определяете эту опцию, определенное значение также используется в качестве базового имени для журналов реле. Вы можете переопределить это поведение, определяя различное базовое имя файла системного журнала реле, используя опцию --relay-log. --relay-log-info-file=file_name Командная строка --relay-log-info-file=file_name Допустимые значения Тип file name Значение по умолчанию relay-log.info Имя, чтобы использовать для файла, в котором ведомое устройство делает запись информации о журналах реле. Имя по умолчанию relay-log.info в каталоге данных. Для информации о формате этого файла см. раздел 19.2.4.2. --relay-log-purge={0|1} Командная строка --relay_log_purge Системная Имя relay_log_purge Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию TRUE Отключить или включить автоматическую чистку журналов реле, как только они больше не нужны. Значение по умолчанию 1 (включить). Это глобальная переменная, которая может быть изменена динамически с SET GLOBAL relay_log_purge = N. Отключение чистки журнала реле, используя опцию --relay-log-recovery рискует последовательностью данных и поэтому не безопасна от катастрофического отказа. --relay-log-recovery={0|1} Командная строка --relay-log-recovery Допустимые значения Тип boolean Значение по умолчанию FALSE Немедленно включает автоматическое восстановление журнала реле после запуска сервера. Процесс восстановления создает новый файл системного журнала реле, инициализирует позицию потока SQL к этому новому журналу реле и инициализирует поток ввода/вывода к позиции потока SQL. Чтение журнала реле от ведущего устройства продолжается. Это должно использоваться после катастрофического отказа на ведомом устройстве репликации, чтобы гарантировать, что поврежденные журналы реле обработаны. Значение по умолчанию 0 (отключено). Чтобы обеспечить безопасное от катастрофического отказа ведомое устройство, эта опция должна быть включена (установлена в 1), --relay-log-info-repository должен быть установлен в TABLE, а relay-log-purge включена. Включение --relay-log-recovery, когда relay-log-purge выключена содержит риск чтения журнала реле из файлов, которые не были очищены, приводя к несогласованности данных, а поэтому не безопасно от катастрофического отказа. Используя мультипоточное ведомое устройство (другими словами slave_parallel_workers больше 0), несогласованности, такие как промежутки, могут произойти в последовательности транзакций, которые были выполнены от журнала реле. Включение --relay-log-recovery, когда есть несогласованности, вызывает ошибку, и опция не имеет никакого эффекта. Решение в этой ситуации состоит в том, чтобы скомандовать START SLAVE UNTIL SQL_AFTER_MTS_GAPS, что приводит сервер в более последовательный статус, затем RESET SLAVE, чтобы удалить журналы реле. См. раздел 19.4.1.34. --relay-log-space-limit=size Командная строка --relay_log_space_limit=# Системная Имя relay_log_space_limit Контекст переменной Глобальная Динамическая Нет Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 0 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 0 Минимум 0 Максимум 18446744073709551615 Эта опция устанавливает верхнюю границу полного размера в байтах всего журнала реле ведомое устройство. Значение 0 отменяет лимит. Это полезно для ведомого узла сервера, который ограничил дисковое пространство. Когда предел достигнут, поток ввода/вывода прекращает читать двоичные события журнала с главного сервера, пока поток SQL не нагонит и удалит некоторые неиспользованные журналы реле. Отметьте, что этот предел не является абсолютным: есть случаи, где поток SQL нуждается в большем количестве событий прежде, чем он сможет удалить журналы реле. В этом случае поток ввода/вывода превышает предел, пока для потока SQL не становится возможно удалить некоторые журналы реле, потому что не выполнение этого вызвало бы тупик. Вы не должны установить --relay-log-space-limit меньше чем два значения --max-relay-log-size (или --max-binlog-size, если --max-relay-log-size = 0). В этом случае есть шанс, что поток ввода/вывода ждет свободного пространства, потому что --relay-log-space-limit превышен, но поток SQL не имеет никакого журнала реле, чтобы произвести чистку и неспособен удовлетворить поток ввода/вывода. Это вынуждает поток ввода/вывода проигнорировать временно --relay-log-space-limit. --replicate-do-db=db_name Командная строка --replicate-do-db=name Допустимые значения Тип string Создает фильтр репликации, используя название базы данных. Такие фильтры могут также быть созданы, используя CHANGE REPLICATION FILTER REPLICATE_DO_DB. Точный эффект этой фильтрации зависит от того основанная на запросе или строке репликация используется и описан в следующих нескольких параграфах. Основанная на запросе репликация. Говорит ведомому потоку SQL ограничивать репликацию запросами, где база данных значения по умолчанию (то есть, выбрана через USE) db_name. Чтобы определить больше, чем одну базу данных, используйте эту опцию многократно, однажды для каждой базы данных, однако, выполнение этого не копирует запросы между базами данных, такие как UPDATE some_db.some_table SET foo='bar' в то время, как различная база данных (или никакая база данных) выбрана. Чтобы определить многократные базы данных, Вы должны использовать многократные копии этой опции. Поскольку имена базы данных могут содержать запятые, если Вы будете поставлять список разделенных запятой значений, то список будет обработан как название единственной базы данных. Пример того, что не работает, как Вы могли бы ожидать, используя основанную на запросе репликацию: если ведомое устройство запущено с --replicate-do-db=sales и Вы делаете следующие запросы на ведущем устройстве, UPDATE не копируется: USE prices; UPDATE sales.january SET amount=amount+1000; Главная причина для этого проверяется только значение базы данных по умолчанию. Трудно из одного только запроса знать, должно ли это копироваться (например, если Вы используете многотабличные запросы DELETE или UPDATE, которые действуют через многие базы данных). Также быстрее проверить только базу данных по умолчанию, а не все базы данных, если нет никакой потребности. Основанная на строке репликация. Говорит ведомому потоку SQL ограничивать репликацию базой данных db_name. Только таблицы, принадлежащие db_name изменены, текущая база данных не имеет никакого влияния на это. Предположите, что ведомое устройство запущено с --replicate-do-db=sales, основанная на строке репликация в действительности, затем следующие запросы выполнены на ведущем устройстве: USE prices; UPDATE sales.february SET amount=amount+100; Таблица february в базе данных sales на ведомом устройстве изменена UPDATE , это происходит безотносительно USE. Однако, выполнение следующих запросов на ведущем устройстве не имеет никакого эффекта на ведомое устройство, используя основанную на строке репликацию и --replicate-do-db=sales: USE prices; UPDATE prices.march SET amount=amount-25; Даже если запрос USE prices был изменен на USE sales, UPDATE все еще не скопировались бы. Другое важное различие того, как --replicate-do-db обработана в основанной на запросе репликации в противоположность основанной на строке репликации, происходит относительно запросов, которые относятся к многим базам данных. Предположите, что ведомое устройство запущено с --replicate-do-db=db1 и следующие запросы выполнены на ведущем устройстве: USE db1; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20; Если Вы используете основанную на запросе репликацию, то обе таблицы обновлены на ведомом устройстве. Однако, используя основанную на строке репликацию, только table1 затронута на ведомом устройстве, с тех пор table2 находится в другой базе данных, table2 на ведомом устройстве не изменена UPDATE . Теперь предположите, что вместо USE db1 выполнен USE db4: USE db4; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20; В этом случае UPDATE не имел бы никакого эффекта на ведомое устройство, используя основанную на запросе репликацию. Однако, если Вы используете основанную на строке репликацию, UPDATE изменил бы table1 на ведомом устройстве, но не table2. Другими словами, только таблицы в базе данных, названной --replicate-do-db изменены, и выбор базы данных значения по умолчанию не имеет никакого эффекта на это поведение. Если Вы нуждаетесь в обновлениях нескольких баз данных, используйте --replicate-wild-do-table=db_name.%. См. раздел 19.2.5. Эта опция затрагивает репликацию в той же самой манере, как --binlog-do-db журналирование и эффекты формата репликации как из формата журналирования в --binlog-do-db. Эта опция не имеет никакого эффекта на BEGIN, COMMIT или ROLLBACK. --replicate-ignore-db=db_name Командная строка --replicate-ignore-db=name Допустимые значения Тип string Создает фильтр репликации, используя название базы данных. Такие фильтры могут также быть созданы, используя CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB. Как с --replicate-do-db , точный эффект этой фильтрации зависит от формата репликации. Основанная на запросе репликация. Говорит ведомому потоку SQL не копировать любой запрос где база данных по умолчанию (то есть, выбранная USE) db_name. Основанная на строке репликация. Говорит ведомому потоку SQL не обновлять любые таблицы в базе данных db_name. База данных по умолчанию не имеет никакого эффекта. Используя основанную на запросе репликацию следующий пример не работает, как Вы могли бы ожидать. Предположите, что ведомое устройство запущено с --replicate-ignore-db=sales и Вы делаете следующие запросы на ведущем устройстве: USE prices; UPDATE sales.january SET amount=amount+1000; UPDATE копируется в таком случае потому, что --replicate-ignore-db применяется только к базе данных по умолчанию (определенной USE). Поскольку база данных sales была определена явно в запросе, запрос не фильтровался. Однако, используя основанную на строке репликацию запросы UPDATE не размножены к ведомому устройству, и копия ведомого устройства таблицы sales.january неизменна, в этом случае --replicate-ignore-db=sales причина того, что все изменения, произведенные в таблицах в копии базы данных ведущего устройства sales будут проигнорированы ведомым устройством. Чтобы определить больше, чем одну базу данных, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой базы данных. Поскольку имена базы данных могут содержать запятые, если Вы будете поставлять список разделенных запятой значений, то список будет обработан как название единственной базы данных. Вы не должны использовать эту опцию, если Вы используете обновления между базами данных, см. раздел 19.2.5. Если Вы нуждаетесь в обновлениях между базами данных, примените --replicate-wild-ignore-table=db_name.%, см. раздел 19.2.5. Эта опция не имеет никакого эффекта на BEGIN, COMMIT или ROLLBACK. --replicate-do-table=db_name.tbl_name Командная строка --replicate-do-table=name Допустимые значения Тип string Создает фильтр репликации, говоря ведомому потоку SQL ограничить репликацию данной таблицей. Чтобы определить больше, чем одну таблицу, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновлениях между базами данных и на обновлениях базы данных по умолчанию, в отличие от --replicate-do-db. См. раздел 19.2.5. Вы можете также создать такой фильтр, выполняя CHANGE REPLICATION FILTER REPLICATE_DO_TABLE. Эта опция затрагивает только запросы, которые относятся к таблицам. Это не затрагивает запросы, которые применяются только к другим объектам базы данных, таким как сохраненные подпрограммы. Чтобы фильтровать запросы, воздействующие на сохраненные подпрограммы, используйте одну или больше опций --replicate-*-db. --replicate-ignore-table=db_name.tbl_name Командная строка --replicate-ignore-table=name Допустимые значения Тип string Создает фильтр репликации, говоря ведомому потоку SQL не копировать любой запрос, который обновляет указанную таблицу, даже если какие-либо другие таблицы могли бы быть обновлены тем же самым запросом. Чтобы определить больше, чем одну таблицу, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновления между базами данных, в отличие от --replicate-ignore-db. См. раздел 19.2.5. Вы можете также создать такой фильтр с помощью CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE. Эта опция затрагивает только запросы, которые относятся к таблицам. Это не затрагивает запросы, которые применяются только к другим объектам базы данных, таким как сохраненные подпрограммы. Чтобы фильтровать запросы, воздействующие на сохраненные подпрограммы, используйте одну или больше опций --replicate-*-db. --replicate-rewrite-db=from_name->to_name Командная строка --replicate-rewrite-db=old_name->new_name Допустимые значения Тип string Говорит ведомому устройству создавать фильтр репликации, который преобразовывает базу данных по умолчанию (то есть, выбранную USE) в to_name, если это было from_name на ведущем устройстве. Только запросы, вовлекающие таблицы, затронуты (не такие запросы, как CREATE DATABASE, DROP DATABASE и ALTER DATABASE), и только если from_name база данных по умолчанию на ведущем устройстве. Чтобы определить многократные перезаписи, используйте эту опцию многократно. Сервер использует первое значение from_name, которое соответствует. Перевод имени базы данных сделан перед проверкой правила --replicate-*. Вы можете также создать такой фильтр командой CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB. Запросы, в которых имена таблиц квалифицированы с именами базы данных, используя эту опцию, не работают с опциями фильтрации репликации на уровне таблицы, например, --replicate-do-table. Предположите, что нам назвали базу данных a на ведущем устройстве и b на ведомом устройстве, каждая содержит таблицу t, и запустили ведущее устройство с --replicate-rewrite-db='a->b'. В более позднем моменте времени мы выполняем DELETE FROM a.t. В этом случае нет соответствующих правил фильтрации по причинам, показанным здесь: --replicate-do-table=a.t не работает, потому что у ведомого устройства есть таблица t в b. --replicate-do-table=b.t не соответствует оригинальному запросу и проигнорировано. --replicate-do-table=*.t обработан тождественно к --replicate-do-table=a.t и таким образом не работает также. Точно так же опция --replication-rewrite-db не работает с обновлениями между базами данных. Если Вы используете эту опцию на командной строке и символ > является специальным для Вашего интерпретаторы команд, заключите значение опции в кавычки. Например: shell> mysqld --replicate-rewrite-db="olddb->newdb" --replicate-same-server-id Командная строка --replicate-same-server-id Допустимые значения Тип boolean Значение по умолчанию FALSE Применяется на ведомых серверах. Обычно Вы должны использовать настройку по умолчанию 0, чтобы предотвратить бесконечные петли, вызванные круговой репликацией. Если установлено в 1, ведомое устройство не пропускает события, имеющие его собственный ID сервера. Обычно это полезно только в редких конфигурациях. Не может быть установлен в 1, если используется --log-slave-updates. По умолчанию ведомый поток ввода/вывода не пишет двоичные события журнала журналу реле, если у них есть ID сервера ведомого устройства (эта оптимизация помогает сохранить диск). Если Вы хотите использовать --replicate-same-server-id, убедитесь, что запустили ведомое устройство с этой опции прежде, чем Вы заставите ведомое устройство читать свои собственные события, которые Вы хотите, чтобы ведомый поток SQL запустил. --replicate-wild-do-table=db_name.tbl_name Командная строка --replicate-wild-do-table=name Допустимые значения Тип string Создает фильтр репликации, говоря ведомому потоку ограничить репликацию запросами, где любая из обновленных таблиц соответствует указанной базе данных и образцам имени таблицы. Образцы могут содержать % и _, у которых есть то же самое значение, что касается оператора LIKE. Чтобы определить больше, чем одну таблицу, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновлениях между базами данных. См. раздел 19.2.5. Вы можете также создать такой фильтр через CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE. Эта опция относится к таблицам, представлениям и триггерам. Это не относится к хранимым процедурам и функциям или событиям. Чтобы фильтровать запросы, воздействующие на последние объекты, используйте одну или больше опций --replicate-*-db. Пример: --replicate-wild-do-table=foo%.bar% копирует только обновления, которые используют таблицу, где имя базы данных начинается с foo и имя таблицы начинается с bar. Если образец имени таблицы %, это соответствует любому имени таблицы и опция также относится к запросам на уровне базы данных (CREATE DATABASE, DROP DATABASE и ALTER DATABASE). Например, если Вы используете --replicate-wild-do-table=foo%.%, запросы на уровне базы данных копируются, если имя базы данных соответствует образцу foo%. Чтобы включать буквальные подстановочные символы в имя базы данных или образцы имени таблицы, выйдите из них с наклонной чертой влево. Например, чтобы копировать все таблицы базы данных, которую называют my_own%db, но не копировать таблицы от базы данных my1ownAABCdb, Вы должны экранировать _ и %: --replicate-wild-do-table=my\_own\%db. Если Вы используете опцию в командной строке, Вы, возможно, должны были бы удвоить наклонные черты влево или заключить значение опции в кавычки, в зависимости от Вашего интерпретатора команды. Например, с оболочкой bash, Вы должны были бы ввести --replicate-wild-do-table=my\\_own\\%db. --replicate-wild-ignore-table=db_name.tbl_name Командная строка --replicate-wild-ignore-table=name Допустимые значения Тип string Создает фильтр репликации, который препятствует ведомому потоку копировать запрос, в котором любая таблица соответствует данному подстановочному образцу. Чтобы определить больше, чем одну таблицу, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновлениях между базами данных. См. раздел 19.2.5. Вы можете также создать такой фильтр через CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE. Пример: --replicate-wild-ignore-table=foo%.bar% не копирует обновления, которые используют таблицу, где имя базы данных начинается с foo и имя таблицы начинается с bar. Для информации о том, как соответствие работает, см. описание опции --replicate-wild-do-table. Правила для включения буквальных подстановочных символов в значении опции являются теми же самыми, что касается --replicate-wild-ignore-table. --report-host=host_name Командная строка --report-host=host_name Системная Имя report_host Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Имя хоста или IP-адрес ведомого устройства, о котором сообщат ведущему устройству во время ведомой регистрации. Это значение появляется в выводе SHOW SLAVE HOSTS на главном сервере. Оставьте значение неопределенным, если Вы не хотите, чтобы ведомое устройство зарегистрировало себя в ведущем устройстве. Недостаточно для ведущего устройства просто считать IP-адрес ведомого устройства от TCP/IP после того, как ведомое устройство соединяется. Из-за NAT и других проблем маршрутизации, тот IP, возможно, недопустим для того, чтобы соединиться с ведомым устройством от ведущего устройства или других узлов. --report-password=password Командная строка --report-password=name Системная Имя report_password Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Пароль учетной записи ведомого устройства, о котором сообщат ведущему устройству во время ведомой регистрации. Это значение появляется в выводе SHOW SLAVE HOSTS на главном сервере, если дана опция --show-slave-auth-info. Хотя название этой опции могло бы подразумевать иное, --report-password не соединен с пользовательской системой привилегии MySQL и также не обязательно тот же самый, как пароль для учетной записи пользователя репликации MySQL. --report-port=slave_port_num Командная строка --report-port=# Системная Имя report_port Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип integer Значение по умолчанию [slave_port] Минимум 0 Максимум 65535 Номер порта TCP/IP для того, чтобы соединиться с ведомым устройством, сообщен ведущему устройству во время ведомой регистрации. Установите это, только если ведомое устройство слушает на порту не по умолчанию или если у Вас есть специальный туннель от ведущего устройства или других клиентов к ведомому устройству. Если Вы не уверены, не используйте эту опцию. Значение по умолчанию для этой опции номер порта, фактически используемый ведомым устройством (Bug #13333431). Это также значение по умолчанию, выведенное на экран SHOW SLAVE HOSTS. --report-user=user_name Командная строка --report-user=name Системная Имя report_user Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Имя пользователя учетной записи ведомого устройства, о котором сообщат ведущему устройству во время ведомой регистрации. Это значение появляется в выводе SHOW SLAVE HOSTS на главном сервере, если задана опция --show-slave-auth-info. Хотя название этой опции могло бы подразумевать иное, --report-user не соединен с пользовательской системой привилегии MySQL и не обязательно то же самое, как название учетной записи пользователя репликации MySQL. --show-slave-auth-info Командная строка --show-slave-auth-info Допустимые значения Тип boolean Значение по умолчанию FALSE Вывести на экран ведомые имена пользователя и пароли в выводе SHOW SLAVE HOSTS на главном сервере для ведомых устройств, запущенных с опциями --report-user и --report-password. --slave-checkpoint-group=# Командная строка --slave-checkpoint-group=# Допустимые значения Тип integer Значение по умолчанию 512 Минимум 32 Максимум 524280 Block Size 8 Устанавливает максимальное количество транзакций, которые могут быть обработаны мультипоточным ведомым устройством прежде, чем вызовут работу контрольной точки, чтобы обновить ее состояние как показано SHOW SLAVE STATUS. Установка этой опции не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Эта опция работает в комбинации с --slave-checkpoint-period таким способом, которым, когда любой предел превышен, контрольная точка выполнена и счетчики, отслеживающие число транзакций и время, начиная с последней контрольной точки, сброшены. Минимальное позволенное значение для этой опции 32, если сервер не был создан, используя -DWITH_DEBUG, когда минимальное значение 1. Действующее значение всегда кратно числу 8, Вы можете установить это в значение, которое не является таким кратным числом, но сервер округляет это в меньшую сторону к следующему кратному 8 прежде, чем сохранить значение. Исключение: Никакое округление не выполнено сервером для отладки. Независимо от того, как сервер был создан, значение по умолчанию 512, и максимальное позволенное значение 524280. --slave-checkpoint-period=# Командная строка --slave-checkpoint-period=# Допустимые значения Тип integer Значение по умолчанию 300 Минимум 1 Максимум 4G Устанавливает максимальное время (в миллисекундах), которому позволяют пройти прежде, чем вызовут работу контрольной точки , чтобы обновить состояние мультипоточного ведомого устройства как показано SHOW SLAVE STATUS. Установка этой опции не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Эта опция работает в комбинации с --slave-checkpoint-group таким способом, которым, когда любой предел превышен, контрольная точка выполнена и счетчики, отслеживающие число транзакций и время, начиная с последней контрольной точки, сброшены. Минимальное позволенное значение для этой опции 1, если сервер не был создан, используя -DWITH_DEBUG, когда минимальное значение 0. Независимо от того, как был создан сервер, значение по умолчанию 300 и максимальное возможное значение 4294967296 (4GB). --slave-parallel-workers Командная строка --slave-parallel-workers=# Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 1024 Определяет число применяющих потоков ведомого устройства для того, чтобы выполнить транзакции репликации параллельно. Установка этой переменной к числу, больше чем 0, создает мультипоточное ведомое устройство с этим числом потоков. Когда установлено в 0 (значение по умолчанию) параллельное выполнение отключено, и ведомое устройство использует единственный поток. Мультипоточное ведомое устройство обеспечивает параллельное выполнение при использовании потока координатора и числа потоков применения, сконфигурированных этой опцией. Способ, которым транзакции распределены среди потоков, сконфигурирован --slave-parallel-type. Для получения дополнительной информации о мультипоточных ведомых устройствах см. slave-parallel-workers. --slave-pending-jobs-size-max=# Командная строка --slave-pending-jobs-size-max=# Допустимые значения Тип integer Значение по умолчанию 16M Минимум 1024 Максимум 18EB Block Size 1024 Для мультипоточных ведомых устройств эта опция устанавливает максимальный объем памяти (в байтах) доступный очередям, хранящим еще не примененные события. Установка этой опции не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Минимальное возможное значение для этой опции 1024, значение по умолчанию составляет 16 МБ. Максимальное возможное значение 18446744073709551615 (16 exabytes). Значения, которые не являются точно кратными 1024, округлены в меньшую сторону к следующему самому большому кратному 1024 числу до того, как будут сохранены. Значение для этой опции не должно быть меньше, чем значение ведущего устройства для max_allowed_packet, иначе очередь может стать полной, в то время как там остаются события, прибывающие от ведущего устройства, чтобы быть обработанными. --skip-slave-start Командная строка --skip-slave-start Допустимые значения Тип boolean Значение по умолчанию FALSE Говорит ведомому серверу не запускать ведомые потоки, когда сервер запускается. Чтобы запустить потоки позже, используйте START SLAVE. --slave_compressed_protocol={0|1} Командная строка --slave_compressed_protocol Системная Имя slave_compressed_protocol Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию OFF Если эта опция установлена в 1, используйте сжатие для ведомого/основного протокола если ведомое и основное устройства его понимают. Значение по умолчанию 0 (никакого сжатия). --slave-load-tmpdir=dir_name Командная строка --slave-load-tmpdir=dir_name Системная Имя slave_load_tmpdir Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип directory name Значение по умолчанию /tmp Название каталога, где ведомое устройство создает временные файлы. Эта опция по умолчанию равна значению tmpdir. Когда ведомый поток SQL копирует LOAD DATA INFILE, это извлекает файл, который будет загружен из журнала реле во временные файлы, и затем загружает их в таблицу. Если файл, загруженный на ведущем устройстве, огромен, временные файлы на ведомом устройстве также огромны. Поэтому могло бы быть желательно использовать эту опцию, чтобы сказать ведомому устройству помещать временные файлы в каталог, расположенный в некоторой файловой системе, у которой есть много свободного места. В этом случае журналы реле также огромны, таким образом, Вы могли бы также хотеть использовать --relay-log, чтобы поместить журналы реле туда, где есть место. Каталог, определенный этой опцией, должен быть расположен в основанной на диске файловой системе (не основанной на памяти файловой системе), потому что временные файлы для копирования LOAD DATA INFILE должны пережить машинные перезапуски. Каталог также не должен быть тем, который очищен операционной системой во время системного процесса запуска. slave-max-allowed-packet=bytes Командная строка --slave-max-allowed-packet=# Допустимые значения Тип integer Значение по умолчанию 1073741824 Минимум 1024 Максимум 1073741824 Эта опция устанавливает максимальный пакетный размер в байтах для ведомого SQL и потоков ввода/вывода, чтобы большие обновления, используя основанную на строке репликацию не заставили репликацию терпеть неудачу, потому что обновление превысило max_allowed_packet (Bug #12400221, Bug #60926). Соответствующая переменная сервера slave_max_allowed_packet всегда имеет значение, которое является положительным целым числом, кратным 1024, если Вы устанавливаете это в некоторое значение, которое не является таким кратным числом, значение автоматически округлено в меньшую сторону к следующему самому большому числу, кратному 1024. Например, если Вы запускаете сервер с --slave-max-allowed-packet=10000, используемое значение 9216, установка 0 заставляет использоваться 1024. Предупреждение выпущено в таких случаях. Максимум (и значение по умолчанию) значение 1073741824 (1 GB), минимум 1024. --slave-net-timeout=seconds Командная строка --slave-net-timeout=# Системная Имя slave_net_timeout Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 3600 Минимум 1 Допустимые значения Тип integer Значение по умолчанию 60 Минимум 1 Число секунд, чтобы ждать большего количества данных от ведущего устройства перед тем, как ведомое устройство считает соединение сломанным, прерывает чтение и пытается повторно соединиться. Первая повторная попытка происходит немедленно после тайм-аута. Интервалом между повторениями управляет опция MASTER_CONNECT_RETRY в CHANGE MASTER TO, число попыток пересоединения ограничено --master-retry-count. Значение по умолчанию составляет 60 секунд (одна минута). --slave-parallel-type=type Командная строка --slave-parallel-type=type Допустимые значения Тип enumeration Значение по умолчанию DATABASE Допустимые значения DATABASE LOGICAL_CLOCK Используя мультипоточное ведомое устройство ( slave_parallel_workers больше 0), эта опция определяет, какая политика решает, которым транзакциям позволяют выполниться параллельно на ведомом устройстве. Возможные значения: DATABASE: транзакции, которые обновляют различные базы данных, применены параллельно. Это значение является соответствующим только, если данные разделены на многие базы данных, которые обновляются независимо и одновременно на ведущем устройстве. Рекомендуется только, если нет никаких ограничений между базами данных, ограничения как таковые могут быть нарушены на ведомом устройстве. LOGICAL_CLOCK: транзакции, которые являются частью той же самой двоичной группы журнала на ведущем устройстве, применены параллельно на ведомом устройстве. Нет никаких ограничений базы данных, и данные не должны быть разделены на много баз данных. Независимо от значения этой переменной нет никакой специальной конфигурации, требуемой на ведущем устройстве. Когда slave_preserve_commit_order=1, Вы можете использовать только LOGICAL_CLOCK. Если Ваша топология репликации использует многократные уровни ведомых устройств, LOGICAL_CLOCK может достигнуть меньшей параллельности для каждого уровня. slave-rows-search-algorithms=list Командная строка --slave-rows-search-algorithms=list Допустимые значения Тип set Значение по умолчанию TABLE_SCAN,INDEX_SCAN Допустимые значения TABLE_SCAN,INDEX_SCAN INDEX_SCAN,HASH_SCAN TABLE_SCAN,HASH_SCAN TABLE_SCAN,INDEX_SCAN,HASH_SCAN (equivalent to INDEX_SCAN,HASH_SCAN) Готовя пакеты строк для основанного на строке журналирования и репликации, эта опция управляет, как строки разыскиваются, то есть, используется ли хеширование для поисков, используя основной или уникальный ключ, некоторый другой ключ или никакой ключ вообще. Эта опция берет список разделенных запятой любых 2 (или возможно 3) значений из списка INDEX_SCAN, TABLE_SCAN, HASH_SCAN. Список не должен быть заключен в кавычки, но не должен содержать пробелы. Возможные комбинации (списки) и их эффекты показывают в следующей таблице: Используемый индекс/значение опции INDEX_SCAN,HASH_SCAN или INDEX_SCAN,TABLE_SCAN,HASH_SCAN INDEX_SCAN,TABLE_SCAN TABLE_SCAN,HASH_SCAN Первичный или уникальный ключ . Просмотр индекса. Просмотр индекса. Просмотр хеш-индекса. (Другой) ключ Просмотр хеш-индекса. Просмотр индекса. Просмотр хеш-индекса. Индекс не применен. Просмотр хеша. Сканирование таблицы. Просмотр хеша. Порядок, в котором алгоритмы определены в списке, не имеет никакого значения в порядке, в котором они выведены на экран SELECT или SHOW VARIABLES (который является тем же самым, как используемый в показанной таблице). Значение по умолчанию TABLE_SCAN,INDEX_SCAN, что означает, что все поиски, которые могут использовать индекс, действительно используют их, и поиски без индексов используют сканирование таблицы. Указание INDEX_SCAN,TABLE_SCAN,HASH_SCAN аналогично INDEX_SCAN,HASH_SCAN. Чтобы использовать хеширование для любых поисков, которые не используют основной или уникальный ключ, устанавливайте эту опцию в INDEX_SCAN,HASH_SCAN. Чтобы вызвать хеширование для всех поисков, установите это в TABLE_SCAN,HASH_SCAN. Есть исполнительное преимущество для INDEX_SCAN и HASH_SCAN только, если события строки являются достаточно большими. Размер событий строки сконфигурирован, используя --binlog-row-event-max-size. Например, предположите, что DELETE, который удаляет 25000 строк, производит большое событие Delete_row_event. В этом случае если slave_rows_search_algorithms установлен в INDEX_SCAN или HASH_SCAN есть прибавка в скорости. Однако, если есть 25000 запросов DELETE и каждый представлен отдельным событием, тогда установка slave_rows_search_algorithms в INDEX_SCAN или HASH_SCAN не обеспечивает исполнительного ускорения, запуская эти отдельные события. --slave-skip-errors=[err_code1, err_code2,...|all|ddl_exist_errors] Командная строка --slave-skip-errors=name Системная Имя slave_skip_errors Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [list of error codes] all ddl_exist_errors Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [list of error codes] all ddl_exist_errors Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [list of error codes] all ddl_exist_errors Обычно репликация останавливается, когда ошибка происходит на ведомом устройстве, что дает Вам возможность решить несогласованность в данных вручную. Эта опция заставляет ведомый поток SQL продолжать репликацию, когда запрос возвращает любую из ошибок, перечисленных в значении опции. Не используйте эту опцию, если Вы полностью не понимаете, почему Вы получаете ошибки. Если нет никаких ошибок в Вашей установке репликации и программах клиента и никаких ошибок в MySQL непосредственно, ошибка, которая останавливает репликацию, никогда не должна происходить. Неразборчивое использование этой опции приводит к ведомым устройствам, безнадежно вышедшими из синхронизации с ведущим устройством, а Вы понятия не имеете, почему это произошло. Для кодов ошибки Вы должны использовать числа, обеспеченные сообщением об ошибке в Вашем ведомом журнале ошибок и в выводе SHOW SLAVE STATUS. Приложение B перечисляет коды ошибок сервера. Вы можете также (но не должны) использовать очень нерекомендуемое значение all, чтобы заставить ведомое устройство игнорировать все сообщения об ошибках и продолжать работу независимо от того, что происходит. Само собой разумеется, если Вы используете all, нет никаких гарантий относительно целостности Ваших данных. Пожалуйста, не жалуйтесь в этом случае, если данные ведомого устройства близко не похожи на то, что находится на ведущем устройстве. Вы были предупреждены. MySQL 8.0 понимает дополнительное значение ddl_exist_errors, которое эквивалентно списку кодов ошибки 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146. Примеры: --slave-skip-errors=1062,1053 --slave-skip-errors=all --slave-skip-errors=ddl_exist_errors --slave-sql-verify-checksum={0|1} Командная строка --slave-sql-verify-checksum=value Допустимые значения Тип boolean Значение по умолчанию 0 Допустимые значения 0 1 Когда эта опция включена, ведомое устройство исследует контрольные суммы, считанные из журнала реле, в случае несоответствия встает с ошибкой. Отключена по умолчанию. Следующие опции используются внутренне испытательным набором MySQL для тестирования репликации и отладки. Они не предназначены для использования в производственной установке. --abort-slave-event-count Командная строка --abort-slave-event-count=# Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Когда эта опция установлена в некоторое положительное целое число value не 0 (по умолчанию) это затрагивает поведение репликации следующим образом: после того, как ведомый поток SQL запустился, value событиям журнала разрешают быть запущенными, после этого ведомый поток SQL больше не получает события, как если бы сетевое соединение от ведущего устройства было отключено. Ведомый поток продолжает работать, и вывод SHOW SLAVE STATUS покажет Yes в обоих столбцах Slave_IO_Running и Slave_SQL_Running, но никакие дальнейшие события не считаны из журнала реле. Опции для журналирования состояния ведомого в таблицы MySQL 8.0 допускает журналирование ведомой информации о статусе репликации к таблицам, а не файлам. Запись основного журнала информации и журнала информации журнала реле может быть сконфигурировано, отдельно используя эти два параметра сервера, перечисленные здесь: --master-info-repository={FILE|TABLE} Командная строка --master-info-repository=FILE|TABLE Допустимые значения Тип string Значение по умолчанию FILE Допустимые значения FILE TABLE Эта опция заставляет сервер писать свой основной журнал информации в файл или таблицу. Имя файла по умолчанию master.info, Вы можете поменять имя файла, используя опцию --master-info-file. Значение по умолчанию для этой опции FILE. Если Вы используете TABLE, журнал написан в таблицу slave_master_info базы данных mysql. --relay-log-info-repository={FILE|TABLE} Командная строка --relay-log-info-repository=FILE|TABLE Допустимые значения Тип string Значение по умолчанию FILE Допустимые значения FILE TABLE Эта опция заставляет сервер регистрировать свою информацию журнала реле в файле или таблице. Имя файла по умолчанию relay-log.info, Вы можете поменять имя файла, используя опцию --relay-log-info-file. Значение по умолчанию для этой опции FILE. Если Вы используете TABLE, журнал написан в таблицу slave_relay_log_info базы данных mysql. Для репликации, чтобы быть безопасной от катастрофического отказа, эта опция должна быть установлена в TABLE, кроме того опция --relay-log-recovery должна быть включена. Таблицы журнала информации и их содержание считают местными к данному MySQL Server. Они не копируются, и изменения в них не написаны в двоичный журнал. См. раздел 19.2.4. Системные переменные, используемые на ведомых устройствах репликации Следующий список описывает системные переменные для того, чтобы управлять ведомыми серверами репликации. Они могут быть установлены при запуске сервера и некоторые из них могут быть изменены во время выполнения при использовании SET. Параметры сервера, используемые с ведомыми устройствами репликации, перечислены ранее в этом разделе. slave_allow_batching Командная строка --slave-allow-batching Системная Имя slave_allow_batching Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию off Включены ли пакетные обновления на ведомых устройствах репликации. init_slave Командная строка --init-slave=name Системная Имя init_slave Контекст переменной Глобальная Динамическая Да Допустимые значения Тип string Эта переменная подобна init_connect, но строка будет выполнена ведомым сервером каждый раз, когда поток SQL запускается. Формат строки тот же самый, что касается init_connect. Установка этой переменной вступает в силу для последующего START SLAVE. Поток SQL посылает ответ клиенту прежде, чем выполнит init_slave. Поэтому не гарантируется, что init_slave был выполнен вместе с START SLAVE, см. раздел 14.4.2.6. log_slow_slave_statements Системная Имя log_slow_slave_statements Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию OFF Когда медленный журнал запроса включен, эта переменная позволяет регистрировать запросы, которые взяли больше, чем long_query_time секунд, чтобы выполниться на ведомом устройстве. Установка этой переменной не имеет никакого непосредственного эффекта. статус переменной применяется на всех последующих START SLAVE. master_info_repository Командная строка --master-info-repository=FILE|TABLE Системная Имя master_info_repository Контекст переменной Глобальная Динамическая Да Допустимые значения Тип string Значение по умолчанию FILE Допустимые значения FILE TABLE Установка этой переменной определяет, регистрирует ли ведомое устройство основное состояние и информацию о соединении в FILE (master.info) или в TABLE (mysql.slave_master_info). Вы можете изменить значение этой переменной только, когда никакие потоки репликации не выполняются. У установки этой переменной также есть непосредственное воздействие на эффект sync_master_info . Эта переменная должна быть установлена в TABLE прежде, чем сконфигурировать многократные каналы репликации. Если Вы используете многократные каналы репликации, Вы не можете установить эту переменную в FILE. relay_log Командная строка --relay-log=file_name Системная Имя relay_log Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Базовое имя файла системного журнала реле без путей и расширения файла. По умолчанию relay-log. Имена отдельных файлов для канала репликации по умолчанию relay-log.XXXXXX, для дополнительных каналов репликации relay-log-channel.XXXXXX. relay_log_basename Системная Имя relay_log_basename Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Значение по умолчанию datadir + '/' + hostname + '-relay-bin' Имя и полный путь к файлу системного журнала реле. relay_log_index Командная строка --relay-log-index Системная Имя relay_log_index Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Значение по умолчанию *host_name*-relay-bin.index Имя индексного файла журнала реле для канала репликации по умолчанию. Имя по умолчанию host_name-relay-bin.index в каталоге данных, где host_name название ведомого сервера. relay_log_info_file Командная строка --relay-log-info-file=file_name Системная Имя relay_log_info_file Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Значение по умолчанию relay-log.info Название файла, в котором ведомое устройство делает запись информации о журналах реле, когда relay_log_info_repository=FILE. Если relay_log_info_repository=TABLE, это имя файла, которое использовалось бы в случае, если бы репозитарий был изменен на FILE). Имя по умолчанию relay-log.info в каталоге данных. relay_log_info_repository Системная Имя relay_log_info_repository Контекст переменной Глобальная Динамическая Да Допустимые значения Тип string Значение по умолчанию FILE Допустимые значения FILE TABLE Эта переменная определяет, написана ли позиция ведомого устройства в журналах реле в FILE (relay-log.info) или TABLE (mysql.slave_relay_log_info). Вы можете изменить значение этой переменной, только когда никакие потоки репликации не выполняются. У установки этой переменной также есть непосредственное воздействие на sync_relay_log_info . Эта переменная должна быть установлена в TABLE прежде, чем сконфигурировать многократные каналы репликации. Если Вы используете многократные каналы репликации, Вы не можете установить эту переменную к FILE. relay_log_recovery Командная строка --relay-log-recovery Системная Имя relay_log_recovery Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию FALSE Включает автоматическое восстановление журнала реле после запуска сервера. Процесс восстановления создает новый файл системного журнала реле, инициализирует позицию потока SQL к этому новому журналу реле и инициализирует поток ввода/вывода к позиции потока SQL. Чтение журнала реле от ведущего устройства тогда продолжается. В MySQL 5.7 эта глобальная переменная только для чтения, значение может быть изменено, запуская ведомое устройство с опцией --relay-log-recovery, которая должна использоваться после катастрофического отказа на ведомом устройстве репликации, чтобы гарантировать, что поврежденные журналы реле обработаны, и должна использоваться, чтобы гарантировать безопасное от катастрофического отказа ведомое устройство. Значение по умолчанию 0 (отключена). Эта переменная также взаимодействует с relay-log-purge, которая управляет чисткой журналов, когда они больше не необходимы. Включение --relay-log-recovery, когда выключена relay-log-purge это риск чтения журнала реле из файлов, которые не были очищены, приводя к несогласованности данных, поэтому не безопасно от катастрофического отказа. Когда relay_log_recovery включена и ведомое устройство остановилось из-за ошибок, с которыми сталкиваются, работая в виде мультидерева сообщений, Вы можете использовать START SLAVE UNTIL SQL_AFTER_MTS_GAPS , чтобы гарантировать, что все промежутки обработаны прежде, чем переключиться назад на единственное дерево сообщений или выполнить CHANGE MASTER TO. rpl_stop_slave_timeout Командная строка --rpl-stop-slave-timeout=seconds Системная Имя rpl_stop_slave_timeout Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 31536000 Минимум 2 Максимум 31536000 Вы можете управлять отрезком времени (в секундах), который STOP SLAVE ждет перед синхронизацией, устанавливая эту переменную. Это может использоваться, чтобы избежать тупиков между STOP SLAVE и другими ведомыми запросами SQL, используя различные соединения клиента с ведомым устройством. Максимальное и значение по умолчанию rpl_stop_slave_timeout 31536000 секунд (1 год). Минимум составляет 2 секунды. Изменения этой переменной вступают в силу для последующего STOP SLAVE. Эта переменная затрагивает только клиента, который скомандовал STOP SLAVE. Когда тайм-аут достигнут, клиент прекращает ждать ведомых потоков, чтобы остановиться, но ведомые потоки продолжают пытаться остановиться. slave_checkpoint_group Командная строка --slave-checkpoint-group=# Системная Имя slave_checkpoint_group=# Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 512 Минимум 32 Максимум 524280 Block Size 8 Устанавливает максимальное количество транзакций, которые могут быть обработаны мультипоточным ведомым устройством прежде, чем работу контрольной точки вызовут, чтобы обновить ее состояние как показано SHOW SLAVE STATUS. Установка этой переменной не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Установка этой переменной не имеет никакого непосредственного эффекта. статус переменной применяется на всех последующих START SLAVE. Эта переменная работает в комбинации с slave_checkpoint_period таким способом, которым, когда любой предел превышен, контрольная точка выполнена и счетчики, отслеживающие число транзакций и время, начиная с последней контрольной точки сброшены. Минимальное позволенное значение для этой переменной 32, если сервер не был создан, используя -DWITH_DEBUG, тогда минимальное значение 1. Действующее значение всегда кратно числу 8, Вы можете установить это в значение, которое не является таким кратным числом, но сервер округляет это в меньшую сторону к следующему кратному 8 прежде, чем сохранить значение. Исключение: никакое округление не выполнено сервером отладки. Независимо от того, как сервер был создан, значение по умолчанию 512 и максимальное позволенное значение 524280. slave_checkpoint_period Командная строка --slave-checkpoint-period=# Системная Имя slave_checkpoint_period=# Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 300 Минимум 1 Максимум 4G Устанавливает максимальное время (в миллисекундах), которому позволяют пройти прежде, чем работу контрольной точки вызовут, чтобы обновить состояние мультипоточного ведомого устройства как показано SHOW SLAVE STATUS. Установка этой переменной не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. Эта переменная работает в комбинации с slave_checkpoint_group таким способом, которым, когда любой предел превышен, контрольная точка выполнена и счетчики, отслеживающие число транзакций и время, начиная с последней контрольной точки сброшены. Минимальное позволенное значение для этой переменной 1, если сервер не был создан, используя -DWITH_DEBUG, тогда минимальное значение 0. Независимо от того, как был создан сервер, значение по умолчанию 300 и максимальное возможное значение 4294967296 (4GB). slave_compressed_protocol Командная строка --slave_compressed_protocol Системная Имя slave_compressed_protocol Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию OFF Использовать ли сжатие ведомого/основного протокола, если ведущее и ведомое устройства это понимают. Изменения этой переменной вступают в силу на последующих попытках соединения, это включается после START SLAVE, так же как пересоединения, сделанные рабочим потоком ввода/вывода (например, после CHANGE MASTER TO MASTER_RETRY_COUNT). slave_exec_mode Командная строка --slave-exec-mode=mode Системная Имя slave_exec_mode Контекст переменной Глобальная Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию STRICT (ALL) Значение по умолчанию IDEMPOTENT (NDB) Допустимые значения IDEMPOTENT STRICT Средство управления, как ведомый поток решает конфликты и ошибки во время репликации. IDEMPOTENT вызывает подавление ошибок дубликата ключа и отсутствия ключа. Этот режим должен использоваться в мультиосновной репликации, круговой репликации и некоторых других специальных сценариях репликации. STRICT значение по умолчанию, и является подходящим для большинства других случаев. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. slave_load_tmpdir Командная строка --slave-load-tmpdir=dir_name Системная Имя slave_load_tmpdir Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип directory name Значение по умолчанию /tmp Название каталога, где ведомое устройство создает временные файлы для того, чтобы копировать LOAD DATA INFILE . Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. slave_max_allowed_packet Системная Имя slave_max_allowed_packet Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1073741824 Минимум 1024 Максимум 1073741824 Эта переменная устанавливает максимальный пакетный размер для ведомых потоков SQL и ввода/вывода, чтобы большие обновления, используя основанную на строке репликацию не заставили репликацию терпеть неудачу, потому что обновление превысило max_allowed_packet. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. У этой глобальной переменной всегда есть значение, которое является положительным целым числом, кратным 1024, если Вы устанавливаете это в некоторое значение, которое не является кратным 1024, значение округлено в меньшую сторону к следующему самому большому кратному 1024 числу, установка slave_max_allowed_packet в 0 установит 1024. Предупреждение выпущено во всех таких случаях. Значение по умолчанию и максимальное значение 1073741824 (1 GB), минимум 1024. slave_max_allowed_packet может также быть установлена при запуске, используя опцию --slave-max-allowed-packet. slave_net_timeout Командная строка --slave-net-timeout=# Системная Имя slave_net_timeout Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 3600 Минимум 1 Допустимые значения Тип integer Значение по умолчанию 60 Минимум 1 Число секунд, чтобы ждать большего количества данных от основного/ведомого соединения прежде, чем прервать чтение. Установка этой переменной не имеет никакого непосредственного эффекта. Статус переменной применяется на всех последующих START SLAVE. slave_parallel_type= type Командная строка --slave-parallel-type=type Допустимые значения Тип enumeration Значение по умолчанию DATABASE Допустимые значения DATABASE LOGICAL_CLOCK Используя мультипоточное ведомое устройство ( slave_parallel_workers больше 0), эта переменная определяет политику, решающую, которые транзакции позволить выполнить параллельно на ведомом устройстве. slave_parallel_workers Командная строка --slave-parallel-workers=# Системная Имя slave_parallel_workers Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 1024 Определяет число потоков применения ведомого устройства для того, чтобы выполнить транзакции репликации параллельно. Установка этой переменной к числу больше 0 создает мультипоточное ведомое устройство с этим числом потоков. Когда установлено в 0 (значение по умолчанию) параллельное выполнение отключено, и ведомое устройство использует единственный поток. Установка slave_parallel_workers не имеет никакого непосредственного эффекта. Статус переменной применяется на всех последующих START SLAVE. Повторение транзакций поддержано, когда мультипоточная обработка включена на ведомом устройстве. Мультипоточное ведомое устройство обеспечивает параллельное выполнение при использовании потока координатора и потоков применения, сконфигурированных этой переменной. Способ, которым транзакции распределены среди потоков, сконфигурирован slave_parallel_type . Транзакции, которые ведомое устройство применяет параллельно, могут передать не в том порядке, если slave_preserve_commit_order=1. Поэтому проверка последней выполненной транзакции не гарантирует, что все предыдущие транзакции от ведущего устройства были выполнены на ведомом устройстве. У этого есть значения для журналирования и восстановления, используя мультипоточное ведомое устройство. Например, на мультипоточном ведомом устройстве START SLAVE UNTIL поддерживает использование только SQL_AFTER_MTS_GAPS. slave_pending_jobs_size_max Системная Имя slave_pending_jobs_size_max Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 16M Минимум 1024 Максимум 18EB Block Size 1024 Для мультипоточных ведомых устройств эта переменная устанавливает максимальный объем памяти (в байтах) доступный очередям, хранящим еще не примененные транзакции. Установка этой переменной не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Установка этой переменной не имеет никакого непосредственного эффекта. Статус переменной применяется на всех последующих START SLAVE. Минимальное возможное значение для этой переменной 1024, значение по умолчанию составляет 16 МБ. Максимальное возможное значение 18446744073709551615 (16 exabytes). Значения, которые не являются кратными 1024 округлены в меньшую сторону к следующему самому большому кратному 1024 числу до того, как сохранены. Значение этой переменной не должно быть меньше чем значение ведущего устройства для max_allowed_packet, иначе очередь может стать полной, в то время как там остаются события, прибывающие от ведущего устройства, чтобы быть обработанными. slave_preserve_commit_order Командная строка --slave-preserve-commit-order=value Системная Имя slave_preserve_commit_order Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию 0 Допустимые значения 0 1 Для мультипоточных ведомых устройств включение этой переменной гарантирует, что транзакции воплощены на ведомом устройстве в том же самом порядке, как они появляются в журнале реле ведомого устройства. Установка этой переменной не имеет никакого эффекта на ведомые устройства, для которых не включена мультипоточная обработка. Все потоки репликации (для всех каналов репликации, если Вы используете многократные каналы репликации) должны быть остановлены прежде, чем менять это значение. --log-bin и --log-slave-updates должны быть включены на ведомом устройстве. Кроме того, --slave-parallel-type должна быть установлена в LOGICAL_CLOCK. Как только мультипоточное ведомое устройство было запущено, транзакции могут начать выполняться параллельно. С включенной slave_preserve_commit_order поток выполнения ждет, пока все предыдущие транзакции не переданы перед совершением. В то время как ведомый поток ждет других, чтобы передать их транзакции, он сообщает о своем состоянии как Waiting for preceding transaction to commit. Включение этого режима на мультипоточном ведомом устройстве гарантирует, что никогда не будет статуса, в котором не было ведущее устройство. Это делает его хорошо подходящим для использования репликации для масштабирования чтения. См. раздел 19.3.5. Используя мультипоточное ведомое устройство, если не включена slave_preserve_commit_order есть шанс промежутков в последовательности транзакций, которые были выполнены от журнала реле ведомого устройства. Когда эта опция включена, нет этого шанса промежутков, но Exec_master_log_pos может быть позади позиции, до которой был выполнен. См. раздел 19.4.1.34. slave_rows_search_algorithms Системная Имя slave_rows_search_algorithms=list Контекст переменной Глобальная Динамическая Да Допустимые значения Тип set Значение по умолчанию TABLE_SCAN,INDEX_SCAN Допустимые значения TABLE_SCAN,INDEX_SCAN INDEX_SCAN,HASH_SCAN TABLE_SCAN,HASH_SCAN TABLE_SCAN,INDEX_SCAN,HASH_SCAN (аналог INDEX_SCAN,HASH_SCAN) Готовя пакеты строк для основанного на строке журналирования и репликации, эта переменная управляет, как строки разыскиваются, то есть, используется ли хеширование для поисков, используется ли основной, уникальный ключ или некоторый другой ключ, или не используются ключи вообще. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. Эта переменная берет список разделенных запятой значений по крайней мере 2 значений из списка INDEX_SCAN, TABLE_SCAN, HASH_SCAN. Значение, ожидаемое как строка, должно быть заключено в кавычки.Кроме того, значение не должно содержать пробелы. Возможные комбинации (списки) и их эффекты показаны в следующей таблице: Значение опции и используемые индексы INDEX_SCAN,HASH_SCAN или INDEX_SCAN,TABLE_SCAN,HASH_SCAN INDEX_SCAN,TABLE_SCAN TABLE_SCAN,HASH_SCAN Первичный или уникальный ключ . Индексный просмотр. Индексный просмотр. Индексный хэш. (Другой) ключ Индексный хэш. Индексный просмотр. Индексный хэш. Индекс не используется. Табличный хэш. Табличный просмотр. Табличный хэш. Порядок, в котором алгоритмы определены в списке, не имеет никакого значения в порядке, в котором они выведены на экран SELECT или SHOW VARIABLES, как показано здесь: mysql> SET GLOBAL slave_rows_search_algorithms = "INDEX_SCAN,TABLE_SCAN"; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE '%algorithms%'; +------------------------------+-----------------------+ | Variable_name | Value | +------------------------------+-----------------------+ | slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN | +------------------------------+-----------------------+ 1 row in set (0.00 sec) mysql> SET GLOBAL slave_rows_search_algorithms = "TABLE_SCAN,INDEX_SCAN"; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE '%algorithms%'; +------------------------------+-----------------------+ | Variable_name | Value | +------------------------------+-----------------------+ | slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN | +------------------------------+-----------------------+ 1 row in set (0.00 sec) Значение по умолчанию TABLE_SCAN,INDEX_SCAN означает, что все поиски, которые могут использовать индексы, действительно используют их, и поиски без индекса используют сканирование таблицы. Определение INDEX_SCAN,TABLE_SCAN,HASH_SCAN имеет тот же самый эффект как определение INDEX_SCAN,HASH_SCAN. Чтобы использовать хеширование для любых поисков, которые не используют основной или уникальный ключ, устанавливайте эту переменную в INDEX_SCAN,HASH_SCAN. Чтобы вызвать хеширование для всех поисков, установите это в TABLE_SCAN,HASH_SCAN. slave_skip_errors Командная строка --slave-skip-errors=name Системная Имя slave_skip_errors Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [list of error codes] all ddl_exist_errors Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [список кодов ошибок] all ddl_exist_errors Допустимые значения Тип string Значение по умолчанию OFF Допустимые значения OFF [список кодов ошибок] all ddl_exist_errors Обычно репликация останавливается, когда ошибка происходит на ведомом устройстве, которое дает Вам возможность решить несогласованность в данных вручную. Эта переменная заставляет ведомый поток SQL продолжать репликацию, когда запрос возвращает любую из ошибок, перечисленных в переменном значении. Установка этой переменной немедленно вступает в силу, даже для рабочих потоков репликации. slave_sql_verify_checksum Системная Имя slave_sql_verify_checksum Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию 1 Допустимые значения 0 1 Заставьте ведомый поток SQL проверять данные, используя контрольные суммы, считанные из журнала реле. В случае несоответствия ведомое устройство останавливается с ошибкой. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. Ведомый поток ввода/вывода всегда читает контрольные суммы, если возможно, принимая события из сети. slave_transaction_retries Командная строка --slave_transaction_retries=# Системная Имя slave_transaction_retries Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 10 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 10 Минимум 0 Максимум 18446744073709551615 Если поток SQL ведомого устройства не в состоянии выполнить транзакцию из-за тупика InnoDB или потому что превышено время выполнения транзакции InnoDB innodb_lock_wait_timeout, это автоматически повторяет slave_transaction_retries раз прежде, чем остановиться с ошибкой. Значение по умолчанию 10. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. Повторение транзакций поддержано, когда мультипоточная обработка включена на ведомом устройстве. В предыдущих версиях slave_transaction_retries была обработана как 0, когда использовались мультипоточныые ведомые устройства. slave_type_conversions Командная строка --slave_type_conversions=set Системная Имя slave_type_conversions Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип set Значение по умолчанию Допустимые значения ALL_LOSSY ALL_NON_LOSSY ALL_SIGNED ALL_UNSIGNED Управляет конверсионным режимом типа на ведомом устройстве, используя основанную на строке репликацию. Его значение разграниченный запятой набор из ноля или большего количества элементов списка: ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED. Установите эту переменную в пустую строку, чтобы отвергнуть преобразования типа между ведущим и ведомым устройствами. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. sql_slave_skip_counter Системная Имя sql_slave_skip_counter Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Число событий от ведущего устройства, которое должен пропустить ведомый сервер. Установка опции не имеет никакого непосредственного эффекта. Переменная относится к следующему вызову START SLAVE, следующий START SLAVE также изменяет значение назад на 0. Когда эта переменная установлена в ненулевое значение и есть многократные сконфигурированные каналы репликации, START SLAVE может использоваться только с FOR CHANNEL channel . Эта опция является несовместимой с GTID-репликацией и не должна быть установлена в ненулевое значение, когда --gtid-mode=ON . Если Вы должны пропустить транзакции, используя GTID, надо использовать gtid_executed от ведущего устройства вместо этого. Если пропуск числа событий, определенных, устанавливая эту переменную, заставил бы ведомое устройство начинать в середине группы событий, ведомое устройство продолжает пропускать транзакции, пока не находит начало следующей группы событий и начинается с того пункта. Для получения дополнительной информации см. раздел 14.4.2.5. sync_master_info Командная строка --sync-master-info=# Системная Имя sync_master_info Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 18446744073709551615 Эффекты этой переменной на ведомом устройстве репликации зависят того, как установлена master_info_repository: FILE или TABLE. master_info_repository = FILE. Если sync_master_info больше 0, ведомое устройство синхронизирует master.info с диском через fdatasync() каждые sync_master_info событий. Если это 0, MySQL не выполняет синхронизации master.info с диском, вместо этого, сервер полагается на операционную систему, чтобы периодически сбросить содержание как с любым другим файлом. master_info_repository = TABLE. Если sync_master_info больше 0, ведомое устройство обновляет свою основную таблицу репозитария информации после каждых sync_master_info событий. Если это 0, таблица никогда не обновляется. Значение по умолчанию для sync_master_info 10000. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. sync_relay_log Командная строка --sync-relay-log=# Системная Имя sync_relay_log Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 18446744073709551615 Если значение этой переменной больше 0, сервер MySQL синхронизирует свой журнал реле с диском (с использованием fdatasync()) каждые sync_relay_log событий. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. Установка sync_relay_log = 0 значит, что никакая синхронизация не будет сделана, в этом случае сервер полагается на операционную систему, чтобы время от времени сбросить содержание журнала реле, что касается любого другого файла. Значение 1 является самым безопасным выбором, потому что в случае катастрофического отказа Вы теряете самое большее одно событие журнала реле. Однако, это также самый медленный выбор (если у диска нет поддержанного батареей кэша, который делает синхронизацию очень быстро). sync_relay_log_info Командная строка --sync-relay-log-info=# Системная Имя sync_relay_log_info Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 10000 Минимум 0 Максимум 18446744073709551615 Эффекты этой переменной на ведомом устройстве зависят от серверной relay_log_info_repository, если это TABLE, дополнительно от того, является ли механизм хранения, используемый таблицей информации журнала реле, транзакционным. Эффекты этих факторов на поведение сервера для sync_relay_log_info = 0 или больше показываются в следующей таблице: sync_relay_log_info relay_log_info_repository FILE TABLE Транзакционный Нетранзакционный N > 0 Ведомое устройство синхронизирует relay-log.info на диск (через fdatasync()) каждые N транзакций. Таблица обновлена после каждой транзакции. N игнорируется. Таблица обновлена после каждого N-го события. 0 Сервер MySQL не выполняет синхронизацию relay-log.info с диском, полагаясь на ОС. Таблица никогда не обновляется. Значение по умолчанию для sync_relay_log_info 10000. Установка этой переменной немедленно вступает в силу для всех каналов репликации, включая рабочие каналы. 19.1.6.4. Опции и переменные двоичного журналирования Вы можете использовать опции и системные переменные mysqld, которые описаны в этом разделе, чтобы затронуть работу двоичного журнала так же как управлять, какие запросы написаны двоичному журналу. Для дополнительной информации о двоичном журнале см. раздел 6.4.4. Опции запуска, используемые с двоичным журналированием Следующий список описывает опции запуска для включения и конфигурирования двоичного журнала. Системные переменные, используемые с двоичным журналированием, обсуждены позже в этом разделе. --binlog-row-event-max-size=N Командная строка --binlog-row-event-max-size=# Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 8192 Минимум 256 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 8192 Минимум 256 Максимум 18446744073709551615 Определите максимальный размер основанного на строке события двоичного журнала в байтах. Строки сгруппированы в события, меньшие чем этот размер, если возможно. Значение должно быть кратным числу 256. Значение по умолчанию 8192. См. раздел 19.2.1. --log-bin[=base_name] Командная строка --log-bin Системная Имя log_bin Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Включить двоичное журналирование. Сервер регистрирует все запросы, об изменении данных в двоичном журнале, который используется для резервного копирования и репликации. См. раздел 6.4.4 . Значение опции, если дано, является базовым именем для последовательности журнала. Сервер создает двоичные файлы системного журнала в последовательности, добавляя числовой суффикс к базовому имени. Рекомендуется, чтобы Вы определили базовое имя (см. раздел B.5.7). Иначе MySQL использует как базовое имя host_name-bin. Когда сервер читает запись из индексного файла, он проверяет, содержит ли она относительный путь, и если это так, относительная часть пути замена абсолютным путем, используя опцию --log-bin. Абсолютный путь остается неизменным, в таком случае индексирование должно быть отредактировано вручную, чтобы позволить новому пути или путям использоваться. В более старых версиях MySQL ручное вмешательство требовалось, перемещая двоичной журнал или файлы системного журнала реле (Bug #11745230, Bug #12133). Установка этой опции вызывает установку log_bin в ON (или 1), а не к базовому имени. Имя файла системного журнала (с путем) доступно как log_bin_basename . Если Вы определяете эту опцию, также не определяя --server-id, сервер не запустится (Bug #11763963, Bug #56739). --log-bin-index[=file_name] Командная строка --log-bin-index=file_name Допустимые значения Тип file name Индексный файл для файла системного журнала. См. раздел 6.4.4. Если Вы опускаете имя файла, и если Вы не определяли его с --log-bin, MySQL использует host_name-bin.index. --log-bin-trust-function-creators[={0|1}] Командная строка --log-bin-trust-function-creators Системная Имя log_bin_trust_function_creators Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию FALSE Эта опция устанавливает соответствующую системную переменную log_bin_trust_function_creators. Если никакой параметр не дан, опция устанавливает переменную в 1. log_bin_trust_function_creators управляет, как MySQL проводит в жизнь ограничения на создание триггеров и сохраненных функций. См. раздел 21.7. --log-bin-use-v1-row-events[={0|1}] Командная строка --log-bin-use-v1-row-events[={0|1}] Системная Имя log_bin_use_v1_row_events Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию 0 MySQL 8.0 применяет Version 2 событий строки, которые не могут быть считаны выпусками MySQL Server до MySQL 5.6.6. Установка этой опции к 1 предписывает mysqld писать двоичной журнал, используя события журналирования Version 1, которая является единственной версией двоичных событий журнала, используемых в предыдущих выпусках, и таким образом производит двоичные журналы, которые могут быть считаны более старыми ведомыми устройствами. Установка --log-bin-use-v1-row-events = 0 (значение по умолчанию) заставляет mysqld использовать события журнала Version 2. Значение, используемое для этой опции, может быть получено из переменной только для чтения log_bin_use_v1_row_events. Опции выбора запроса. Опции в следующем списке определяют, которые запросы написаны двоичному журналу, и таким образом посланы главным сервером репликации в его ведомые устройства. Есть также опции для ведомых серверов, которые управляют, какие запросы, полученные от ведущего устройства, должны быть выполнены или проигнорированы. Для деталей см. раздел 19.1.6.3. --binlog-do-db=db_name Командная строка --binlog-do-db=name Допустимые значения Тип string Эта опция затрагивает журналирование аналогично --replicate-do-db. Эффекты этой опции зависят от того, используется ли основанный на запросе или основанный на строке формат журналирования таким же образом, как --replicate-do-db . Вы должны иметь в виду, что формат, используемый, чтобы зарегистрировать данный запрос, возможно, не тот же самый, как обозначено значением binlog_format . Например, запросы DDL CREATE TABLE и ALTER TABLE всегда регистрируются как запросы без отношения к формату журналирования. Основанное на запросе журналирование. Только те запросы написаны двоичному журналу, где база данных по умолчанию (то есть, выбранная USE) db_name. Чтобы определить больше, чем одну базу данных, используйте эту опцию многократно, однажды для каждой базы данных, однако, выполнение этого не регистрирует запросы между базами данных, например, UPDATE some_db.some_table SET foo='bar' в то время, как другая база данных выбрана (или никакая база данных не выбрана вообще). Чтобы определить многократные базы данных, Вы должны использовать многократные копии этой опции. Поскольку имена базы данных могут содержать запятые, список будет обработан как название единственной базы данных, если Вы будете поставлять список разделенных запятой значений. Пример того, что не работает, как Вы могли бы ожидать, используя основанное на запросе журналирование: если сервер запущен с --binlog-do-db=sales и Вы делаете следующие запросы, UPDATE не будет зарегистрирован: USE prices; UPDATE sales.january SET amount=amount+1000; Главная причина для этой проверки, что значение база данных по умолчанию то, что трудно из одного только запроса знать, должно ли это копироваться (например, если Вы используете многотабличный DELETE или UPDATE, которые действуют через многократные базы данных). Также быстрее проверить только базу данных по умолчанию, а не все базы данных, если в этом нет никакой потребности. Другой случай, который, возможно, не самоочевиден, происходит, когда данная база данных копируется даже при том, что это не было определено, устанавливая опцию. Если сервер запущен с --binlog-do-db=sales, следующий UPDATE зарегистрирован даже при том, что prices не была включена, устанавливая --binlog-do-db: USE sales; UPDATE prices.discounts SET percentage = percentage + 10; Так как sales база данных по умолчанию, когда выполнен UPDATE, UPDATE зарегистрирован. Основанное на строке журналирование. Журналирование ограничено базой данных db_name. Только изменения таблиц, принадлежащих db_name зарегистрированы, база данных по умолчанию не имеет никакого эффекта на это. Предположите, что сервер запущен с --binlog-do-db=sales и основанное на строке журналирование включено, затем следующие запросы выполнены: USE prices; UPDATE sales.february SET amount=amount+100; Изменения таблицы february в базе данных sales зарегистрированы в соответствии с UPDATE , это происходит независимо от USE . Однако, используя основанный на строке формат журналирования и --binlog-do-db=sales , изменения, произведенные следующим UPDATE не зарегистрированы: USE prices; UPDATE prices.march SET amount=amount-25; Даже если USE prices было изменено на USE sales, UPDATE эффекты запроса все еще не были бы написаны в двоичный журнал. Другое важное различие в --binlog-do-db обработка для основанного на запросе журналирования в противоположность основанному на строке журналированию происходит относительно запросов, которые относятся к многим базам данных. Предположите, что сервер запущен с --binlog-do-db=db1 и следующие запросы выполнены: USE db1; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20; Если Вы используете основанное на запросе журналирование, обновления обеих таблиц написаны в двоичный журнал. Однако, используя основанный на строке формат, только изменения table1 зарегистрированы, table2 находится в другой базе данных, таким образом, это не изменено UPDATE. Теперь предположите, что вместо USE db1 использован USE db4: USE db4; UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20; В этом случае UPDATE не написан в двоичный журнал, используя основанное на запросе журналирование. Однако, используя основанное на строке журналирование, изменение table1 зарегистрировано, но не table2, другими словами, только изменения таблиц в базе данных, названной --binlog-do-db зарегистрированы, и выбор базы данных значения по умолчанию не имеет никакого эффекта на это поведение. --binlog-ignore-db=db_name Командная строка --binlog-ignore-db=name Допустимые значения Тип string Эта опция затрагивает журналирование аналогично --replicate-ignore-db. Эффекты этой опции зависят от того, используется ли основанный на запросе или основанный на строке формат журналирования, таким же образом, как эффекты --replicate-ignore-db. Вы должны иметь в виду, что формат, используемый, чтобы зарегистрировать данный запрос, возможно, не тот же самый как обозначен значением binlog_format. Например, запросы DDL CREATE TABLE и ALTER TABLE всегда регистрируются как запросы, без отношения к формату журналирования. Основанное на запросе журналирование. Говорит серверу не регистрировать любой запрос, где база данных по умолчанию (выбрана через USE) db_name. Когда нет никакой базы данных по умолчанию, опция --binlog-ignore-db не применена и такие запросы всегда регистрируются (Bug #11829838, Bug #60188). Основанный на строке формат. Говорит серверу не регистрировать обновления любых таблиц в базе данных db_name. Текущая база данных не имеет никакого эффекта. Используя основанное на запросе журналирование, следующий пример не работает, как Вы могли бы ожидать. Предположите, что сервер запущен с --binlog-ignore-db=sales и Вы делаете следующие запросы: USE prices; UPDATE sales.january SET amount=amount+1000; UPDATE зарегистрирован, потому что --binlog-ignore-db применяется только к базе данных по умолчанию (определенной USE). Поскольку база данных sales была определена явно в запросе, запрос не фильтровался. Однако, используя основанное на строке журналирование, UPDATE не написан в двоичный журнал, что означает что никакие изменения sales.january не зарегистрированы, в этом случае --binlog-ignore-db=sales не пишет все изменения, произведенные в таблицах в копии ведущего устройства базы данных sales. Чтобы определить больше, чем одну базу данных, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой базы данных. Поскольку имена базы данных могут содержать запятые, список будет обработан как название единственной базы данных, если Вы будете поставлять список разделенных запятой значений. Вы не должны использовать эту опцию, если Вы используете обновления между базами данных, и Вы не хотите, чтобы эти обновления были зарегистрированы. Опции контрольной суммы. MySQL 8.0 понимает чтение и запись контрольных сумм журнала. Они включены, используя эти две опции: --binlog-checksum={NONE|CRC32} Командная строка --binlog-checksum=type Допустимые значения Тип string Значение по умолчанию CRC32 Допустимые значения NONE CRC32 Включение этой опции заставляет ведущее устройство писать контрольные суммы для событий, написанных двоичному журналу. Установите в NONE, чтобы выключить или в название алгоритма, который будет использоваться для того, чтобы произвести контрольные суммы, в настоящее время поддержаны только контрольные суммы CRC32, CRC32 значение по умолчанию. --master-verify-checksum={0|1} Командная строка --master-verify-checksum=name Допустимые значения Тип boolean Значение по умолчанию OFF Включение этой опции заставляет ведущее устройство проверять события от двоичного журнала, используя контрольные суммы, и останавливаться с ошибкой в случае несоответствия. Отключена по умолчанию. Чтобы управлять чтением контрольных сумм ведомым устройством от реле, используйте --slave-sql-verify-checksum. Тестирование и отладка опций. Следующие опции журнала используются в тестировании репликации и отладке. Они не предназначены для использования в нормальном функционировании. --max-binlog-dump-events=N Командная строка --max-binlog-dump-events=# Допустимые значения Тип integer Значение по умолчанию 0 Эта опция используется внутренне испытательным набором MySQL для тестирования репликации и отладки. --sporadic-binlog-dump-fail Командная строка --sporadic-binlog-dump-fail Допустимые значения Тип boolean Значение по умолчанию FALSE Эта опция используется внутренне испытательным набором MySQL для тестирования репликации и отладки. --binlog-rows-query-log-events Командная строка --binlog-rows-query-log-events Допустимые значения Тип boolean Значение по умолчанию FALSE Эта опция включает binlog_rows_query_log_events. Системные переменные, используемые с двоичным журналированием Следующий список описывает системные переменные для того, чтобы управлять двоичным журналированием. Они могут быть установлены при запуске сервера, некоторые из них могут быть изменены во время выполнения при использовании SET. Параметры сервера, используемые, чтобы управлять двоичным журналированием, перечислены ранее в этом разделе. Для информации о sql_log_bin и sql_log_off см. раздел 6.1.5. binlog_cache_size Командная строка --binlog_cache_size=# Системная Имя binlog_cache_size Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 32768 Минимум 4096 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 32768 Минимум 4096 Максимум 18446744073709551615 Размер кэша, чтобы содержать изменения двоичного журнала во время транзакции. Кэш журнала выделен для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы хранения и если у сервера есть двоичный включенный журнал ( --log-bin). Если Вы часто используете большие транзакции, Вы можете увеличить этот размер кэша, чтобы получить лучшую работу. Binlog_cache_use и Binlog_cache_disk_use могут быть полезными для настройки размера этой переменной. См. раздел 6.4.4. binlog_cache_size устанавливает размер только для операционного кэша, размером кэша запроса управляет binlog_stmt_cache_size. binlog_checksum Системная Имя binlog_checksum Контекст переменной Глобальная Динамическая Да Допустимые значения Тип string Значение по умолчанию CRC32 Допустимые значения NONE CRC32 Когда включена, эта переменная заставляет ведущее устройство писать контрольную сумму для каждого события в двоичном журнале. binlog_checksum допускает значения NONE (отключена) и CRC32. Значение по умолчанию CRC32. Когда binlog_checksum выключена (NONE), сервер проверяет, что пишет только полные события в двоичный журнал при записи и проверяя длину событий (а не контрольную сумму) для каждого события. Изменение значения этой переменной заставляет двоичной журнал ротировать, контрольные суммы всегда пишутся всему файлу системного журнала, и никогда только части. Установка этой переменной на ведущем устройстве к значению, не признанному ведомым устройством, заставляет ведомое устройство устанавливать свое собственное значение binlog_checksum в NONE и остановить репликацию с ошибкой (Bug #13553750, Bug #61096). Если обратная совместимость с более старыми ведомыми устройствами это проблема, Вы можете хотеть установить значение явно в NONE. binlog_direct_non_transactional_updates Командная строка --binlog_direct_non_transactional_updates[=value] Системная Имя binlog_direct_non_transactional_updates Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип boolean Значение по умолчанию OFF Из-за проблем параллелизма, ведомое устройство может стать непоследовательным, когда транзакция содержит обновления транзакционных и нетранзакционных таблиц. MySQL пытается сохранить причинную связь среди этих запросов при записи нетранзакционных запросов операционному кэшу, который сбрасывается при передаче. Однако, проблемы возникают, когда модификации, сделанные к нетранзакционным таблицам от имени транзакции, немедленно становятся видимыми другим соединениям, потому что эти изменения не могут быть немедленно написаны в двоичной журнал. binlog_direct_non_transactional_updates предлагает одно возможное обходное решение этой проблемы. По умолчанию эта переменная отключена. Включение binlog_direct_non_transactional_updates делает так, что обновления нетранзакционных таблиц будут написаны непосредственно двоичному журналу, а не операционному кэшу. binlog_direct_non_transactional_updates работает только для запросов, которые копируются, используя основанный на запросе двоичной формат журналирования, то есть, это работает только когда значение binlog_format STATEMENT или MIXED и данный запрос копируется, используя основанный на запросе формат. Эта переменная не имеет никакого эффекта, когда двоичной формат журнала ROW или binlog_format MIXED и данный запрос копируется, используя основанный на строке формат. Прежде, чем включить эту переменную, Вы должны удостовериться, что нет никаких зависимостей между транзакционными и нетранзакционными таблицами, примером такой зависимости был бы запрос INSERT INTO myisam_table SELECT * FROM innodb_table. Иначе такие запросы, вероятно, заставят ведомое устройство отклоняться от ведущего устройства. В MySQL 8.0 эта переменная не имеет никакого эффекта, когда двоичный формат журнала ROW или MIXED (Bug #51291). binlog_error_action Командная строка --binlog_error_action[=value] Системная Имя binlog_error_action Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию IGNORE_ERROR Допустимые значения IGNORE_ERROR ABORT_SERVER Допустимые значения Тип enumeration Значение по умолчанию ABORT_SERVER Допустимые значения IGNORE_ERROR ABORT_SERVER Средство управления, что происходит, когда сервер сталкивается с ошибкой, такой как неспособность написать, сбросить или синхронизировать двоичный журнал, что может заставить журнал ведущего устройства становиться непоследовательным и ведомые устройства репликации потерять синхронизацию. Значение по умолчанию ABORT_SERVER заставляет сервер остановить журналирование и закрыться всякий раз, когда это сталкивается с такой ошибкой с двоичным журналом. На перезапуске сервера переданы все ранее готовые и зарегистрированные транзакции, в то время как любые транзакции, которые были подготовлены, но не зарегистрированы из-за ошибки прерваны. Когда binlog_error_action = IGNORE_ERROR, если сервер сталкивается с такой ошибкой, это продолжает транзакцию, регистрирует ошибку, останавливает журналирование и продолжает выполнять обновления. ЧСтобы возобновить двоичное журналирование log_bin должен быть включен снова. Это предоставляет обратную совместимость с более старыми версиями MySQL. В предыдущих выпусках эту переменную называли binlogging_impossible_mode. binlog_format Командная строка --binlog-format=format Системная Имя binlog_format Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию ROW Допустимые значения ROW STATEMENT MIXED Эта переменная устанавливает двоичный формат журналирования и может быть любым значением из STATEMENT, ROW или MIXED. См. раздел 19.2.1. binlog_format установлена --binlog-format при запуске или binlog_format во время выполнения. В то время как Вы можете изменить формат журналирования во время выполнения, не рекомендуется, чтобы Вы изменили это в то время, как репликация работает. Значение по умолчанию ROW. Вы должны иметь привилегию SUPER , чтобы установить глобальное или сеансовое значение binlog_format. Управление правилами, когда изменения этой переменной вступают в силу и сколько времени эффект длится, является тем же самым, что касается других системных переменных сервера MySQL. Для получения дополнительной информации см. раздел 14.7.4.1. Когда указано MIXED, основанная на запросе репликация используется, за исключением случаев, где только основанная на строке репликация приведет к надлежащим результатам. Например, это происходит, когда запросы содержат определяемые пользователем функции (UDF) или UUID(). Исключение к этому правилу: MIXED всегда использует основанную на запросе репликацию для сохраненных функций и триггеров. Есть исключения, когда Вы не можете переключить формат репликации во время выполнения: Изнутри сохраненной функции или триггера. Если сеанс в настоящее время находится в основанном на строке режиме репликации и имеет открытые временные таблицы. Изнутри транзакции. Попытка переключить формат в тех случаях приводит к ошибке. Двоичный формат журнала затрагивает поведение следующих параметров сервера: --replicate-do-db --replicate-ignore-db --binlog-do-db --binlog-ignore-db Эти эффекты обсуждены подробно в описаниях отдельных опций. binlog_group_commit_sync_delay Командная строка --binlog-group-commit-sync-delay=# Системная Имя binlog_group_commit_sync_delay Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 1000000 Средство управления, сколько микросекунд двоичный журнал ждет прежде, чем синхронизировать файл системного журнала с диском. По умолчанию binlog-group-commit-sync-delay = 0, означая, что нет никакой задержки. Установка binlog-group-commit-sync-delay к микросекундной задержке позволяет большему количеству транзакций быть синхронизированным вместе с диском сразу, уменьшая полное время, чтобы передать группу транзакций, потому что более многочисленные группы требуют меньшего количества единиц времени на группу. С правильной настройкой это может увеличить ведомую работу, не ставя под угрозу пропускную способность ведущего устройства. binlog_group_commit_sync_no_delay_count Командная строка --binlog-group-commit-sync-no-delay-count=# Системная Имя binlog_group_commit_sync_no_delay_count Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 1000000 Максимальное количество транзакций, чтобы ждать прежде, чем прервать текущую задержку как определено binlog-group-commit-sync-delay. Если binlog-group-commit-sync-delay = 0, эта опция не имеет никакого эффекта. binlogging_impossible_mode Устаревшая 5.7.6 Командная строка --binlogging_impossible_mode[=value] Системная Имя binlogging_impossible_mode Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию IGNORE_ERROR Допустимые значения IGNORE_ERROR ABORT_SERVER Эта опция устарела и будет удалена в будущем выпуске MySQL. Используйте binlog_error_action , чтобы управлять, что происходит, когда сервер не может написать двоичный журнал. binlog_max_flush_queue_time Устаревшая 5.7.9 Системная Имя binlog_max_flush_queue_time Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 0 Минимум 0 Максимум 100000 Прежде, это управляло временем в микросекундах, чтобы продолжить читать транзакции из очереди потока прежде, чем продолжение группы передано. В MySQL 8.0 эта переменная больше не имеет эффекта. binlog_max_flush_queue_time устарела в MySQL 5.7.9, и отмечена для возможного удаления в будущем выпуске MySQL. binlog_order_commits Системная Имя binlog_order_commits Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию ON Когда эта переменная включена на ведущем устройстве (значение по умолчанию), транзакции воплощены в том же самом порядке, как они написаны двоичному журналу. Если отключено, транзакции могут быть переданы параллельно. В некоторых случаях отключение этой переменной могло бы произвести улучшение производительности. binlog_row_image Командная строка --binlog-row-image=image_type Системная Имя binlog_row_image=image_type Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию full Допустимые значения full (Зарегистрировать все столбцы.) minimal (Зарегистрировать только измененные столбцы и столбцы, нужные чтобы идентифицировать строки.) noblob (Зарегистрировать все столбцыLog, за исключением ненужных столбцов BLOB и TEXT.) В основанной на строке репликации каждый случай изменения строки содержит два образа: до, столбцы которого являются соответствующими при поиске строки, которая будет обновлена, и после, содержащий изменения. Обычно MySQL регистрирует все строки (то есть, все столбцы) для обоих образов. Однако, не строго необходимо включать каждый столбец в оба образа и мы можем часто сэкономить диск, память и сеть, регистрируя только те столбцы, которые фактически требуются. Удаляя строку, только исходный вид записи зарегистрирован, так как нет никаких измененных значений после удаления. Вставляя строку, образ записан только после, так как нет никакой существующей строки, которая будет соответствующей. Только обновление строки требует образов прежде и после, и оба написаны в двоичный журнал. Для исходного вида записи необходимо только, чтобы минимальный набор столбцов, требуемых, чтобы уникально идентифицировать строки, был зарегистрирован. Если у таблицы, содержащей строку, есть первичный ключ, то только столбец первичного ключа (или столбцы) написаны в двоичный журнал. Иначе, если у таблицы есть уникальный ключ, у которого все столбцы NOT NULL, только столбцы в уникальнои ключе зарегистрированы. Если у таблицы нет ни первичного, ни уникального ключа без столбцов NULL, все столбцы должны использоваться в исходном виде записи и зарегистрированы. В образе после необходимо зарегистрировать только столбцы, которые фактически изменились. Вы можете заставить сервер регистрировать все или минимальные строки, используя binlog_row_image. Эта переменная фактически берет одно из трех возможных значений, как показано в следующем списке: full: Зарегистрировать все столбцы в образах до и после. minimal: Зарегистрировать только те столбцы в исходном виде записи, которые обязаны идентифицировать строку, которая будет изменена, регистрировать только те столбцы в образе после, которые фактически изменены. noblob: Аналог full, кроме BLOB и TEXT, которые не обязаны идентифицировать строки или не изменились. Значение по умолчанию full. Применяя minimal или noblob удаления и обновления будут работать правильно с данной таблицей, если и только если следующие условия истина для источника и для целевых таблиц: Все столбцы должны присутствовать и в том же самом порядке, каждый столбец должен использовать тот же самый тип данных в качестве своего коллеги в другой таблице. У таблиц должны быть идентичные определения первичного ключа. Другими словами, таблицы должны быть идентичными с возможным исключением индексов, которые не являются частью первичных ключей таблиц. Если эти условия не соблюдаются, возможно, что значения столбцов первичного ключа в целевой таблице могут оказаться недостаточными, чтобы обеспечить уникальное соответствие для удаления или обновления. В этом случае никакое предупреждение или ошибка не выпущены, ведущее и ведомое устройства тихо отклоняются, таким образом ломая последовательность. Установка этой переменной не имеет никакого эффекта, когда двоичной формат журналирования STATEMENT. Когда binlog_format = MIXED, binlog_row_image применена к изменениям, которые зарегистрированы, используя основанный на строке формат, но эта установка не имеет никакого эффекта на изменения, зарегистрированные как запросы. Установка binlog_row_image на глобальном уровне или на уровне сеанса не вызывает неявной передачи, это означает, что эта переменная может быть изменена в то время, как транзакция происходит, не затрагивая транзакцию. binlog_rows_query_log_events Системная Имя binlog_rows_query_log_events Контекст переменной Глобальная и сеансовая Динамическая Да Допустимые значения Тип boolean Значение по умолчанию FALSE binlog_rows_query_log_events затрагивает только основанное на строке журналирование. Когда включено, это заставляет MySQL Server писать информационные события журнала, такие как события журнала запроса строки в его двоичной журнал. Эта информация может использоваться для отладки и связанных целей, такой как получение оригинального запроса, выпущенного на ведущем устройстве, когда это не может быть восстановлено из обновлений строки. Эти события обычно игнорируются программами MySQL, читая двоичный журнал и не вызывают проблемы, копируя или восстанавливая от резервного копирования. Чтобы рассмотреть их, увеличьте уровень подробностей при использовании опции --verbose в mysqlbinlog дважды, например, "-vv" или "--verbose --verbose". binlog_stmt_cache_size Командная строка --binlog_stmt_cache_size=# Системная Имя binlog_stmt_cache_size Контекст переменной Глобальная Динамическая Да Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 32768 Минимум 4096 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 32768 Минимум 4096 Максимум 18446744073709551615 Эта переменная определяет размер кэша для двоичного журнала, чтобы считать нетранзакционные запросы выпущенными во время транзакции. Кэш запроса выделен для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы хранения и если у сервера есть двоичной включенный журнал (--log-bin ). Если Вы часто используете большие нетранзакционные запросы во время транзакций, Вы можете увеличить этот размер кэша, чтобы получить лучшую работу. Binlog_stmt_cache_use и Binlog_stmt_cache_disk_use могут быть полезными для настройки размера этой переменной. См. раздел 6.4.4. binlog_cache_size устанавливает размер для операционного кэша. log_bin Системная Имя log_bin Контекст переменной Глобальная Динамическая Нет Включен ли двоичной журнал. Если --log-bin используется, тогда значение этой переменной ON, иначе OFF. Эта переменная сообщает только относительно состояния журналирования (включено или отключено), это не сообщает о значении --log-bin. См. раздел 6.4.4. log_bin_basename Системная Имя log_bin_basename Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Значение по умолчанию datadir + '/' + hostname + '-bin' Имя и полный путь к двоичному файлу системного журнала. В отличие от log_bin, log_bin_basename отражает имя, заданное опцией --log-bin. log_bin_index Системная Имя log_bin_index Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип file name Индексный файл для файла двоичного системного журнала. log_bin_use_v1_row_events Командная строка --log-bin-use-v1-row-events[={0|1}] Системная Имя log_bin_use_v1_row_events Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию 0 Используется ли журналирование Version 2. Значение 1 указывает, что сервер пишет двоичной журнал, используя события журналирования Version 1 (единственная версия двоичных событий журнала, используемая в предыдущих выпусках), и таким образом производит двоичный журнал, который может быть считан более старыми ведомыми устройствами. 0 указывает, что события журнала используют Version 2. Эта переменная только для чтения. Чтобы переключиться между журналированием Version 1 и Version 2, необходимо перезапустить mysqld с опцией --log-bin-use-v1-row-events. log_slave_updates Командная строка --log-slave-updates Системная Имя log_slave_updates Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию FALSE Должны ли обновления, полученные ведомым сервером от главного быть зарегистрированы в собственном двоичном журнале ведомого устройства. Двоичное журналирование должно быть позволено на ведомом устройстве для работы этой переменной. См. раздел 19.1.6. log_statements_unsafe_for_binlog Системная Имя log_statements_unsafe_for_binlog Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию ON Если ошибка 1592 происходит, добавлены ли произведенные предупреждения к журналу ошибок или нет. master_verify_checksum Системная Имя master_verify_checksum Контекст переменной Глобальная Динамическая Да Допустимые значения Тип boolean Значение по умолчанию OFF Включение этой переменной заставляет ведущее устройство исследовать контрольные суммы, читая из двоичного журнала. master_verify_checksum отключена по умолчанию, в этом случае ведущее устройство использует длину событий от двоичного журнала, чтобы проверить события, чтобы только полные события были считаны из двоичного журнала. max_binlog_cache_size Командная строка --max_binlog_cache_size=# Системная Имя max_binlog_cache_size Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 18446744073709551615 Минимум 4096 Максимум 18446744073709551615 Допустимые значения Тип integer Значение по умолчанию 4294967295 Минимум 4096 Максимум 4294967295 Если транзакция требует больше этого числа байтов памяти, сервер производит ошибку Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage. Минимальное значение 4096. Максимальное 16EB (exabytes). Максимальное рекомендуемое значение 4GB, это следствие того, что MySQL в настоящее время не может работать с двоичными позициями журнала больше 4GB. max_binlog_cache_size устанавливает размер для операционного кэша, верхним пределом для кэша запроса управляет max_binlog_stmt_cache_size. В MySQL 8.0 видимость к сеансам max_binlog_cache_size соответствует binlog_cache_size, другими словами, изменение значения действует только на новые сеансы, которые запущены после изменения. max_binlog_size Командная строка --max_binlog_size=# Системная Имя max_binlog_size Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1073741824 Минимум 4096 Максимум 1073741824 Если запись в двоичный журнал заставляет текущий размер файла системного журнала превышать значение этой переменной, сервер ротирует двоичные журналы (закрывает текущий файл и открывает следующий). Минимальное значение составляет 4096 байтов. Максимальное и значение по умолчанию 1GB. Транзакция написана в одном куске в двоичный журнал, таким образом, это никогда не разделяется между несколькими двоичными журналами. Поэтому, если у Вас есть большие транзакции, Вы могли бы видеть двоичные файлы системного журнала, больше max_binlog_size. Если max_relay_log_size = 0, max_binlog_size относится также к журналам реле. max_binlog_stmt_cache_size Командная строка --max_binlog_stmt_cache_size=# Системная Имя max_binlog_stmt_cache_size Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 18446744073709547520 Минимум 4096 Максимум 18446744073709547520 Если нетранзакционные запросы в пределах транзакции требуют больше, чем это количество памяти, сервер производит ошибку. Минимальное значение 4096. Максимальные и значения по умолчанию 4GB на 32-битовых платформах и 16EB (exabytes) на 64-битовых платформах. max_binlog_stmt_cache_size устанавливает размер только для кэша запроса, верхним пределом для операционного кэша управляет исключительно max_binlog_cache_size. sync_binlog Командная строка --sync-binlog=# Системная Имя sync_binlog Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1 Минимум 0 Максимум 4294967295 Допустимые значения (32-bit platforms) Тип integer Значение по умолчанию 0 Минимум 0 Максимум 4294967295 Допустимые значения (64-bit platforms) Тип integer Значение по умолчанию 0 Минимум 0 Максимум 4294967295 Средство управления числом групп двоичного журнала, чтобы собрать прежде, чем синхронизировать двоичный журнал с диском. Когда sync_binlog=0, двоичный журнал никогда не синхронизируется с диском, когда sync_binlog больше 0, это число групп журнала периодически синхронизируется. Когда sync_binlog=1, все транзакции синхронизированы с двоичным журналом прежде, чем они будут переданы. Поэтому даже в случае неожиданного перезапуска, любые транзакции, которые отсутствуют в двоичном журнале, находятся только в готовом состоянии. Это заставляет автоматическую подпрограмму восстановления сервера удалять те транзакции.Это гарантирует, что никакая транзакция не потеряна из двоичного журнала и является самой безопасной. Однако у этого может быть негативное воздействие на работу из-за увеличенного числа записей на диск. Использование более высокого значения улучшает работу, но с увеличенным риском потери данных. Когда sync_binlog=0 или sync_binlog больше 1, транзакции переданы, не будучи синхронизированными с диском. Поэтому в случае перебоя в питании или катастрофического отказа операционной системы, возможно, что сервер передал некоторые транзакции, которые не были синхронизированы с двоичным журналом. Поэтому для подпрограммы восстановления невозможно возвратить эти транзакции и они будут потеряны из двоичного журнала. Значение по умолчанию sync_binlog = 1 является самым безопасным выбором, но, как отмечено выше, может воздействовать на работу. До MySQL 5.7.7 значение по умолчанию было 0, которое не конфигурирует синхронизацию, в этом случае сервер полагается на операционную систему, чтобы время от времени сбросить содержание двоичного журнала. 19.1.6.5. Опции и переменные глобального операционного ID Опции запуска, используемые с репликацией GTID Следующие опции запуска сервера используются с GTID-репликацией: --enforce-gtid-consistency Командная строка --enforce-gtid-consistency[=value] Системная Имя enforce_gtid_consistency Контекст переменной Глобальная Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию OFF Допустимые значения OFF ON WARN Когда включено, сервер проводит в жизнь последовательность GTID, позволяя выполнение только запросов, которые могут быть безопасно зарегистрированы, используя GTID. Вы должны установить эту опцию в ON прежде, чем включить GTID-репликацию. Значения --enforce-gtid-consistency может быть сконфигурировано к: OFF: всем транзакциям позволяют нарушить последовательность GTID. ON: никакой транзакции не позволяют нарушить последовательность GTID. WARN: всем транзакциям позволяют нарушить последовательность GTID, но предупреждение произведено в этом случае. Установка --enforce-gtid-consistency без значения это псевдоним для --enforce-gtid-consistency=ON. Это воздействует на поведение переменной, см. enforce_gtid_consistency. Только запросы, которые могут быть зарегистрированы, используя GTID, могут быть зарегистрированы, когда enforce-gtid-consistency = ON, таким образом, операции, перечисленные здесь, не могут использоваться с этой опцией: CREATE TABLE ... SELECT. CREATE TEMPORARY TABLE или DROP TEMPORARY TABLE в транзакциях. Транзакции или запросы, которые обновляют транзакционные и нетранзакционные таблицы. Есть исключение, что нетранзакционный DML позволен в той же самой транзакции или в том же самом запросе, как транзакционный DML, если все нетранзакционные таблицы являются временными. См. раздел 19.1.3.4. --executed-gtids-compression-period Устаревшая 5.7.6 Командная строка --executed-gtids-compression-period=# Допустимые значения Тип integer Значение по умолчанию 1000 Минимум 0 Максимум 4294967295 Эта опция устарела и будет удалена в будущем выпуске MySQL. Используйте gtid_executed_compression_period. --gtid-mode Командная строка --gtid-mode=MODE Системная Имя gtid_mode Контекст переменной Глобальная Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию OFF Допустимые значения OFF OFF_PERMISSIVE ON_PERMISSIVE ON Эта опция определяет, используются ли глобальные операционные идентификаторы (GTID), чтобы идентифицировать транзакции. Установка этой опции в --gtid-mode=ON требует enforce-gtid-consistency = ON. gtid_mode переменная является динамической и позволяет репликации GTID быть сконфигурированной онлайн. Перед использованием этой особенности см. раздел 19.1.5. --gtid-executed-compression-period Командная строка --gtid-executed-compression-period=# Допустимые значения Тип integer Значение по умолчанию 1000 Минимум 0 Максимум 4294967295 Сжать таблицу mysql.gtid_executed каждое указанное число транзакций. Установка 0 говорит, что эта таблица не сжата. Никакое сжатие таблицы не происходит, когда двоичное журналирование включено, поэтому опция не имеет никакого эффекта, если log_bin = OFF. Системные переменные, используемые с репликацией GTID Следующие системные переменные используются с GTID-репликацией: binlog_gtid_simple_recovery Командная строка --binlog-gtid-simple-recovery Системная Имя binlog_gtid_simple_recovery Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию FALSE Допустимые значения Тип boolean Значение по умолчанию TRUE Эта переменная управляет, как двоичные файлы системного журнала повторены во время поиска GTID, когда MySQL запускается или перезапускается. Когда binlog_gtid_simple_recovery=FALSE, метод повторения двоичных файлов системного журнала: Чтобы инициализировать gtid_executed, файлы системного журнала повторены от новейшего файла, останавливаясь в первом двоичном журнале, у которого есть любой Previous_gtids_log_event. Все GTID из Previous_gtids_log_event и Gtid_log_events считаны из этого двоичного файла системного журнала. Этот набор GTID сохранен внутренне и назван gtids_in_binlog. Значение gtid_executed вычислено как союз этого набора и GTID, сохраненного в таблице mysql.gtid_executed. Этот процесс может занять много времени, если у Вас большое количество двоичных файлов системного журнала без событий GTID, например, создаваемых, когда gtid_mode=OFF. Чтобы инициализировать gtid_purged, двоичные файлы системного журнала повторены от самого старого до новейшего, останавливаясь на первом двоичном журнале, который содержит любой Previous_gtids_log_event, который не пуст (у которого есть по крайней мере один GTID), или у этого есть по крайней мере один Gtid_log_event. От этого двоичного журнала это читает Previous_gtids_log_event. Этот набор GTID вычтен из gtids_in_binlog и результат сохранен во внутренней переменной gtids_in_binlog_not_purged. Значение gtid_purged инициализировано к значению gtid_executed минус gtids_in_binlog_not_purged. Когда binlog_gtid_simple_recovery=TRUE, что является значением по умолчанию, сервер повторяет только самый старый и новейший двоичные файлы системного журнала и значения gtid_purged и gtid_executed вычислены, базируясь только на Previous_gtids_log_event или Gtid_log_event, найденных в этих файлах. Это гарантирует, что только два двоичных файла системного журнала повторены во время перезапуска сервера или когда двоичные журналы очищаются. Если эта опция включена, gtid_executed и gtid_purged могут быть инициализированы неправильно в следующих ситуациях: Новейший двоичный журнал был произведен MySQL 5.7.5 или более старый, и gtid_mode ON для некоторых двоичных журналов, но OFF для новейшего двоичного журнала. SET GTID_PURGED был сделан на версии MySQL до 5.7.7, и двоичной журнал, который был активным во время SET GTID_PURGED еще не был очищен. Если неправильный набор GTID будет вычислен в любой ситуации, то останется неправильным, даже если сервер будет позже перезапущен, независимо от значения этой опции. enforce_gtid_consistency Командная строка --enforce-gtid-consistency[=value] Системная Имя enforce_gtid_consistency Контекст переменной Глобальная Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию OFF Допустимые значения OFF ON WARN В зависимости от значения этой переменной сервер проводит в жизнь последовательность GTID, позволяя выполнение только запросов, которые могут быть безопасно зарегистрированы, используя GTID. Вы должны установить эту переменную в ON прежде, чем включить GTID-репликацию. Значение enforce_gtid_consistency может быть сконфигурирован к: OFF: всем транзакциям позволяют нарушить последовательность GTID. ON: никакой транзакции не позволяют нарушить последовательность GTID. WARN: всем транзакциям позволяют нарушить последовательность GTID, но предупреждение произведено в этом случае. До MySQL 5.7.6 enforce-gtid-consistency по умолчанию была OFF. Чтобы поддержать совместимость с предыдущими версиями, в MySQL 5.7.6 значение по умолчанию OFF и --enforce-gtid-consistency без значения интерпретируется как установка значения ON. У переменной также есть многократные текстовые псевдонимы для значений: 0=OFF=FALSE, 1=ON=TRUE,2=WARN. Это отличается от другого перечисления, но поддерживает совместимость с булевым типом, используемым в предыдущих версиях. Эти изменения воздействуют на то, что возвращено переменной. Используя SELECT @@ENFORCE_GTID_CONSISTENCY, SHOW VARIABLES LIKE 'ENFORCE_GTID_CONSISTENCY' и SELECT * FROM INFORMATION_SCHEMA.VARIABLES WHERE 'VARIABLE_NAME' = 'ENFORCE_GTID_CONSISTENCY', все возвращается в текстовой форме, не числовой. Это несовместимое изменение, с тех пор как @@ENFORCE_GTID_CONSISTENCY возвращает числовую форму для boolean, но возвращает текстовую форму для SHOW и Information Schema. executed_gtids_compression_period Устаревшая 5.7.6 Системная Имя executed_gtids_compression_period Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1000 Минимум 0 Максимум 4294967295 Эта опция устарела и будет удалена в будущем выпуске MySQL. Используйте gtid_executed_compression_period. gtid_executed Системная Имя gtid_executed Контекст переменной Глобальная и сеансовая Динамическая Нет Системная Имя gtid_executed Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип string Когда используется с глобальным контекстом, эта переменная содержит представление набора всех транзакций, выполненных на сервере и GTID, которые были установлены SET gtid_purged. Это то же самое, как значение столбца Executed_Gtid_Set в SHOW MASTER STATUS и SHOW SLAVE STATUS. Значение этой переменной набор GTID. Когда сервер запускается, @@global.gtid_executed инициализирована. GTID тогда добавлены к набору, поскольку транзакции выполнены, или если выполнен любой SET gtid_purged. Набор транзакций, которые могут быть найдены в двоичных журналах в любой момент времени, равен GTID_SUBTRACT(@@global.gtid_executed, @@global.gtid_purged), то есть, всем транзакциям в двоичном журнале, которые еще не были очищены. RESET MASTER заставляет глобальное значение (но не значение сеанса) этой переменной быть сброшенным к пустой строке. GTID иначе не удалены из этого набора кроме того, когда набор очищен из-за RESET MASTER. До MySQL 5.7.7 эта переменная могла также использоваться с контекстом сеанса, где это содержало представление набора транзакций, которые написаны кэшу в текущем сеансе. Контекст сеанса устарел в MySQL 5.7.7. gtid_executed_compression_period Системная Имя gtid_executed_compression_period Контекст переменной Глобальная Динамическая Да Допустимые значения Тип integer Значение по умолчанию 1000 Минимум 0 Максимум 4294967295 Сжать таблицу mysql.gtid_executed каждые раз, когда выполнено число транзакций, заданных переменной. Установка 0 указывает, что эта таблица не сжата. Так как никакое сжатие таблицы не происходит, когда используется двоичный журнал, установка значение переменной не имеет никакого эффекта, если двоичное журналирование не отключено. gtid_mode Системная Имя gtid_mode Контекст переменной Глобальная Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию OFF Допустимые значения OFF OFF_PERMISSIVE ON_PERMISSIVE ON Средство управления, включено до GTID-журналирование и какие транзакции журналы могут содержать. До MySQL 5.7.6 эти переменные были только для чтения и были установлены, используя --gtid-mode. MySQL 5.7.6 позволяет этой переменной быть установленной динамически. Вы должны иметь привилегию SUPER , чтобы установить эту переменную. enforce_gtid_consistency должна быть истина прежде, чем Вы сможете установить gtid_mode=ON . Прежде чем изменить эту переменную, см. раздел 19.1.5. Зарегистрированные транзакции могут быть анонимными или использовать GTID. Анонимные транзакции полагаются на двоичной файл системного журнала и позицию, чтобы идентифицировать определенные транзакции. У транзакций GTID есть уникальный идентификатор, который используется, чтобы обратиться к транзакциям. Различные режимы: OFF: Новые и копируемые транзакции должны быть анонимными. OFF_PERMISSIVE: Новые транзакции являются анонимными. Копируемые транзакции могут быть анонимными или транзакциями GTID. ON_PERMISSIVE: Новые транзакции GTID. Копируемые транзакции могут быть анонимными или транзакциями GTID. ON: Новые и копируемые транзакции должны быть транзакциями GTID. Изменения от одного значения до другого могут быть только пошаговыми за один раз. Например, если gtid_mode сейчас OFF_PERMISSIVE, возможно изменить на OFF или ON_PERMISSIVE, но не на ON. gtid_purged и gtid_executed являются постоянными независимо от значения gtid_mode. Поэтому даже после изменения gtid_mode эти переменные содержат правильные значения. gtid_next Системная Имя gtid_next Контекст переменной Session Динамическая Да Допустимые значения Тип enumeration Значение по умолчанию AUTOMATIC Допустимые значения AUTOMATIC ANONYMOUS UUID:NUMBER Эта переменная используется, чтобы определить, как следующий GTID получен. gtid_next может взять любое из следующих значений: AUTOMATIC: Используйте следующее автоматически произведенное глобальное операционное ID. ANONYMOUS: Транзакции не имеют глобальных идентификаторов и идентифицированы только файлом и позицией. Глобальное операционное ID в формате UUID:NUMBER. Точно то, какие из вышеупомянутых опций допустимы, зависит от установки setting of gtid_mode, см. раздел 19.1.5.1. Установка этой переменной не имеет никакого эффекта, если gtid_mode OFF. После того, как эта переменная была установлена в UUID:NUMBER и транзакция была передана или удалена, явное SET GTID_NEXT должно снова быть сделано перед любым другим запросом. DROP TABLE или DROP TEMPORARY TABLE терпит неудачу с явной ошибкой, когда используется на комбинации невременных таблиц с временными таблицами или временных таблиц, используя транзакционные механизмы хранения с временными таблицами, используя нетранзакционные механизмы хранения. gtid_owned Системная Имя gtid_owned Контекст переменной Глобальная и сеансовая Динамическая Нет Допустимые значения Тип string Эта переменная только для чтения содержит список, содержание которого зависит от его контекста. Когда используется с контекстом сеанса, список содержит все GTID, которые принадлежат этому клиенту, когда используется с глобальным контекстом, это содержит список всех GTID с их владельцами. gtid_purged Системная Имя gtid_purged Контекст переменной Глобальная Динамическая Да Допустимые значения Тип string Набор всех транзакций, которые были вычищены из двоичного журнала. Это подмножество набора транзакций в gtid_executed. Значение этой переменной набор GTID. Когда сервер запускается, глобальное значение gtid_purged инициализировано к ряду GTID. RESET MASTER заставляет значение этой переменной быть сброшенным к пустой строке. Возможно обновить значение этой переменной, но только когда gtid_executed пустая строка, и поэтому gtid_purged пустая строка. Это может произойти когда репликация не была запущена ранее или когда репликация ранее не использовала GTID. Эта переменная устанавливается независимо от значения gtid_mode. Если все существующие двоичные журналы были произведены, используя MySQL 5.7.6 или позже, после SET gtid_purged binlog_gtid_simple_recovery=TRUE (настройка по умолчанию в MySQL 5.7.7 и позже) может безопасно использоваться. Если двоичные журналы от MySQL 5.7.7 или ранее существуют, есть шанс, что gtid_purged может быть вычислен неправильно. Если Вы используете MySQL 5.7.7 или ранее, после SET gtid_purged запрос записывает текущее двоичное имя файла системного журнала, которое может быть проверено, используя SHOW MASTER STATUS. Если сервер перезапущен прежде, чем этот файл был очищен, то Вы должны использовать binlog_gtid_simple_recovery=FALSE, чтобы избегать неправильного gtid_purged или gtid_executed. simplified_binlog_gtid_recovery Устаревшая 5.7.6 Командная строка --simplified-binlog-gtid-recovery Системная Имя simplified_binlog_gtid_recovery Контекст переменной Глобальная Динамическая Нет Допустимые значения Тип boolean Значение по умолчанию FALSE Эта опция устарела и будет удалена в будущем выпуске MySQL. Используйте binlog_gtid_simple_recovery. 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 Поля из отчета о состоянии: Slave_IO_State: Текущий статус ведомого устройства. См. разделы 9.14.5 и 9.14.6. Slave_IO_Running: Работает ли поток ввода/вывода для того, чтобы считать двоичный журнал ведущего устройства. Обычно Вы хотите, чтобы это было Yes, если Вы еще не запустили репликацию или явно остановили ее с STOP SLAVE. Slave_SQL_Running: Работает ли поток SQL для того, чтобы запустить события в журнале реле. Как с потоком ввода/вывода, это должно обычно быть Yes. Last_IO_Error, Last_SQL_Error: Последние ошибки, зарегистрированные вводом/выводом и SQL, обрабатывая журнал реле. Идеально они должны быть пробелом, не указывая ни на какие ошибки. Seconds_Behind_Master: Число секунд, на которые ведомый поток SQL находится позади обработки основного двоичного журнала. Высокое число (или увеличивающееся) может указать, что ведомое устройство неспособно обработать события от ведущего устройства своевременно. Значение 0 для Seconds_Behind_Master может обычно интерпретироваться как то, что ведомое устройство догнало ведущее устройство, но есть некоторые случаи, где это не строго истинно. Например, это может произойти, если сетевое соединение между ведущим устройством и ведомым устройством сломано, но ведомый поток ввода/вывода еще не заметил этого, то есть, slave_net_timeout еще не прошел. Это также возможно тот переходный процесс значения для Seconds_Behind_Master не отражает ситуацию точно. Когда ведомый поток SQL нагнал во вводе/выводе, Seconds_Behind_Master покажет 0,но когда ведомый поток ввода/вывода все еще держит в очереди новое событие, Seconds_Behind_Master может показать большое значение, пока поток SQL не заканчивает запуск события. Это особенно вероятно, когда у событий есть старый timestamp, в таких случаях, если Вы выполняете SHOW SLAVE STATUS несколько раз за относительно короткий период, Вы можете видеть, что это значение изменяется назад и вперед неоднократно между 0 и относительно большим значением. Несколько пар областей предоставляют информацию о продвижении ведомого устройства в чтении событий от основного двоичного журнала и обработки их в журнале реле: (Master_Log_file, Read_Master_Log_Pos): Координаты в основном двоичном журнале, указывающем, как далеко ведомый поток ввода/вывода считал события из журнала. (Relay_Master_Log_File, Exec_Master_Log_Pos): Координаты в основном двоичном журнале, указывающем, как далеко ведомый поток SQL запустил события, полученные от журнала. (Relay_Log_File, Relay_Log_Pos): Координаты в ведомом журнале реле, указывающие, как далеко ведомый поток SQL выполнил журнал реле. Они соответствуют предыдущим координатам, но выражены в ведомых координатах журнала реле, а не основных двоичных координатах журнала. На ведущем устройстве Вы можете проверить состояние соединенного ведомого использованием 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. Форматы репликации Репликация работает, потому что события, написанные двоичному журналу, считаны от ведущего устройства и затем обработаны на ведомом устройстве. События зарегистрированы в пределах двоичного журнала в различных форматах, согласно типу события. Различные используемые форматы репликации соответствуют двоичному формату журналирования, используемому, когда события были зарегистрированы в двоичном журнале ведущего устройства. Корреляция между двоичными форматами журналирования и терминами, использованными во время репликации: Используя основанное на запросе двоичное журналирование, ведущее устройство пишет запросы SQL в двоичный журнал. Репликация ведущего устройства к ведомому устройству работает, выполняя запросы SQL о ведомом устройстве. Это называют основанной на запросе репликацией (часто сокращаемой как SBR), что соответствует стандартному MySQL основанному на запросе двоичному формату журналирования. Репликация в версии MySQL 5.1.4 и ранее использует этот формат исключительно. Используя основанное на строке журналирование, ведущее устройство пишет события в двоичный журнал, которые указывают, как изменены отдельные строки таблицы. Репликация ведущего устройства к ведомому устройству работает, копируя события, представляющие изменения строк таблицы к ведомому устройству. Это называют основанной на строке репликацией (часто сокращенной как RBR). Основанное на строке журналирование это метод по умолчанию. Вы можете также сконфигурировать MySQL, чтобы использовать соединение основанного на запросе и основанного на строке журналирования, в зависимости от того, что является самым подходящим для изменения, которое будет зарегистрировано. Это называют журналированием смешанного формата . Используя журналирование смешанного формата, основанный на запросе журнал используется по умолчанию. В зависимости от определенных запросов и используемого механизма хранения, журнал автоматически переключен на основанный на строке в особых случаях. Репликация используя смешанный формат часто упоминается как репликация смешанного формата. Для получения дополнительной информации см. раздел 6.4.4.3. Используя формат 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. Преимущества и недостатки основанной на запросе и строке репликации У каждого двоичного формата журналирования есть преимущества и недостатки. Для большинства пользователей смешанный формат репликации должен обеспечить лучшую комбинацию целостности данных и работы. Если, однако, Вы хотите использовать в своих интересах особенности, определенные для основанного на запросе или основанного на строке формата репликации, выполняя определенные задачи, Вы можете использовать информацию в этом разделе, который обеспечивает резюме их относительных преимуществ и недостатков, чтобы определить, что лучше для Ваших потребностей. Преимущества основанной на запросе репликации Доказанная технология. Меньше данных, написанных файлам системного журнала. Когда обновления или удаления обрабатывают много строк, это приводит к намного меньшему количеству места для хранения, требуемого для файлов системного журнала. Это также означает, что взятие и восстановление от резервных копий могут быть достигнуты более быстро. Файлы системного журнала содержат все запросы, которые производили любые изменения, таким образом, они могут использоваться, чтобы ревизовать базу данных. Недостатки основанной на запросе репликации Запросы, которые опасны для SBR. Не все запросы, которые изменяют данные (например, INSERT DELETE, UPDATE и REPLACE) могут копироваться, используя основанную на запросе репликацию. Любое недетерминированное поведение трудно копировать, используя основанную на запросе репликацию. Примеры такой ситуации это запросы Data Modification Language (DML): Запрос, который зависит от UDF или сохраненной программы, которая недетерминирована, начиная со значения, возвращенного таким UDF или сохраненной программой, или зависит от факторов кроме параметров. Основанная на строке репликация, однако, просто копирует значение, возвращенное UDF или сохраненной программой, таким образом, ее эффект на строки таблицы и данные тот же самый на ведущем и на ведомом устройстве. См. раздел 19.4.1.12. DELETE и UPDATE, использующие LIMIT без ORDER BY недетерминированы. См. раздел 19.4.1.17. Детерминированный UDF должен быть применен на ведомом устройстве. Запросы, использующие любую из следующих функций, не могут копироваться должным образом, используя основанную на запросе репликацию: LOAD_FILE() UUID(), UUID_SHORT() USER() FOUND_ROWS() SYSDATE() (если и ведущее устройство и ведомое устройство не запущены с --sysdate-is-now). GET_LOCK() IS_FREE_LOCK() IS_USED_LOCK() MASTER_POS_WAIT() RAND() RELEASE_LOCK() SLEEP() VERSION() Однако, все другие функции копируются, правильно используя основанную на запросе репликацию, включая NOW() . См. раздел 19.4.1.16 . Запросы, которые не могут копироваться правильно, используя основанную на запросе репликацию, зарегистрированы с предупреждением, как показано здесь: [Warning] Statement is not safe to log in statement format. Подобное предупреждение также выпущено клиенту в таких случаях. Клиент может вывести на экран это с использованием SHOW WARNINGS. INSERT ... SELECT требует большего числа блокировок на уровне строки, чем с основанной на строке репликацией. UPDATE, которые требуют сканирования таблицы (потому что индекс не используется в WHERE), должны заблокировать большее число строк, чем с основанной на строке репликацией. Для InnoDB: INSERT, который использует AUTO_INCREMENT, блокировка не конфликтует с INSERT. Для сложных запросов запрос должен быть оценен и выполнен на ведомом устройстве прежде, чем строки будут обновлены или вставлены. С основанной на строке репликацией ведомое устройство должно изменить только затронутые строки, а не выполнить полный запрос. Если есть ошибка в оценке на ведомом устройстве, особенно выполняя сложные запросы, основанная на запросе репликация может медленно увеличивать предел погрешности через затронутые строки в течение долгого времени. См. раздел 19.4.1.28. Сохраненные функции выполняются с тем же самым значением NOW(), как при вызове. Однако, это неверно для хранимых процедур. Детерминированный UDF должен быть применен на ведомом устройстве. Табличные определения должны быть (почти) идентичными на ведущем и ведомом устройстве. См. раздел 19.4.1.10. Преимущества основанной на строке репликации Все изменения могут копироваться. Это самая безопасная форма репликации. Запросы, которые обновляют информацию в базе данных mysql, например, GRANT, REVOKE и манипуляции триггерами, сохраненными подпрограммами (включая хранимые процедуры) и представлениями, все копируются к ведомым устройствам, используя основанную на запросе репликацию. Для запросов CREATE TABLE ... SELECT, a CREATE запрос произведен из табличного определения и копируется, используя основанный на запросе формат, в то время как вставки строки копируются, используя основанный на строке формат. Меньше блокировок строки требуется на ведущем устройстве, которое таким образом достигает более высокого параллелизма, для следующих типов запросов: INSERT ... SELECT INSERT с AUTO_INCREMENT. UPDATE или DELETE с WHERE, которые не используют ключи или не изменяют большинство исследованных строк. Меньше блокировок строки требуется на ведомом устройстве для любого запроса INSERT, UPDATE или DELETE. Недостатки основанной на строке репликации RBR может произвести больше данных, которые должны быть зарегистрированы. Чтобы копировать запрос DML (UPDATE или DELETE), основанная на запросе репликация пишет только запрос двоичному журналу. В отличие от этого, основанная на строке репликация пишет каждую измененную строку двоичному журналу. Если запрос изменяет много строк, основанная на строке репликация может написать значительно больше данных, это истина даже для запросов, которые отменены. Это также означает, что создание и восстановление резервного копирования могут потребовать большего количества времени. Кроме того, двоичной журнал заблокирован в течение более длительного времени, чтобы написать данные, которые могут вызвать проблемы параллелизма. Использование binlog_row_image=minimal значительно уменьшает этот недостаток. Детерминированные UDF, которые производят большие BLOB занимают больше времени, чтобы копировать с основанной на строке репликацией, чем с основанной на запросе репликацией. Это потому, что зарегистрировано значение столбца BLOB, а не запрос, производящий данные. Вы не можете видеть на ведомом устройстве, какие запросы были получены от ведущего устройства и выполнены. Однако, Вы можете видеть, какие данные были изменены, используя mysqlbinlog с опциями --base64-output=DECODE-ROWS и --verbose. Альтернативно используйте binlog_rows_query_log_events, которая если включена добавляет событие с Rows_query к выводу mysqlbinlog , когда используется -vv. Для таблиц, используя MyISAM, более сильная блокировка требуется на ведомом устройстве для INSERT, применяя их как основанные на строке события к двоичному журналу, чем применяя их как запросы. Это означает что параллельные вставки на таблицах MyISAM не поддержаны, используя основанную на строке репликацию. 19.2.1.2. Использование основанного на строке журналирования и репликации MySQL использует основанное на запросе журналирование (SBL), основанное на строке журналирование (RBL) или журналирование смешанного формата. Тип двоичного журнала определяет размер и эффективность журналирования. Поэтому выбор между основанной на строке репликацией (RBR) или основанной на запросе репликацией (SBR) зависит от Вашего приложения и окружающей среды. Этот раздел описывает известные проблемы, используя основанный на строке формат журнала и описывает некоторые лучшие методы, используя это в репликации. Основанное на строке журналирование временных таблиц. Как отмечено в разделе 19.4.1.24, временные таблицы не копируются, используя основанный на строке формат. Когда идет использование смешанного журналирования формата, безопасные запросы, вовлекающие временные таблицы, зарегистрированы, используя основанный на запросе формат. Для получения дополнительной информации см. раздел 19.2.1.1. В MySQL 8.0 Вы можете переключиться с основанного на запросе на основанное на строке журналирование, даже когда временные таблицы были составлены. Однако, используя основанный на строке формат, сервер MySQL не может определить режим журналирования, который был в действительности, когда данная временная таблица была составлена. Поэтому сервер в таких случаях регистрирует запрос DROP TEMPORARY TABLE IF EXISTS для каждой временной таблицы, которая все еще существует для данного сеанса клиента, когда сеанс заканчивается. В то время как это означает, что возможно, что ненужный DROP TEMPORARY TABLE мог бы быть зарегистрирован в некоторых случаях, запрос безопасен и не вызывает ошибку, даже если таблица не существует из-за присутствия IF EXISTS опции. Временные таблицы не копируются, используя основанный на строке формат, потому что нет никакой потребности. Кроме того, потому что временные таблицы могут быть только для чтения для потока, который создал их, редко есть какая-либо выгода из мультиплицирования их, используя основанный на запросе формат. Нетранзакционные запросы DML, вовлекающие временные таблицы, позволены, используя binlog_format=ROW , пока любые нетранзакционные таблицы, затронутые запросами, являются временными таблицами (Bug #14272672). RBL и синхронизация нетранзакционных таблиц. Когда много строк затронуты, набор изменений разделен на несколько событий; когда запрос передается, все эти события написаны двоичному журналу. Выполняя на ведомом устройстве, табличная блокировка взята на всех вовлеченных таблицах, затем строки применены в пакетном режиме. В зависимости от механизма, используемого для копии ведомого устройства таблицы, это может быть неэффективно. Время ожидания и размер журнала. RBL пишет изменения для каждой строки к двоичному журналу и таким образом его размер может увеличиться быстро. Это может значительно увеличить время, требуемое, чтобы производить изменения на ведомом устройстве, которые соответствуют изменениям на ведущем устройстве. Вы должны знать о потенциале для этой задержки Ваших приложений. Чтение двоичного журнала. mysqlbinlog выводит на экран основанные на строке события в двоичном журнале, используя BINLOG (см. раздел 14.7.6.1 ). Этот запрос выводит на экран событие как закодированную строку, значение которой не очевидно. Когда вызвано с --base64-output=DECODE-ROWS и --verbose, mysqlbinlog форматирует содержание двоичного журнала, чтобы быть удобочитаемым. Когда двоичные события журнала были написаны в основанном на строке формате, и Вы хотите читать их, можете использовать эту команду, чтобы считать содержание двоичного журнала. См. раздел 5.6.8.2. Ошибки выполнения журнала и slave_exec_mode. Если slave_exec_mode = IDEMPOTENT, нельзя применить изменения от RBL, потому что оригинальная строка не может быть найдена, не вызывает ошибку или заставляет репликацию терпеть неудачу. Это означает, что возможно, что обновления применены на ведомом устройстве так, чтобы ведущее и ведомое устройства больше не были синхронизированы. Проблемы времени ожидания и использование нетранзакционных таблиц с RBR, когда slave_exec_mode = IDEMPOTENT может заставить ведущее и ведомое устройства отклоняться еще далее. Для получения дополнительной информации о slave_exec_mode см. раздел 6.1.5. slave_exec_mode=IDEMPOTENT вообще полезно только для круговой репликации или мультирепликации с MySQL Cluster, для которой IDEMPOTENT значение по умолчанию. Для других сценариев установка slave_exec_mode в STRICT обычно достаточна, это значение по умолчанию для механизмов хранения кроме NDB. NDBCLUSTER в настоящее время не поддерживается в MySQL 8.0. См. MySQL Cluster NDB 7.5. Нехватка контрольных сумм журнала. RBL не использует контрольные суммы, так сеть, диск и другие ошибки не могут быть идентифицированы, обрабатывая двоичной журнал. Чтобы гарантировать, что данные переданы без сетевого повреждения, используют SSL для соединений репликации. CHANGE MASTER TO имеет опции, чтобы включить репликации по SSL. См. также раздел 14.4.2.1. Фильтрация, основанная на ID сервера, не поддержана. В MySQL 8.0 Вы можете фильтровать основываясь на ID при использовании IGNORE_SERVER_IDS в CHANGE MASTER TO. Эта опция работает с основанным на запросе и основанным на строке форматами журналирования. Другой метод, чтобы отфильтровать изменения на некоторых ведомых устройствах должен использовать WHERE, который включает отношение @@server_id <> id_value с UPDATE и DELETE. Например, WHERE @@server_id <> 1. Однако, это не работает правильно с основанным на строке журналированием. Используйте переменную server_id для фильтрации запросов, используя основанное на запросе журналирование. Опции репликации на уровне базы данных. Действие опций --replicate-do-db, --replicate-ignore-db и --replicate-rewrite-db отличается значительно в зависимости от типа журналирования. Поэтому рекомендуется избежать опций на уровне базы данных и вместо этого использовать опции на уровне таблицы, например, --replicate-do-table и --replicate-ignore-table. См. раздел 19.1.6. RBL, нетранзакционные таблицы и остановленные ведомые устройства. Используя основанное на строке журналирование, если ведомый сервер остановлен, в то время как ведомый поток обновляет нетранзакционную таблицу, ведомая база данных может достигнуть непоследовательного состояния. Поэтому рекомендуется, чтобы Вы использовали транзакционной механизм хранения, такой как InnoDB для всех таблиц, копируемых, используя основанный на строке формат. Использование STOP SLAVE или STOP SLAVE SQL_THREAD до закрытия ведомого сервера MySQL помогает препятствовать тому, чтобы проблемы произошли, и всегда рекомендуется независимо от формата журналирования или механизма хранения, который Вы используете. 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. Опасные запросы. Запросы со следующими характеристиками считают опасными: Запросы, содержащие системные функции, которые могут возвратить отличное значение на ведомом устройстве. Эти функции включают FOUND_ROWS(), GET_LOCK(), IS_FREE_LOCK(), IS_USED_LOCK(), LOAD_FILE(), MASTER_POS_WAIT() , PASSWORD(), RAND(), RELEASE_LOCK(), ROW_COUNT(), SESSION_USER(), SLEEP(), SYSDATE(), SYSTEM_USER(), USER(), UUID() и UUID_SHORT(). Недетерминированные функции, которые не рассматривают как опасные. Хотя эти функции не детерминированы, они обработаны как безопасные: CONNECTION_ID(), CURDATE(), CURRENT_DATE(), CURRENT_TIME(), CURRENT_TIMESTAMP() , CURTIME(), LAST_INSERT_ID(), LOCALTIME(), LOCALTIMESTAMP(), NOW(), UNIX_TIMESTAMP(), UTC_DATE(), UTC_TIME() и UTC_TIMESTAMP() . См. раздел 19.4.1.16 . Ссылки на системные переменные. Большинство системных переменных не копируется правильно, используя основанный на запросе формат. См. разделы 19.4.1.38 и 6.4.4.3. UDF. Так как мы не имеем никакого контроля над тем, что делает UDF, мы должны предположить, что он выполняет опасные запросы. Плагин Fulltext. Этот плагин может вести себя по-другому на различных серверах MySQL, поэтому у запросов в зависимости от этого могли быть различные результаты. Поэтому все запросы, полагающиеся на плагин fulltext, обработаны как опасные в MySQL. Триггер или сохраненная программа обновляет таблицу, имеющую столбец AUTO_INCREMENT. Это опасно, потому что порядок, в котором обновлены строки, может разойтись в ведущем и ведомом устройствах. Кроме того, INSERT в таблицу, у которой есть сложный первичный ключ, содержащий AUTO_INCREMENT, который не является первым столбцом этого сложного ключа, опасен. См. раздел 19.4.1.1. INSERT ... ON DUPLICATE KEY UPDATE запросы о таблицах с первичными или уникальными ключами. Когда выполнено для таблицы, которая содержит больше, чем один основной или уникальный ключ, этот запрос считают опасным, будучи чувствительным к порядку, в котором механизм хранения проверяет ключи, который не детерминирован и от которого зависит выбор строк, обновленных MySQL Server. INSERT ... ON DUPLICATE KEY UPDATE запрос для таблицы, имеющей больше, чем один уникальный или первичный ключ, отмечен как опасный для основанной на запросе репликации (Bug #11765650, Bug #58637). Обновления используя LIMIT. Порядок, в котором получены строки, не определен и поэтому считается опасным. См. раздел 19.4.1.17. Доступы или ссылки к таблицам журнала. Содержание системной таблицы журнала может отличаться между ведущим и ведомым устройствами. Нетранзакционные операции после транзакционных операций. В пределах транзакции, позволяя любые нетранзакционные чтения или записи, чтобы выполнить после любых транзакционных чтений или записей, считается опасным. См. раздел 19.4.1.33. Доступы или ссылки к таблицам регистрации. Все чтения и записи к таблицам журналирования считаются опасными. В пределах транзакции любые запросы после чтения или записи также считаются опасными. LOAD DATA INFILE. LOAD DATA INFILE считается опасным, это вызывает предупреждение в основанном на запросе режиме и переключает к основанному на строке формату, используя журналирование смешанного формата. См. раздел 19.4.1.18. См. раздел 19.4.1. 19.2.2. Детали выполнения репликации Способности репликации MySQL осуществлены, используя три потока, один на главном сервере и два на ведомом устройстве: Поток Binlog dump. Ведущее устройство создает поток, чтобы послать двоичное содержание журнала в ведомое устройство, когда ведомое устройство соединяется. Этот поток может быть идентифицирован в выводе SHOW PROCESSLIST на ведущем устройстве как Binlog Dump. Поток дампа журнала приобретает блокировку на двоичном журнале ведущего устройства для того, чтобы считать каждое событие, которое нужно послать в ведомое устройство. Как только событие было считано, блокировка выпущена даже прежде, чем событие посылают в ведомое устройство. Ведомый поток ввода/вывода. Когда START SLAVE сделан на ведомом сервере, ведомое устройство создает поток ввода/вывода, который соединяется с ведущим устройством и просит послать обновления. Ведомый поток ввода/вывода читает обновления, посланные потоком Binlog Dump (см. предыдущий элемент) и копирует их к местным файлам, которые включают журнал реле ведомого устройства. Статус этого потока показывают как Slave_IO_running в выводе SHOW SLAVE STATUS или Slave_running в выводе SHOW STATUS. Ведомый поток SQL. Ведомое устройство создает поток SQL, чтобы читать журнал реле, который написан ведомым вводом/выводом, и запускать события, содержащиеся там. В предыдущем описании есть три потока на основное/ведомое соединение. Ведущее устройство, у которого есть многократные ведомые устройства, создает один двоичной поток дампа журнала для каждого в настоящее время соединяемого ведомого устройства, и у каждого ведомого устройства есть свой собственный ввод/вывод и поток 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 для использования со следующими запросыми репликации в управлении каналом репликации независимо от других каналов: CHANGE MASTER TO START SLAVE STOP SLAVE SHOW RELAYLOG EVENTS FLUSH RELAY LOGS SHOW SLAVE STATUS RESET SLAVE Точно так же дополнительный параметр channel_name введен для следующих функций: MASTER_POS_WAIT() WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() Следующие запросы отвергнуты для канала group_replication_recovery. START SLAVE STOP SLAVE 19.2.3.2. Совместимость с предыдущими запросами репликации Когда у ведомого устройства репликации есть многократные каналы и опция FOR CHANNEL channel_name не определена, допустимый запрос действует на все доступные каналы. Например, следующие запросы ведут себя как ожидалось: START SLAVE запускает потоки репликации для всех каналов, кроме group_replication_recovery. STOP SLAVE останавливает репликацию для всех каналов, кроме group_replication_recovery. SHOW SLAVE STATUS сообщает состояние для всех каналов. FLUSH RELAY LOGS сбрасывает журналы реле для всех каналов. RESET SLAVE перезапускает все каналы. Применяйте RESET SLAVE с осторожностью, поскольку эта команда удаляет все существующие каналы, производит чистку их файлов системного журнала реле и обновляет только канал по умолчанию. Некоторые запросы репликации не могут воздействовать на все каналы. В этом случае выводится ошибка 1964 Multiple channels exist on the slave. Please provide channel name as an argument. Следующие запросы и функции производят эту ошибку, когда используются в мультиисходной топологии репликации и опция FOR CHANNEL channel_name не используется, чтобы определить, на который канал действовать: SHOW RELAYLOG EVENTS CHANGE MASTER TO MASTER_POS_WAIT() WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS() WAIT_FOR_EXECUTED_GTID_SET() Отметьте, что канал по умолчанию всегда существует в единственной исходной топологии репликации, где запросы и функции ведут себя как в предыдущих версиях MySQL. 19.2.3.3. Опции запуска и каналы репликации Этот раздел описывает опции запуска, на которые воздействует добавление каналов репликации. Следующие опции запуска должны быть сконфигурированы правильно, чтобы использовать мультиисходную репликацию. --relay-log-info-repository Это должно быть установлено в TABLE. Если эта опция установлена в FILE, попытка добавить больше источников к ведомому устройству терпит неудачу с ER_SLAVE_NEW_CHANNEL_WRONG_REPOSITORY. --master-info-repository Это должно быть установлено в TABLE. Если эта опция установлена FILE, попытка добавить больше источников к ведомому устройству терпит неудачу с ER_SLAVE_NEW_CHANNEL_WRONG_REPOSITORY. Следующие опции запуска теперь затрагивают все каналы в топологии репликации. --log-slave-updates Все транзакции, полученные ведомым устройством (даже из многократных источников), написаны в двоичный журнал. --relay-log-purge Когда установлено, каждый канал производит чистку своего собственного журнала реле автоматически. --slave_transaction_retries Потоки применения всех каналов повторяют транзакции. --skip-slave-start Никакие потоки репликации не запускаются ни на каких каналах. --slave-skip-errors Выполнение продолжается, ошибки пропущены для всех каналов. Набор значений для следующих опций запуска применяется на каждый канал, так как это опции запуска mysqld , они применены на каждый канал. --max-relay-log-size=size Максимальный размер отдельного файла системного журнала реле для каждого канала, после достижения этого предела файл ротируется. --relay-log-space-limit=size Верхний предел для полного размера всех журналов реле для каждого отдельного канала. Для N каналов объединенный размер этих журналов ограничен relay_log_space_limit * N. --slave-parallel-workers=value Число ведомых параллельных потоков на канал. --slave-checkpoint-group Время ожидания вводом/выводом для каждого источника. --relay-log-index=filename Базовое имя для индексного файла журнала реле каждого канала, см. раздел 19.2.3.4. --relay-log=filename Обозначает базовое имя файла системного журнала реле каждого канала. См. See раздел 19.2.3.4 . --slave_net-timeout=N Это значение установлено на канал, чтобы каждый канал ждал N секунд, чтобы проверить на сломанное соединение. --slave-skip-counter=N Это значение установлено на канал, чтобы каждый канал пропустил N событий от его ведущего устройства. 19.2.3.4. Соглашения о присвоении имен канала репликации Этот раздел описывает, как на соглашения о присвоении имен воздействуют каналы репликации. У каждого канала репликации есть уникальное имя, которое является строкой с максимальной длиной 64 символа и является нечувствительным к регистру. Поскольку названия канала используются в ведомых таблицах, набором символов, используемым для них, всегда является UTF-8. Хотя Вы вообще свободны использовать любое название каналов, следующие имена сохранены: group_replication_applier group_replication_recovery Имя, которое Вы выбираете для канала репликации, также влияет на имена файла, используемые ведомым устройством мультирепликации. Файлы системного журнала реле и индексные файлы для каждого канала называют base_name-relay-bin-channel_name .0000x, где base_name имя хоста (если не определено использованием --log-bin) и channel_name название канала, зарегистрированного к этому файлу. 19.2.4. Реле репликации и журналы состояния Во время репликации ведомый сервер создает несколько журналов, которые хранят события, переданные от ведущего к ведомому устройству и делают запись информации о текущем статусе и местоположении в пределах журнала реле. Есть три типа журналов, используемых в процессе, перечисленных здесь: Журнал реле состоит из событий, считанных из двоичного журнала ведущего устройства и написанный ведомым потоком ввода/вывода. События в журнале реле запущены на ведомом устройстве как часть потока SQL. Основной журнал информации содержит состояние и текущую информацию о конфигурации для соединения ведомого устройства с ведущим устройством. Этот журнал содержит информацию об основном имени хоста, параметрах входа в систему и координатах, указывающих, где ведомое устройство читает из двоичного журнала ведущего устройства. Этот журнал может быть написан в таблицу mysql.slave_master_info вместо файла, запуская ведомое устройство с опцией --master-info-repository=TABLE. Журнал информации журнала реле содержит информацию о статусе выполнения в пределах журнала реле ведомого устройства. Этот журнал может быть написан в таблицу mysql.slave_relay_log_info вместо файла, запуская ведомое устройство с --relay-log-info-repository=TABLE. Безопасная от катастрофического отказа репликация. Для репликации, чтобы быть безопасной от катастрофического отказа, используя таблицы для того, чтобы зарегистрировать состояние и информацию о реле, эти таблицы должны использовать транзакционной механизм хранения, такой как 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 Ведомый сервер создает новый файл системного журнала реле при следующих условиях: Каждый раз, когда поток ввода/вывода запускается. Когда журналы сброшены, например, с FLUSH LOGS или mysqladmin flush-logs . Когда размер текущего файла системного журнала реле становится слишком большим, что определено следующим образом: Если значение max_relay_log_size больше 0, что является максимальным размером файла системного журнала реле. Если значение max_relay_log_size = 0, max_binlog_size определяет максимальный размер файла системного журнала реле. Поток 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, процесс подобен, но опции проверены на ведущем устройстве. С основанной на запросе репликацией база данных по умолчанию проверена на соответствие. С основанной на строке репликацией база данных, где данные должны быть изменены, является базой данных, которая проверена. Независимо от двоичного формата журналирования проверка опций на уровне базы данных продолжается как показано в следующей диаграмме. Вовлеченные шаги перечислены здесь: Есть ли любые --replicate-do-db ? Да. Какая-либо из них соответствует базе данных? Да. Выполнить запрос. Нет. Проигнорировать запрос. Нет. Пеерйти на шаг 2. Есть ли любая опция --replicate-ignore-db? Да. Какая-либо из них соответствует базе данных? Да. Проигнорировать запрос. Нет. Перейти на шаг 3. Нет. Перейти на шаг 3. Продолжите двигаться к проверке опций репликации на уровне таблицы, если они есть. Для описания того, как эти опции проверены, см. раздел 19.2.5.2. Запрос, который все еще разрешен на данном этапе, фактически еще не выполнен. Запрос не выполнен, пока все опции на уровне таблицы (если есть) не были также проверены, и результат этого процесса разрешает выполнение запроса. Для двоичного журналирования вовлеченные шаги перечислены здесь: Есть ли любые опции --binlog-do-db или --binlog-ignore-db? Да. Перейти на шаг 2. Нет. Зарегистрировать запрос. Есть ли база данных по умолчанию (имеется любая база данных, выбранная USE)? Да. Перейти на шаг 3. Нет. Проигнорировать запрос. Есть база данных по умолчанию. Есть ли любая опция --binlog-do-db ? Да. Какая-либо из них соответствует базе данных? Да. Зарегистрировать запрос. Нет. Проигнорировать запрос. Нет. Перейти на шаг 4. Любая из опций --binlog-ignore-db соответствуют базе данных? Да. Проигнорировать запрос. Нет. Зарегистрировать запрос. Для основанного на запросе журналирования исключение сделано в правилах, для CREATE DATABASE, ALTER DATABASE и DROP DATABASE. В тех случаях база данных заменяет базу данных по умолчанию определяя, зарегистрировать или проигнорировать обновления. --binlog-do-db может иногда означать игнорировать другие базы данных . Например, используя основанное на запросе журналирование, сервер, работающий только с --binlog-do-db=sales не пишет в двоичный журнал запросы, для которых база данных по умолчанию отличается от sales. Используя основанное на строке журналирование с той же самой опцией, сервер регистрирует только обновления об изменении в sales. 19.2.5.2. Оценка опций репликации на уровне таблицы Ведомое устройство проверяет и оценивает табличные опции, только если любое из следующих двух условий истина: Никакие опции базы данных соответствия не были найдены. Одна или более опций базы данных были найдены и оценены, чтобы достигнуть выполнения условия согласно правилам, описанным в предыдущем разделе (см. раздел 19.2.5.1). Как предварительное условие, ведомое устройство проверяет, включена ли основанная на запросе репликация. Если это так, и запрос происходит в пределах сохраненной функции, ведомое устройство выполняет запрос. Если основанная на строке репликация включена, ведомое устройство не знает, произошел ли запрос в пределах сохраненной функции на ведущем устройстве, таким образом, это условие не применяется. Для основанной на запросе репликации события представляют запросы (все изменения, составляющие данное событие, связаны с единственным запросом SQL), для основанной на строке репликации каждое событие представляет изменение в единственной строке таблицы (таким образом, единственный запрос, такой как UPDATE mytable SET mycol = 1 может привести ко многим основанным на строке событиям). Когда рассматривается с точки зрения событий, процесс проверки опций таблицы тот же самый для основанной на строке и для основанной на запросе репликации. Достигнув этой точки, если нет никаких табличных опций, ведомое устройство просто запускает все события. Если есть --replicate-do-table или --replicate-wild-do-table, событие должно соответствовать одной из них, если это должно быть выполнено, иначе это проигнорировано. Если есть --replicate-ignore-table или --replicate-wild-ignore-table, все события запущены кроме тех, которые соответствуют любой из этих опций. Этот процесс проиллюстрирован на следующей диаграмме. Следующие шаги описывают эту оценку более подробно: Есть ли какие-либо табличные опции? Да. Перейти на шаг 2. Нет. Выполнить событие. Есть ли любая опция --replicate-do-table? Да. Таблица соответствует какой-то из них? Да. Выполнить событие. Нет. Перейти на шаг 3. Нет. Перейти на шаг 3. Есть ли любая опция --replicate-ignore-table? Да. Таблица соответствует какой-то из них? Да. Проигнорировать событие. Нет. Перейти на шаг 4. Нет. Перейти на шаг 4. Есть ли любая опция --replicate-wild-do-table? Да. Таблица соответствует какой-то из них? Да. Выполнить событие. Нет. Перейти на шаг 5. Нет. Перейти на шаг 5. Есть ли любая опция --replicate-wild-ignore-table? Да. Таблица соответствует какой-то из них? Да. Проигнорировать событие. Нет. Перейти на шаг 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. Использование репликации для резервных копий Чтобы использовать репликацию в качестве резервного решения, копируйте данные от ведущего устройства к ведомому, а затем зарезервируйте ведомое устройство данных. Ведомое устройство может быть поставлено на паузу и закрыто, не затрагивая рабочую работу ведущего устройства, таким образом, Вы можете произвести эффективный снимок живых данных, которые иначе потребовали бы, чтобы ведущее устройство было закрыто. То, как Вы поддерживаете базу данных, зависит от ее размера и поддерживаете ли Вы только данные, или данные и состояние репликации так, чтобы Вы могли восстановить ведомое устройство в случае отказа. Есть поэтому два выбора: Если Вы используете репликацию в качестве решения, чтобы позволить Вам поддержать данные по ведущему устройству, и размер Вашей базы данных не является слишком большим, mysqldump может помочь, см. раздел 19.3.1.1 . Для больших баз данных, где mysqldump был бы непрактичен или неэффективен, Вы можете поддержать файлы необработанных данных вместо этого. Использование опции файлов необработанных данных также означает, что Вы можете поддержать двоичный и журнал реле, которые позволят Вам обновить ведомое устройство в случае отказа. Для получения дополнительной информации см. раздел 19.3.1.2 . Другая резервная стратегия, которая может использоваться для основных или для ведомых серверов, состоит в том, чтобы поместить сервер в статус только для чтения. Резервное копирование выполнено на сервере только для чтения, который сразу изменен назад на его обычное операционное состояние чтения-записи. См. раздел 19.3.1.3 . 19.3.1.1. Поддержка ведомого устройства используя mysqldump Использование mysqldump , чтобы создать копию базы данных позволяет Вам получить все данные в базе данных в формате, который позволяет информации быть импортированной в другой MySQL Server (см. раздел 5.5.4). Поскольку формат информации это запросы SQL, файл может легко быть распределен на рабочие серверы, когда Вы нуждаетесь в доступе к данным в чрезвычайной ситуации. Однако, если размер Вашего набора данных является очень большим, mysqldump может быть непрактичным. Используя mysqldump , Вы должны остановить репликацию на ведомом устройстве прежде, чем запустить процесс дампа, чтобы гарантировать, что дамп содержит непротиворечивое множество данных: Остановите обработку запросов на ведомом. Вы можете остановить репликацию полностью на ведомом устройстве, используя mysqladmin : shell> mysqladmin stop-slave Альтернативно, Вы можете остановить только ведомый поток SQL: shell> mysql -e 'STOP SLAVE SQL_THREAD;' Это позволяет ведомому устройству продолжить получать события изменения данных от двоичного журнала ведущего устройства, регистрирует и хранит их в журналах реле, используя поток ввода/вывода, но препятствует тому, чтобы ведомое устройство запустило эти события и изменило данные. В пределах занятой окружающей среды репликации, разрешение потоку ввода/вывода работать во время резервного копирования может ускорить процесс, когда Вы перезапускаете ведомый поток SQL. Выполните mysqldump , чтобы вывести Ваши базы данных в дамп. Вы можете вывести все базы данных или выбрать базы данных, которые будут выведены. Например, чтобы вывести все базы данных: shell> mysqldump --all-databases > fulldb.dump Как только дамп завершился, запустите ведомые операции снова: shell> mysqladmin start-slave В предыдущем примере Вы можете хотеть добавить параметры входа в систему (имя пользователя, пароль) к командам и связать процесс в скрипт, который Вы можете выполнять автоматически каждый день. Если Вы используете этот подход, удостоверьтесь, что Вы контролируете ведомый процесс репликации, чтобы гарантировать, что время, потраченное, чтобы выполнить резервное копирование, не затрагивает способность ведомого устройства не отставать от событий от ведущего устройства. См. раздел 19.1.7.1. Если ведомое устройство неспособно поддержать производительность на высоком уровне, Вы можете хотеть добавить другое ведомое устройство и распределить резервный процесс. Для примера того, как сконфигурировать этот сценарий, см. раздел 19.3.6. 19.3.1.2. Поддержка необработанных данных от ведомого устройства Чтобы гарантировать целостность файлов, которые скопированы, поддерживая файлы необработанных данных на Вашем ведомом устройстве репликации MySQL, это должно иметь место в то время, как Ваш ведомый сервер закрыт. Если сервер MySQL все еще работает, фоновые задачи могут все еще обновлять файлы базы данных, особенно те, которые вовлекают механизмы хранения с фоновыми процессами, например, InnoDB. С InnoDB эти проблемы должны быть решены во время восстановления катастрофического отказа, но так как ведомый сервер может быть закрыт во время резервного процесса, не затрагивая выполнение ведущего устройства, имеет смысл использовать в своих интересах эту способность. Закрыть сервер и зарезервировать файлы: Закройте ведомый сервер MySQL: shell> mysqladmin shutdown Скопируйте файлы с данными. Вы можете использовать любое подходящее копирование, включая cp, tar или WinZip. Например, предполагая, что каталог данных расположен под текущим каталогом, Вы можете заархивировать весь каталог следующим образом: shell> tar cf /tmp/dbbackup.tar ./data Запустите сервер 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, чтобы изменить статус "только для чтения" сервера, который будет сохранен: Сделайте сервер только для чтения, так, чтобы он обработал только извлечения и заблокировал обновления. Выполните резервное копирование. Измените сервер назад на его нормальный статус чтения-записи. Инструкции в этом разделе помещают сервер, который будет поддержан, в статус, который безопасен для резервных методов, которые получают данные от сервера, таких как mysqldump (см. раздел 5.5.4). Вы не должны пытаться использовать эти инструкции, чтобы сделать двоичное резервное копирование, копируя файлы непосредственно, потому что сервер, возможно, все еще изменяет данные, кэшируемые в памяти, и не сбросил их на диск. Следующие инструкции описывают, как сделать это для главного сервера и для ведомого сервера. Для обоих сценариев, обсужденных здесь, предположите, что у Вас есть следующая установка репликации: Главный сервер M1. Ведомый сервер S1, у которого есть M1 как его ведущее устройство. Клиент К1 соединяется с M1. Клиент К2 соединяется с S1. В любом сценарии, запросы, чтобы приобрести глобальную блокировку чтения и управлять переменной read_only выполнены на сервере, который будет поддержан, и не размножаются ни к каким ведомым устройствам того сервера. Сценарий 1: Резервное копирование с ведущим устройством только для чтения Поместите ведущее устройство М1 в статус только для чтения, выполняя эти запросы: mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON; В то время как M1 находится в состоянии только для чтения, следующие свойства истина: Запросы об обновлениях, посланные C1 в M1, заблокируют, потому что сервер находится в режиме только для чтения. Запросы о результатах запроса, посланные C1 в M1, преуспеют. Создание резервного копирования на M1 безопасно. Создание резервного копирования на S1 не безопасно. Этот сервер все еще работает и мог бы обрабатывать двоичный журнал или обновления, прибывающие от клиента К2. В то время как 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 находится в состоянии только для чтения, следующие свойства истина: Ведущее устройство М1 продолжит действовать, так что создание резервного копирования на ведущем устройстве не безопасно. Ведомый S1 остановлен, таким образом делая резервное копирование на ведомом 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 Нет Остается Поскольку таблица показывает, используя однопоточное ведомое устройство, следующие конфигурации наиболее эластичны к неожиданным остановам: Используя GTID и MASTER_AUTO_POSITION, установите relay_log_recovery=0 . С этой конфигурацией установка relay_log_info_repository и другие переменные не воздействуют на восстановление. Когда используется репликацуя на основе позиции файла, установите relay_log_recovery=1 и relay_log_info_repository=TABLE. Во время восстановления потерян журнал реле. Следующая таблица показывает воздействие этих различных факторов на то, как мультипоточное ведомое устройство восстанавливается от неожиданного останова. Таблица 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 Нет Остается Как таблица показывает, используя мультипоточное ведомое устройство, следующие конфигурации наиболее эластичны к неожиданным остановам: Используя GTID и MASTER_AUTO_POSITION, установите relay_log_recovery=0 . С этой конфигурацией установка relay_log_info_repository и другие переменные не воздействуют на восстановление. Когда используется позиция файла, установите relay_log_recovery=1 , sync_relay_log=1 и relay_log_info_repository=TABLE. Во время восстановления потерян журнал реле. Важно отметить воздействие 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): Включите три этапа Performance Schema: mysql> UPDATE performance_schema.setup_instruments SET ENABLED = 'YES' -> WHERE NAME LIKE 'stage/sql/Applying batch of row changes%'; Ждите некоторых событий, которые будут обработаны репликацией и затем проверяйте продвижение, изучая таблицу events_stages_current. Например получить продвижение для событий update: mysql> SELECT WORK_COMPLETED, WORK_ESTIMATED FROM performance_schema.events_stages_current -> WHERE EVENT_NAME LIKE 'stage/sql/Applying batch of row changes (update)' Если binlog_rows_query_log_events включена, информация о запросах хранится в двоичном журнале и выставлена в поле processlist_info . Чтобы увидеть оригинальный запрос, который вызвал это событие: mysql> SELECT db, processlist_state, processlist_info FROM performance_schema.threads -> WHERE processlist_state LIKE 'stage/sql/Applying batch of row changes%' AND thread_id = N; 19.3.4. Используя репликацию с различными основными и ведомыми механизмами хранения Не имеет значения для процесса репликации, используют ли исходная таблица на ведущем устройстве и копируемая таблица на ведомом различный механизм. Фактически переменная default_storage_engine не копируется. Это обеспечивает много выгод в процессе репликации, в котором Вы можете использовать в своих интересах различные типы механизма для различных сценариев репликации. Например, в типичном сценарии масштаба (см. раздел 19.3.5) Вы хотите использовать InnoDB на ведущем устройстве, чтобы использовать в своих интересах транзакционную функциональность, но MyISAM на ведомых устройствах, где операционная поддержка не требуется, потому что данные только считаны. Используя репликацию в регистрирующей данные окружающей среде, Вы можете хотеть использовать на ведомом устройстве Archive. Конфигурирование различных механизмов на ведущем устройстве и ведомом устройстве зависит от того, как Вы настраиваете начальный процесс репликации: Если бы Вы использовали mysqldump, чтобы создать снимок базы данных на Вашем ведущем устройстве, то Вы могли бы отредактировать текст файла дампа, чтобы изменить тип механизма, используемый на каждой таблице. Другая альтернатива для mysqldump должна отключить типы механизма, которые Вы не хотите использовать на ведомом устройстве перед использованием дампа, чтобы создать данные по ведомому устройству. Например, Вы можете добавить опцию --skip-federated на Вашем ведомом устройстве, чтобы отключить механизм FEDERATED. Если определенный механизм не будет существовать для таблицы, которая будет создаваться, то MySQL будет использовать тип механизма по умолчанию, обычно MyISAM. Это требует отключения SQL-режима NO_ENGINE_SUBSTITUTION. Если Вы хотите отключить дополнительные механизмы таким образом, Вы можете хотеть создать специальный исполняемый модуль, который используется на ведомом устройстве, которое поддерживает только нужные механизмы. Если Вы будете использовать файлы необработанных данных (двоичное резервное копирование), чтобы настроить ведомое устройство, то Вы не будете способны изменить начальный формат таблицы. Вместо этого используйте ALTER TABLE, чтобы изменить табличные типы после того, как ведомое устройство было запущено. Для новых основных/ведомых установок репликации, где в настоящее время нет никаких таблиц на ведущем устройстве, избегайте определять тип механизма, составляя новые таблицы. Если Вы уже выполняете решение для репликации и хотите преобразовать Ваши существующие таблицы в другой тип механизма, надо следовать этим шагам: Запретите ведомому устройству выполнить обновления репликации: mysql> STOP SLAVE; Это позволит Вам изменить типы механизма без прерываний. Выполните ALTER TABLE ... ENGINE='engine_type ' для каждой таблицы, которая будет изменена. Запустите ведомый процесс репликации снова: 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_writer_connect() safe_reader_connect() safe_reader_statement() safe_writer_statement() safe_ в каждом имени функции говорит, что функция заботится об обработке всех состояний ошибки. Вы можете использовать различные названия функций. Важная вещь состоит в том, чтобы иметь объединенный интерфейс для того, чтобы соединиться для чтений и записей. Тогда преобразуйте свой код клиента, чтобы пользоваться библиотекой обертки. Это может быть болезненным и страшным процессом сначала, но это окупается в конечном счете. Все приложения, которые используют только что описанный подход, в состоянии использовать в своих интересах основную/ведомую конфигурацию, даже вовлекающие многократные ведомые устройства. Код намного легче поддержать, поиск неисправностей тривиален. Вы должны изменить только одну или две функции, например, чтобы зарегистрировать, сколько времени каждый запрос взял, или какой запрос среди выпущенных дал Вам ошибку. Если Вы написали много кода, Вы можете хотеть автоматизировать конверсионную задачу при использовании утилиты replace, которая идет со стандартными пакетами MySQL, или напишите свой собственный конверсионный скрипт. Идеально, если Ваш код использует последовательные программные соглашения стиля. 19.3.6. Мультиплицирование различных баз данных к различным ведомым устройствам Могут быть ситуации, где Вы имеете единственное ведущее устройство и хотите копировать различные базы данных к различным ведомым устройствам. Например, Вы можете хотеть распределить различные данные о сбыте различным отделам, чтобы помочь распространить загрузку во время анализа данных. Образец этого расположения показывают на рис. 19.2. Рис. 19.2. Использование репликации, чтобы копировать базы данных, чтобы отделить ведомые устройства репликации Вы можете достигнуть этого разделения, конфигурируя ведущее устройство и ведомые устройства как обычно, затем ограничивая двоичные запросы журнала, которые каждое ведомое устройство обрабатывает при использовании --replicate-wild-do-table на каждом ведомом устройстве. Вы не должны использовать --replicate-do-db с этой целью, используя основанную на запросе репликацию, так как основанная на запросе репликация заставляет эффекты этой опции изменяться согласно базе данных, которая в настоящее время выбирается. Это относится к репликации смешанного формата также, так как это позволяет некоторым обновлениям копироваться, используя основанный на запросе формат. Однако, должно быть безопасно использовать --replicate-do-db с этой целью, если Вы используете только основанную на строке репликацию, так как в этом случае в настоящее время выбираемая база данных не имеет никакого влияния на работу опции. Например, чтобы поддержать разделение как показано на рис. 19.2, Вы должны сконфигурировать каждое ведомое устройство репликации следующим образом, перед выполнением START SLAVE : Ведомое устройство репликации 1 должно использовать --replicate-wild-do-table=databaseA.%. Ведомое устройство репликации 2 должно использовать --replicate-wild-do-table=databaseB.%. Ведомое устройство репликации 3 должно использовать --replicate-wild-do-table=databaseC.%. Каждое ведомое устройство в этой конфигурации получает весь двоичный журнал от ведущего устройства, но запускает только те события, которые относятся к базам данных и таблицам, включенным на том ведомом устройстве опцией --replicate-wild-do-table. Если у Вас есть данные, которые должны быть синхронизированы к ведомым устройствам прежде, чем репликация запустится, у Вас есть выбор: Синхронизируйте все данные к каждому ведомому устройству и удалите базы данных, таблицы, все, что Вы не хотите сохранять. Используйте mysqldump , чтобы создать отдельный файл дампа для каждой базы данных и загрузить соответствующий файл дампа на каждом ведомом устройстве. Используйте дамп файла необработанных данных и включите только определенные файлы и базы данных, в которых Вы нуждаетесь для каждого ведомого устройства. Это не работает с InnoDB, если Вы не используете innodb_file_per_table. 19.3.7. Улучшение работы репликации Поскольку число ведомых устройств, соединяющихся с ведущим устройством, увеличивается, загрузка, хотя и минимально, также увеличивается, поскольку каждое ведомое устройство использует соединение клиента с ведущим устройством. Кроме того, поскольку каждое ведомое устройство должно получить полную копию основного двоичного журнала, сетевая загрузка на ведущем устройстве может также увеличить и создать узкое место. Если Вы используете большое количество ведомых устройств, соединенных с одним ведущим устройством, и ведущее устройство также занято, обрабатывая запросы (например, как часть решения масштаба), то Вы можете хотеть улучшить исполнение процесса репликации. Один способ улучшить исполнение процесса репликации состоит в том, чтобы создать более глубокую структуру репликации, которая позволяет ведущему устройству копировать только к одному ведомому устройству, а остающиеся ведомые устройства должны соединиться с этим основным ведомым устройством для их отдельных требований репликации. Образец этой структуры показывают на рис. 19.3. Рис. 19.3. Использование дополнительного узла репликации, чтобы улучшить работу Вы должны сконфигурировать экземпляры MySQL следующим образом: Ведущее устройство 1 является основным ведущим устройством, где все изменения и обновления написаны в базу данных. Двоичное журналирование должно быть включено на этой машине. Ведущее устройство 2 является ведомым устройством ведущего устройства 1, которое обеспечивает функциональность репликации ведомым устройствам в структуре репликации. Ведущее устройство 2 является единственной машиной, которой разрешено соединяться с ведущим устройством 1. Ведущему устройству 2 также надо включить двоичное журналирование и опцию --log-slave-updates, чтобы инструкции репликации от ведущего устройства 1 были также написаны ведущему устройству 2 в двоичный журнал так, чтобы они могли оттуда копироваться истинно ведомым устройствам. Ведомые устройства 1, 2 и 3 работают как ведомые устройства ведущего устройства 2 и копируют информацию от ведущего устройства 2, которая фактически состоит из обновлений с ведущего устройства 1. Вышеупомянутое решение уменьшает загрузку клиента и сетевого интерфейса на основном ведущем устройстве, что должно улучшить эффективность работы основного ведущего устройства, когда используется в качестве прямого решения для базы данных. Если Ваши ведомые устройства испытывают затруднения, отставая от процесса репликации на ведущем устройстве, есть много доступных опций: Если возможно, поместите журналы реле и файлы с данными на различных физических дисках. Чтобы сделать это, используйте опцию --relay-log, чтобы определить местоположение журнала реле. Если ведомые устройства значительно медленнее, чем ведущее устройство, Вы можете хотеть разделить работу по мультиплицированию различных баз данных различным ведомым устройствам. См. раздел 19.3.6. Если Ваше ведущее устройство использует транзакции, и Вы не обеспокоены операционной поддержкой на Ваших ведомых устройствах, используйте MyISAM или другой нетранзакционной механизм на ведомых устройствах. См. раздел 19.3.4. Если Ваши ведомые устройства не действуют как ведущие устройства, и у Вас есть потенциальное решение, чтобы гарантировать, что Вы можете восстановить ведущее устройство в случае отказа, то Вы можете выключить --log-slave-updates. Это защищает ведомые устройства от журналирования событий, которые они запустили, в их собственный двоичный журнал. 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 Пути к файлам могут быть относительными или абсолютными, мы рекомендуем, чтобы Вы всегда использовали полные пути. Опции здесь следующие: ssl-ca сертификат Certificate Authority (CA). ssl-cert сертификат открытого ключа сервера. Это можно послать клиенту и заверено сертификатом CA. ssl-key частный ключ сервера. На ведомом устройстве есть два способа определить информацию, запрошенную для того, чтобы соединиться надежно с ведущим устройством. Вы можете назвать ведомый сертификат и ключевые файлы в разделе [client] файла my.cnf ведомого устройства или Вы можете явно определить ту информацию, используя CHANGE MASTER TO: Чтобы назвать ведомый сертификат и ключевые файлы, используя файл опции, добавьте следующие строки к разделу [client] файла my.cnf ведомого устройства, изменяя имена файлов по мере необходимости: [client] ssl-ca=cacert.pem ssl-cert=client-cert.pem ssl-key=client-key.pem Перезапустите ведомый сервер, используя опцию --skip-slave-start, чтобы препятствовать тому, чтобы ведомое устройство соединилось с ведущим устройством. Используйте CHANGE MASTER TO, чтобы определить основную конфигурацию, используя опцию MASTER_SSL, чтобы соединиться надежно: mysql> CHANGE MASTER TO MASTER_HOST='master_hostname', -> MASTER_USER='replicate', -> MASTER_PASSWORD='password', MASTER_SSL=1; Чтобы определить сертификат и ключевые имена, используя CHANGE MASTER TO, приложите соответствующие опции MASTER_SSL_xxx : mysql> CHANGE MASTER TO MASTER_HOST='master_hostname', -> MASTER_USER='replicate', MASTER_PASSWORD='password', -> MASTER_SSL=1, MASTER_SSL_CA = 'ca_file_name', -> MASTER_SSL_CAPATH = 'ca_directory_name', -> MASTER_SSL_CERT = 'cert_file_name', -> MASTER_SSL_KEY = 'key_file_name'; После того, как основная информация была обновлена, запустите ведомый процесс репликации: 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управляет пунктом, в котором полусинхронное ведущее устройство репликации ждет ведомого признания прежде, чем возвратить состояние клиенту, который передал транзакцию. Эти значения разрешены: AFTER_SYNC (по умолчанию): ведущее устройство пишет каждую транзакцию своему двоичному журналу и ведомому устройству и синхронизирует двоичный журнал с диском. Ведущее устройство ждет от ведомого признания после синхронизации. После получения признания ведущее устройство передает транзакцию механизму хранения и возвращает результат клиенту, который тогда может продолжить работу. AFTER_COMMIT: Ведущее устройство пишет каждую транзакцию в свой двоичный журнал и ведомому устройству, синхронизирует двоичной журнал и передает транзакцию механизму хранения. Ведущее устройство ждет от ведомого признания после передачи. После получения признания ведущее устройство возвращает результат клиенту, который тогда может продолжить работу. Характеристики репликации этих настроек отличаются следующим образом: С AFTER_SYNC все клиенты видят переданную транзакцию в то же самое время: после того, как это было признано ведомым устройством и передано механизму хранения на ведущем устройстве. Таким образом, все клиенты видят те же самые данные по ведущему устройству. В случае основного отказа все транзакции, переданные на ведущем устройстве, скопировались к ведомому устройству (сохранены в его журнале реле). Катастрофический отказ ведущего устройства и переход к ведомому устройству будут без потерь, потому что ведомое устройство современно. С AFTER_COMMIT клиент, выпускающий транзакцию, получает статус возврата только после того, как сервер передает механизму хранения и получает ведомое признание. После передачи и перед ведомым признанием, другие клиенты могут видеть переданную транзакцию перед commit клиента. Если что-то идет не так, как надо, таким образом, что ведомое устройство не обрабатывает транзакцию, то в случае основного катастрофического отказа и перехода к ведомому устройству, возможно, что такие клиенты будут видеть потерю данных относительно того, что они видели на ведущем устройстве. 19.3.10.1. Административный интерфейс полусинхронной репликации У административного интерфейса к полусинхронной репликации есть несколько компонентов: Два плагина осуществляют полусинхронную способность. Есть один плагин для основной стороны и один для ведомой стороны. Системные переменные управляют логикой плагина: rpl_semi_sync_master_enabled Средство управления, включена ли полусинхронная репликация на ведущем устройстве. Чтобы включить или отключить плагин, установите эту переменную в 1 или 0, соответственно. Значение по умолчанию 0 (off). rpl_semi_sync_master_timeout Значение в миллисекундах, которое управляет, сколько времени ведущее устройство ждет при передаче признания от ведомого устройства перед синхронизацией и возвратом к асинхронной репликации. Значение по умолчанию 10000 (10 секунд). rpl_semi_sync_slave_enabled Аналогично rpl_semi_sync_master_enabled, но управляет ведомым плагином. Все переменные rpl_semi_sync_xxx рассмотрены в разделе 6.1.5. Переменные состояния включают контроль полусинхронной репликации. Некоторые примеры: Rpl_semi_sync_master_clients Число полусинхронных ведомых устройств. Rpl_semi_sync_master_status Является ли полусинхронная репликация в настоящее время работающей на ведущем устройстве. Значение 1, если плагин был включен, и передача признания не произошла. Это 0, если плагин не включен, или ведущее устройство отступило к асинхронной репликации. Rpl_semi_sync_master_no_tx Число передач, которые не были признаны успешно ведомым устройством. Rpl_semi_sync_master_yes_tx Число передач, которые были признаны успешно ведомым устройством. Rpl_semi_sync_slave_status Является ли полусинхронная репликация в настоящее время рабочей на ведомом устройстве. Это 1, если плагин был включен, и ведомый поток ввода/вывода работает, 0 иначе. Все переменные Rpl_semi_sync_xxx рассмотрены в разделе 6.1.7. Переменные состояния доступны, только если соответствующий основной или ведомый плагин был установлен с INSTALL PLUGIN. 19.3.10.2. Полусинхронная репликация: установка и конфигурация Полусинхронная репликация осуществлена, используя плагины, таким образом, плагины должны быть установлены в сервер, чтобы сделать их доступными. После того, как плагин был установлен, Вы управляете им посредством системных переменных, связанных с ним. Эти системные переменные недоступны, пока связанный плагин не был установлен. Этот раздел описывает, как установить полусинхронные плагины репликации. Для общей информации об установке плагинов см. раздел 6.6.2. Чтобы использовать полусинхронную репликацию, следующие требования должны быть удовлетворены: MySQL 5.5 или выше. Способность установки плагинов требует сервера MySQL, который поддерживает динамическую загрузку. Чтобы проверить это, проверьте что значение have_dynamic_loading = YES. Двоичные дистрибутивы должны поддерживать динамическую загрузку. Репликация должна уже работать, см. раздел 19.1. Не должно быть многократных сконфигурированных каналов репликации. Полусинхронная репликация совместима только с каналом репликации по умолчанию. См. раздел 19.2.3. Чтобы настроить полусинхронную репликацию, используйте следующие инструкции. 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. Отсроченная репликация может использоваться в нескольких целях: Защищать от ошибок пользователя на ведущем устройстве. DBA может откатить отсроченное ведомое устройство до прежнего уровня времени. Проверить, как система ведет себя, когда есть задержка. Например, в приложении задержка могла бы быть вызвана тяжелой задачей на ведомом устройстве. Однако, может быть трудно воспроизвести этот уровень загрузки. Отсроченная репликация может моделировать задержку, не имея необходимости моделировать нагрузку. Это может также использоваться, чтобы отладить условия, связанные с отстающим ведомым устройством. Осмотреть, на что база данных была похожа давно, не имея необходимости перезагружать резервное копирование. Например, если задержка одна неделя, и DBA должен видеть то, на что была похожа база данных прежде, отсроченное ведомое устройство может быть осмотрено. START SLAVE и STOP SLAVE вступают в силу немедленно и проигнорируют любую задержку. RESET SLAVE сбрасывает задержку к 0. SHOW SLAVE STATUS имеет три области, которые предоставляют информацию о задержке: SQL_Delay: Неотрицательное целое число, указывающее на число секунд, на которое ведомое устройство должно изолировать ведущее устройство. SQL_Remaining_Delay: Когда Slave_SQL_Running_State = Waiting until MASTER_DELAY seconds after master executed event, эта область содержит целое число, указывающее на число секунд, оставшейся задержки. В других случаях эта область NULL. Slave_SQL_Running_State: Строка, указывающая на статус потока SQL (аналог Slave_IO_State). Значение идентично State потока SQL как выведено на экран SHOW PROCESSLIST. Когда ведомый поток 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 сделаны правильно согласно следующим исключениям: Запрос, вызывающий триггер или функцию, которая вызывает обновление AUTO_INCREMENT не копируется правильно, используя основанную на запросе репликацию. В MySQL 8.0 такие запросы отмечены как опасные (Bug #45677). INSERT в таблицу, у которой есть сложный первичный ключ, который включает столбец AUTO_INCREMENT, который не является первым столбцом этого сложного ключа, не безопасен для основанного на запросе журналирования или репликации. В MySQL 8.0 и позже такие запросы отмечены как опасные (Bug #11754117, Bug #45670). Эта проблема не затрагивает таблицы, используя InnoDB со столбцом AUTO_INCREMENT требует по крайней мере одного ключа, где столбец auto-increment единственный или крайний левый столбец. Добавление AUTO_INCREMENT к таблице с ALTER TABLE не мог бы произвести то же самое упорядочивание строк на ведомом и ведущем устройствах. Это происходит, потому что порядок, в котором пронумерованы строки, зависит от определенного механизма хранения, используемого для таблицы и порядка, в который были вставлены строки. Если важно иметь тот же самый порядок, строки должны быть упорядочены прежде, чем назначить AUTO_INCREMENT. Допустим, что Вы хотите добавить AUTO_INCREMENT в таблицу t1, у которой есть столбцы col1 и col2, следующие запросы производят новую таблицу t2 идентичную t1, но со столбцом AUTO_INCREMENT: CREATE TABLE t2 LIKE t1; ALTER TABLE t2 ADD id INT AUTO_INCREMENT PRIMARY KEY; INSERT INTO t2 SELECT * FROM t1 ORDER BY col1, col2; Чтобы гарантировать то же самое упорядочивание, ORDER BY должен назвать все столбцы t1. Эти инструкции подвергаются ограничениям CREATE TABLE ... LIKE: определения внешнего ключа проигнорированы, как и опции DATA DIRECTORY и INDEX DIRECTORY. Если табличное определение включает какую-либо из тех характеристик, надо создать t2 через CREATE TABLE, который идентичен тому, которым создали t1, но с добавкой столбца AUTO_INCREMENT. Независимо от метода, используемого, чтобы создать и заполнить копию, имеющую столбец AUTO_INCREMENT, заключительный шаг должен удалить оригинальную таблицу и затем переименовать копию: DROP t1; ALTER TABLE t2 RENAME t1; См. раздел B.5.6.1. 19.4.1.2. Репликация и таблицы BLACKHOLE BLACKHOLE принимает данные, но отказывается от них и не хранит их. Выполняя двоичное журналирование, все вставки к таким таблицам, всегда регистрируются, независимо от формата журналирования. Обновления и удаления обработаны по-другому в зависимости от того, какой формат журналирования применен. С форматом регистрации запросов все воздействие на таблицу BLACKHOLE зарегистрировано, но эффекты проигнорированы. Когда используется основанное на строке журналирование, обновления и удаления к таким таблицам просто пропущены, они не написаны в двоичный журнал. Предупреждение зарегистрировано всякий раз, когда это происходит. По этой причине мы рекомендуем, когда Вы копируете к таблицам, используя BLACKHOLE, установить binlog_format в STATEMENT, а не ROW или MIXED. 19.4.1.3. Репликация и наборы символов Следующее относится к репликации между серверами MySQL, которые используют различные наборы символов: Если у ведущего устройства есть базы данных с набором символов, отличающимся от глобального character_set_server, Вы должны разработать Ваши CREATE TABLE так, чтобы они неявно не положились на набор символов по умолчанию базы данных. Хорошее обходное решение должно заявить набор символов и сопоставление явно в CREATE TABLE . 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: Каждый CREATE DATABASE IF NOT EXISTS копируется безотносительно того, существует ли база данных уже на ведущем устройстве. Точно так же каждый CREATE TABLE IF NOT EXISTS без SELECT копируется, существует ли таблица уже на ведущем устройстве. Это включает CREATE TABLE IF NOT EXISTS ... LIKE . Репликация CREATE TABLE IF NOT EXISTS ... SELECT следует несколько иным правилам, см. раздел 19.4.1.6 . CREATE EVENT IF NOT EXISTS всегда копируется в MySQL 8.0, неважно, существует ли событие, названное в запросе, на ведущем устройстве. См. также 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: CREATE TABLE ... SELECT всегда неявно передает (раздел 14.3.3). Если целевая таблица не существует, журналирование происходит следующим образом. Не имеет значения IF NOT EXISTS. STATEMENT или MIXED: запрос зарегистрирован как написан. ROW: запрос зарегистрирован как CREATE TABLE с серией событий вставки строк. Если запрос терпит неудачу, ничто не зарегистрировано. Это включает случай, что целевая таблица существует и нет IF NOT EXISTS. Когда целевая таблица существует и задано 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() расширен как и где необходимо: DROP USER RENAME USER GRANT REVOKE CREATE FUNCTION CREATE PROCEDURE CREATE TRIGGER CREATE EVENT CREATE VIEW ALTER EVENT ALTER VIEW SET PASSWORD Когда 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. Репликация с большим количеством столбцов на ведущем или ведомом устройстве Вы можете копировать таблицу от ведущего устройства к ведомому таким образом, что у основных и ведомых копий таблицы есть отличающееся число столбцов согласно следующим условиям: Столбцы, характерные для обеих версий таблицы, должны быть определены в том же самом порядке на ведущем и ведомом устройствах. Это истина, даже если у обеих таблиц есть то же самое число столбцов. Столбцы, характерные для обеих версий таблицы, должны быть определены перед любыми дополнительными столбцами. Это означает, что выполнение ALTER TABLE на ведомом устройстве, где новый столбец вставлен в таблицу в пределах диапазона столбцов, характерных для обеих таблиц, заставляет репликацию терпеть неудачу, как показано в следующем примере: Допустим, что таблица t на ведущем и ведомом устройствах определена следующим запросом CREATE TABLE: CREATE TABLE t (c1 INT, c2 INT, c3 INT); Допустим, что ALTER TABLE, показанный здесь, выполнен на ведомом устройстве: ALTER TABLE t ADD COLUMN cnew1 INT AFTER c3; Предыдущий ALTER TABLE разрешен на ведомом устройстве, потому что столбцы c1, c2 и c3 характерны для обеих версий таблицы t и останутся сгруппированными в обеих версиях таблицы перед любыми столбцами, которые отличаются. Однако, следующий ALTER TABLE не может быть выполнен на ведомом устройстве, не заставляя репликацию сломаться: ALTER TABLE t ADD COLUMN cnew2 INT AFTER c2; Репликация терпит неудачу после выполнения на ведомом устройстве ALTER TABLE, потому что новый столбец cnew2 между столбцами, характерными для обеих версий t. У каждого столбца extra в версии таблицы, имеющей больше столбцов, должно быть значение по умолчанию. Значение по умолчанию столбца определено многими факторами, включая его тип, определен ли он с DEFAULT, объявлено ли это как NULL и серверный режим SQL во время его создания, для получения дополнительной информации см. раздел 12.7. Кроме того, когда у копии ведомого устройства таблицы есть больше столбцов, чем у копии ведущего устройства, каждый столбец, характерный для таблиц, должен использовать тот же самый тип данных в обеих таблицах. Примеры. Следующие примеры иллюстрируют некоторые допустимые и недопустимые табличные определения: Больше столбцов на ведущем устройстве. Следующие табличные определения допустимы и скопируются правильно: 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. Поддержанные преобразования. Поддержанные преобразования между различными но подобными типами данных показывают в следующем списке: Между любым из типов целого числа TINYINT, SMALLINT, MEDIUMINT, INT и BIGINT. Это включает преобразования между версиями со знаком и без знака этих типов. Преобразования с потерями сделаны, усекая исходное значение к максимуму (или минимуму), разрешенному целевым столбцом. Для того, чтобы гарантировать преобразования не с потерями, переходя от значения без знака к типу со знаком, целевой столбец должен быть достаточно большим, чтобы приспособить диапазон значений в исходном столбце. Например, Вы можете конвертировать TINYINT UNSIGNED не с потерями к SMALLINT, но не к TINYINT. Между любым из десятичных типов DECIMAL, FLOAT, DOUBLE и NUMERIC. FLOAT в DOUBLE конвертируется без потерь, DOUBLE в FLOATможет быть обработано только с потерями. Преобразование от DECIMAL(M,D) в DECIMAL(M',D'), где D' >= D и (M'-D') >= (M-D) без потерь, для любого случая, где M' < M, D' < D или оба только преобразование с потерями может быть сделано. Для любого из десятичных типов, если значение, которое будет сохранено, не может поместиться в целевой тип, значение округлено в меньшую сторону согласно правилам, определенным для сервера в другом месте в документации. См. раздел 13.20.4. Между любым из строковых типов CHAR, VARCHAR и TEXT, включая преобразования между различными ширинами. Конвертация CHAR, VARCHAR или TEXT в CHAR, VARCHAR или TEXT того же самого размера или больше никогда не делается с потерями. Преобразование с потерями обработано, вставляя только первые N символов строки на ведомом устройстве, где N это ширина целевого столбца. Репликация между столбцами, используя различные наборы символов не поддержана. Между любым из типов двоичных данных BINARY, VARBINARY и BLOB, включая преобразования между различными ширинами. Конвертация BINARY, VARBINARY или BLOB в BINARY, VARBINARY или BLOB того же самого размера или больше никогда не делается с потерями. Преобразование с потерями обработано, вставляя только первые N байт строки на ведомом устройстве, где N это ширина целевого столбца. Между любыми 2 столбцами BIT любых 2 размеров. Вставляя значение от BIT(M) в BIT(M'), где M' > M, старшие значащие биты BIT(M') столбцы очищены (установлены к нолю) и M бит из BIT(M) установлены как младшие значащие биты столбца BIT(M'). Вставляя значение из BIT(M) в BIT(M'), где M' < M, максимальное возможное значение для BIT(M') назначено, другими словами, значение all-set назначено на целевой столбец. Преобразования между типами не в предыдущем списке не разрешены. 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) и сохраненные программы (хранимые процедуры и функции, триггеры и события) обеспечивает следующие характеристики: Эффекты особенности всегда копируются. Следующие запросы копируются, используя основанную на запросе репликацию: CREATE EVENT ALTER EVENT DROP EVENT CREATE PROCEDURE DROP PROCEDURE CREATE FUNCTION DROP FUNCTION CREATE TRIGGER DROP TRIGGER Однако, эффекты особенностей с использованием этих запросов копируются, используя основанную на строке репликацию. Попытка копировать особенности, используя основанную на запросе репликацию производит предупрждение Statement is not safe to log in statement format. Например, попытка копировать UDF с основанной на запросе репликацией производит это предупреждение, потому что в настоящее время не может определяться сервером MySQL, детерминирован ли UDF. Если Вы абсолютно уверены, что эффекты особенности детерминированы, Вы можете безопасно игнорировать такие предупреждения. В случае CREATE EVENT и ALTER EVENT: Состояние события установлено в SLAVESIDE_DISABLED на ведомом устройстве независимо от определенного состояния (это не относится к DROP EVENT). Ведущее устройство, на котором создавалось событие, идентифицировано на ведомом устройстве по его ID сервера. Столбец ORIGINATOR в INFORMATION_SCHEMA.EVENTS и столбец originator в mysql.event хранят эту информацию. См. разделы 22.7 и 14.7.5.18. Выполнение особенности находится на ведомом устройстве в возобновимом состоянии, чтобы, если ведущее устройство терпит неудачу, ведомое устройство могло использоваться в качестве ведущего без потери обработки событий. Определить, есть ли какие-либо запланированные события на сервере 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 и ранее), которое этого не делает: Для CREATE TABLE, содержащих столбцы, которые имеют значение fsp (fractional seconds precision) больше 0, репликация потерпит неудачу из-за ошибок анализатора. Запросы, которые используют временные типы данных с fsp = 0, будут работать с основанным на запросе журналированием, но не с основанным на строке журналированием. В последнем случае типы данных имеют двоичные форматы и их коды ведущего устройства отличаются от кодов в ведомом устройстве. Некоторые результаты выражения разойдутся в ведущем и ведомом устройствах. Примеры: на ведущем устройстве системная переменная timestamp возвращает значение, которое включает дробную часть микросекунд, на ведомом устройстве это возвращает целое число. На ведущем устройстве функции, которые возвращают результат, который включает текущее время (например, CURTIME(), SYSDATE() или UTC_TIMESTAMP()) интерпретируют параметр как fsp и возвращаемое значение включают дробную часть секунд. На ведомом устройстве эти функции разрешают параметр, но игнорируют его. 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. Репликация и системные функции Определенные функции не копируются хорошо при некоторых условиях: USER(), CURRENT_USER() (или CURRENT_USER ), UUID(), VERSION() и LOAD_FILE() копируются без изменения и таким образом не работают достоверно с ведомым устройством, если основанная на строке репликация не включена. См. раздел 19.2.1. USER() и CURRENT_USER() автоматически копируются, используя основанную на строке репликацию, используя режим MIXED и производят предупреждение в режиме STATEMENT (см. раздел 19.4.1.8). Это также истина для VERSION() и RAND(). Для NOW() двоичный журнал включает timestamp. Это означает, что значение, возвращенное вызовом этой функции на ведущем устройстве , копируется к ведомому устройству. Чтобы избежать неожиданных результатов, копируя между серверами MySQL в различных часовых поясах, установите часовой пояс на ведущем устройстве и на ведомом устройстве. См. также раздел 19.4.1.32 . Чтобы объяснить потенциальные проблемы, копируя между серверами, которые находятся в различных часовых поясах, предположите, что ведущее устройство расположено в Нью-Йорке, ведомое устройство расположено в Стокгольме, и оба сервера используют местное время. Предположите далее, что на ведущем устройстве Вы составляете таблицу mytable, выполняете INSERT на ней, а затем выбираете из таблицы, как показано здесь: mysql> CREATE TABLE mytable (mycol TEXT); Query OK, 0 rows affected (0.06 sec) mysql> INSERT INTO mytable VALUES (NOW()); Query OK, 1 row affected (0.00 sec) mysql> SELECT * FROM mytable; +---------------------+ | mycol | +---------------------+ | 2009-09-01 12:00:00 | +---------------------+ 1 row in set (0.00 sec) Местное время в Стокгольме на 6 часов позже чем в Нью-Йорке, если Вы выполните SELECT NOW() на ведомом устройстве в этот же самый момент, значение будет 2009-09-01 18:00:00. Поэтому, если Вы выбираете из копии ведомого устройства mytable после копирования CREATE TABLE и INSERT, Вы могли бы ожидать, что mycol содержит значение 2009-09-01 18:00:00. Однако, дело обстоит не так: когда Вы выбираете из копии ведомого устройства mytable, Вы получаете точно тот же самый результат как на ведущем устройстве: mysql> SELECT * FROM mytable; +---------------------+ | mycol | +---------------------+ | 2009-09-01 12:00:00 | +---------------------+ 1 row in set (0.00 sec) В отличие от NOW(), функция SYSDATE() не безопасна для репликации, потому что она не затронута SET TIMESTAMP в двоичном журнале и недетерминирована, если основанное на запросе журналирование используется. Это не проблема, если основанное на строке журналирование используется. Альтернатива должна использовать опцию --sysdate-is-now , чтобы вызвать SYSDATE() как псевдоним для NOW(). Это должно быть сделано на ведущем и ведомом устройствах, чтобы работать правильно. В таких случаях предупреждение все еще выпущено этой функцией, но может быть безопасно проигнорировано, пока --sysdate-is-now используется на ведущем и на ведомом устройствах. SYSDATE() автоматически копируется, используя основанную на строке репликацию, используя режим MIXED и производит предупреждение в режиме STATEMENT. См. раздел 19.4.1.32 . Следующее ограничение относится только к основанной на запросе репликации, но не к основанной на строке. Функции GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK() и IS_USED_LOCK(), которые обрабатывают блокировки на уровне пользователя, копируются без ведомого устройства, зная контекст параллелизма на ведущем устройстве. Поэтому, эти функции не должны использоваться, чтобы вставить в основную таблицу, потому что контент на ведомом устройстве будет отличаться. Например, не делайте запрос INSERT INTO mytable VALUES(GET_LOCK(...)) . Эти функции автоматически копируются, используя основанную на строке репликацию, используя режим MIXED и производят предупреждение в режиме STATEMENT. Как обходное решение для предыдущих ограничений, когда основанная на запросе репликация работает, Вы можете использовать стратегию сохранения проблематичного функционального результата в пользовательской переменной и обращении к переменной в более позднем запросе. Например, следующий 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. Когда с таким запросом сталкиваются: Используя режим STATEMENT, предупреждение, что запрос не безопасен для основанной на запросе репликации, создано. Используя режим STATEMENT, предупреждения выпущены для запросов DML, содержащих LIMIT даже когда они также имеют ORDER BY (и таким образом сделаны детерминированными). Это известная проблема (Bug #42851). Используя режим MIXED, запрос теперь автоматически копируется, используя основанный на строке режим. 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. Грязные завершения работы могли бы произвести проблемы, особенно если дисковый кэш не сброшен к диску прежде, чем проблема произошла: Для транзакций, которые ведомое устройство передает и затем обновляет relay-log.info. Если катастрофический отказ происходит между этими двумя операциями, обработка журнала реле продолжится далее, чем информационный файл указывает, и ведомое устройство повторно запустит события от последней транзакции в журнале реле после того, как это было перезапущено. Подобная проблема может произойти, если ведомое устройство обновляет relay-log.info, но катастрофический отказ узла сервера был перед сбросом записи на диск. Чтобы минимизировать шанс этого, надо установить sync_relay_log_info=1 в файле my.cnf ведомого. Значение по умолчанию sync_relay_log_info = 0 не сбрасывает записи на диск строго, сервер полагается на операционную систему, чтобы время от времени сбрасывать файл. Отказоустойчивость Вашей системы для этих типов проблем очень увеличена, если у Вас есть хорошее непрерывное электропитание. 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 становятся пустыми. Это заставляет ведомое устройство быть вне синхронизации с ведущим устройством и может привести к другим отказам или заставить ведомое устройство останавливаться: Формат строки, полученный от ведущего устройства, может потерпеть неудачу с ошибкой Can't find record in 'memory_table '. Запросы INSERT INTO ... SELECT FROM memory_table могут вставить различный набор строк на ведущем и ведомом устройствах. Безопасный способ перезапустить ведомое устройство, которое копирует таблицы 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 для запросов, вовлекающих временные таблицы, которые могут быть зарегистрированы безопасно, используя основанный на запросе формат. Безопасное ведомое завершение работы, используя временные таблицы. Временные таблицы копируются кроме случая, когда Вы останавливаете ведомый сервер (не только ведомые потоки), и Вы копировали временные таблицы, которые открыты для использования в обновлениях, которые еще не были выполнены на ведомом устройстве. Если Вы останавливаете ведомый сервер, временные таблицы, необходимые тем обновлениям, больше недоступны, когда ведомое устройство перезапущено. Чтобы избежать этой проблемы, не закрывайте ведомое устройство, в то время как у этого есть временные открытые таблицы. Вместо этого используйте следующую процедуру: Выполните STOP SLAVE SQL_THREAD. Используйте SHOW STATUS, чтобы проверять значение переменной Slave_open_temp_tables. Если значение не 0, перезапустите ведомый поток SQL с помощью START SLAVE SQL_THREAD и повторите процедуру позже. Когда значение 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. Чтобы работать вокруг проблемы базы данных, таблицы или имен столбцов на ведущем устройстве, которые были бы расценены как зарезервированные слова ведомым устройством, делается одно из следующего: Используйте один или больше ALTER TABLE на ведущем устройстве, чтобы изменить названия любой базы данных, где эти имена считались бы зарезервированными словами на ведомом устройстве, и измените любые запросы SQL, которые используют старые названия, чтобы использовать новые имена вместо этого. В любых запросах SQL, используя эти названия объекта базы данных, напишите имена как заключенные в кавычки идентификаторы, используя символы обратной кавычки (`). Для списков зарезервированных слов в версии 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. Обновите свои серверы через mysql_upgrade , сначала на ведомых устройствах и затем на ведущем устройстве. Это обычный принцип обновления ведомых устройств сначала. Решите, хотите ли Вы копировать табличный контент справки от ведущего устройства к его ведомым устройствам. В противном случае загрузите контент на ведущем устройстве и на каждом ведомом устройстве индивидуально. Иначе, проверьте и решите любые несовместимости между структурой таблицы справки на ведущем устройстве и ведомых, затем загрузите контент в ведущее устройство и позвольте этому копировать к ведомым устройствам. Загрузка табличного контента справки без репликации к ведомым устройствам Чтобы загрузить табличный контент справки без репликации, выполните эту команду на ведущем устройстве и на каждом ведомом устройстве индивидуально, используя файл 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 Табличный контент будет загружаться в ведущее устройство, затем копироваться к ведомым устройствам. Если у ведущего и ведомого устройств есть несовместимые таблицы справки (у одного сервера есть старая структура, другой имеет новую), у Вас есть выбор между не мультиплицированием табличного контента справки или созданием совместимых структур таблиц, чтобы Вы могли копировать контент. Если Вы решаете не копировать контент, обновите ведущее устройство и ведомые устройства, индивидуально, используя mysql с опцией --init-command . Если вместо этого Вы решаете сделать структуры таблиц совместимыми, обновите таблицы на сервере, у которого есть старая структура. Предположите, что у Вашего главного сервера есть старая структура таблицы. Обновите его таблицы до новой структуры вручную, выполняя эти запросы (двоичное журналирование отключено здесь, чтобы предотвратить репликацию изменений ведомых устройств, у которых уже есть новая структура): SET sql_log_bin=0; ALTER TABLE mysql.help_category ALTER COLUMN url TEXT; ALTER TABLE mysql.help_topic ALTER COLUMN 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. Репликация и транзакции Смешивание транзакционных и нетранзакционных запросов в пределах той же самой транзакции. Вообще Вы должны избежать транзакций, которые обновляют транзакционные и нетранзакционные таблицы в окружающей среде репликации. Вы должны также избегать использования любого запроса, который обращается к транзакционным (или временным) и нетранзакционным таблицам и пишет любую из них. Сервер использует эти правила для двоичного журналирования: Если начальные запросы в транзакции являются нетранзакционными, они немедленно написаны в двоичный журнал. Остающиеся запросы в транзакции кэшируются и не написаны в двоичный журнал, пока транзакция не передана. Если транзакция отменена, кэшируемые запросы написаны двоичному журналу, только если они производят нетранзакционные изменения, которые не могут быть отменены. Иначе от них отказываются. Для основанного на запросе журналирования журналирование нетранзакционных запросов затронуто binlog_direct_non_transactional_updates. Когда эта переменная OFF (по умолчанию), журналирование работает, как только что описано. Когда эта переменная ON, журналирование немедленно происходит для нетранзакционных запросов, происходящих где угодно в транзакции (не только начальных нетранзакционных запросов). Другие запросы сохранены в операционном кэше и зарегистрированы, когда транзакция передается. binlog_direct_non_transactional_updates не имеет никакого эффекта для журналирования формата строки или смешанного. Транзакционные, нетранзакционные и смешанные запросы. Чтобы применить эти правила, сервер считает запрос нетранзакционным, если он изменяет только нетранзакционные таблицы, и транзакционным, если он изменяет только транзакционные таблицы. В MySQL 8.0 запрос, который использует нетранзакционные и транзакционные таблицы и обновляет любые из вовлеченных таблиц, считается смешанным. В предыдущем ряду выпуска MySQL запрос, который менял нетранзакционные и транзакционные таблицы, считали смешанным. Смешанные запросы, как транзакционные запросы, кэшируются и зарегистрированы, когда транзакция передается. Смешанный запрос, который обновляет транзакционную таблицу, считают опасным, если запрос также выполняет любое из следующих действий: Обновления или чтения транзакционной таблицы. Читает нетранзакционную таблицу, и операционный уровень изоляции меньше REPEATABLE_READ. Смешанный запрос после обновления транзакционной таблицы в пределах транзакции считают опасным, если это выполняет любое из следующих действий: Обновления любой таблицы и чтения от любой временной таблицы. Обновляет нетранзакционную таблицу, и binlog_direct_non_trans_update = OFF. См. раздел 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. Репликация и операционные несогласованности Несогласованности в последовательности транзакций, которые были выполнены из журнала реле, могут произойти в зависимости от Вашей конфигурации репликации. Этот раздел объясняет, как избежать несогласованностей и решить любые проблемы, которые они вызывают. Следующие типы несогласованностей могут существовать: Полуприкладные транзакции. Транзакция, которая обновляет нетранзакционные таблицы, применила некоторые, но не все ее изменения. Промежутки. Промежуток это транзакция, которая не была (полностью) применена, даже при том, что некоторая более поздняя транзакция была применена. Промежутки могут появиться, только используя мультипоточное ведомое устройство. Чтобы избежать появления промежутков, надо установить slave_preserve_commit_order=1, что требует slave_parallel_type=LOGICAL_CLOCK, а также включения log-bin и log-slave-updates . Позиция низкой отметки без промежутков. Даже в отсутствие промежутков возможно, что транзакции после Exec_master_log_pos не были применены. Таким образом, все транзакции до точки N были применены, и никакие транзакции после N не были применены, но Exec_master_log_pos имеет значение меньше N. Это может произойти только на мультипоточных ведомых устройствах. Включение slave_preserve_commit_order не предотвращает такие позиции без промежутков. Следующие сценарии относятся к существованию полуприкладных транзакций, промежутков и несогласованностей позиции низкой отметки без промежутков: В то время как ведомые потоки работают, могут быть промежутки и полупримененные транзакции. mysqld закрывается. Чистое и грязное завершение работы прерывает продолжающиеся транзакции и может оставить промежутки и полупримененные транзакции. KILL для потоков репликации (поток SQL, используя однопоточное ведомое устройство, поток координатора, используя мультипоточное ведомое устройство). Это прерывает продолжающиеся транзакции и может оставить промежутки и полупримененные транзакции. Ошибка в потоках. Это может оставить промежутки. Если ошибка находится в смешанной транзакции, та транзакция полуприменена. Используя мультипоточное ведомое устройство, рабочие потоки, которые не получили ошибку, завершают свои очереди, таким образом, это может занять время, чтобы остановить все потоки. STOP SLAVE, используя мультипоточное ведомое устройство. После STOP SLAVE ведомое устройство ждет заполнения любых промежутков и затем обновляет Exec_master_log_pos. Это гарантирует, что никогда не оставляет промежутки или позиции низкой отметки без промежутков, если любой из случаев выше не применяется (другими словами, прежде завершения STOP SLAVE, ошибки, получением от другого потока KILL или перезапуска сервера. В этих случаях STOP SLAVE успешно отработает. Если последняя транзакция в журнале реле только полуполучена, и мультипоточный ведомый координатор начал намечать транзакцию рабочему, то STOP SLAVE ждет 60 секунд для транзакции, которая будет получена. После этого тайм-аута координатор сдается и прерывает транзакцию. Если транзакция смешана, это может остаться полузавершенным. STOP SLAVE, используя однопоточное ведомое устройство. Если продолжающаяся транзакция только обновляет транзакционные таблицы, она отменена и STOP SLAVE остановлен сразу. Если продолжающаяся транзакция смешана, STOP SLAVE ждет 60 секунд для транзакции, чтобы завершиться. После этого тайм-аута это прерывает транзакцию, таким образом, это может оставить ее полузавершенной. Глобальная переменная rpl_stop_slave_timeout не связана с процессом остановки потоков репликации. Это только делает клиенту, который вызвал STOP SLAVE, возврат управления к клиенту, но потоки репликации продолжают пытаться остановиться. Если у канала репликации есть промежутки, у него есть следующие последствия: Ведомая база данных находится в статусе, которое никогда, возможно, не существовало на ведущем устройстве. Поле Exec_master_log_pos в SHOW SLAVE STATUS только "low-watermark". Другими словами, транзакции, появляющиеся перед позицией, как гарантируют, переданы, но транзакции после позиции, возможно, переданы или нет. CHANGE MASTER TO для того канала терпят неудачу с ошибкой, если потоки применения не работают и CHANGE MASTER TO только устанавливает опции получателя. Если mysqld запущен с --relay-log-recovery, никакое восстановление не сделано для того канала, и предупреждение напечатано. Если 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 или выше). Если новый сервер это ведущее устройство репликации и имеет старые ведомые устройства, которые не поддерживают многократные триггеры, ошибка происходит на тех ведомых устройствах, если триггер создается на ведущем устройстве для таблицы, у которой уже есть триггер с тем же самым событием и временем действия. Чтобы избежать этой проблемы, обновите ведомые устройства сначала, затем обновите ведущее. Откат. Если Вы понижаете сервер, который поддерживает многократные триггеры к более старой версии, которая этого не делает, откат имеет эти эффекты: Для каждой таблицы, у которой есть триггеры, все определения триггеров находятся в файле .TRG для таблицы. Однако, если есть многократные триггеры с тем же самым событием и временем действия, сервер выполняет только одного из них, когда событие имеет место. Для информации о файлах .TRG см. Table Trigger Storage. Если триггеры для таблицы добавлены или удалены после отката, сервер переписывает файл .TRG. Переписанный файл сохраняет только один триггер на комбинацию события и времени, другие потеряны. Чтобы избежать этих проблем, измените свои триггеры перед откатом. Для каждой таблицы, у которой есть многократные триггеры на комбинацию события и времени, преобразуйте каждый такой набор триггеров к единственному триггеру следующим образом: Для каждого триггера, создайте сохраненную подпрограмму, которая содержит весь код триггера. Значения с доступом к использованию NEW и OLD могут быть переданы к обычным параметрам использования. Если триггер нуждается в единственном значении результата от кода, Вы можете поместить код в сохраненную функцию и иметь возвращенное функцией значение. Если триггер нуждается в многократных значениях результата от кода, Вы можете поместить код в хранимую процедуру и возвратить с использованием значений параметров OUT. Удалите все триггеры для таблицы. Создайте один новый триггер для таблицы, который вызывает сохраненные подпрограммы. Эффект для этого триггера то же самое, как многократные триггеры, которые это заменяет. 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, за исключением следующих переменных, когда они используются с контекстом сеанса: auto_increment_increment auto_increment_offset character_set_client character_set_connection character_set_database character_set_server collation_connection collation_database collation_server foreign_key_checks identity last_insert_id lc_time_names pseudo_thread_id sql_auto_is_null time_zone timestamp unique_checks Когда используется режим 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 следующие переменные сеанса написаны в двоичный журнал и соблюдаются ведомым устройством репликации, разбирая двоичной журнал, независимо от формата журналирования: sql_mode foreign_key_checks unique_checks character_set_client collation_connection collation_database collation_server sql_auto_is_null Даже при том, что переменные сеанса, касающиеся наборов символов и сопоставлений, написаны в двоичный журнал, репликация между различными наборами символов не поддержана. Чтобы помочь уменьшить возможный беспорядок, мы рекомендуем, чтобы Вы всегда использовали ту же самую установку для 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.3. См. раздел 19.2.1. Несовместимости SQL. Вы не можете копировать от более нового ведущего устройства к более старому ведомому, используя основанную на запросе репликацию, если запросы, которые будут копироваться, используют особенности SQL, доступные на ведущем устройстве, но не на ведомом. Однако, если оба устройства применяют основанную на строке репликацию, и нет никаких запросов определения данных, которые будут копироваться, которые зависят от особенностей SQL, на ведущем, но не на ведомом устройстве, Вы можете использовать основанную на строке репликацию, чтобы копировать эффекты запросов модификации данных, даже если DDL, выполненный на ведущем устройстве, не поддержан на ведомом устройстве. См. раздел 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. Является самым безопасным выполнить эти операции отдельно на ведомых устройствах и ведущем устройстве и отключить репликацию этих операций от ведущего устройства к ведомому. Чтобы достигнуть этого, используйте следующую процедуру: Остановите все ведомые устройства и обновите их. Перезапустите их с --skip-slave-start, чтобы они не соединились с ведущим устройством. Выполните любые операции ремонта или восстановления таблицы, которые должны были обновить объекты базы данных, такие как использование REPAIR TABLE, ALTER TABLE или дамп и перезагрузка таблиц или триггеров. Отключите двоичный журнал ведущего устройства. Чтобы сделать это, не перезапуская ведущее устройство, выполните SET sql_log_bin = 0. Альтернативно, остановите ведущее устройство и перезапустите это без опции --log-bin. Если Вы перезапускаете ведущее устройство, Вы могли бы также хотеть отвергнуть соединения клиента. Например, если все клиенты соединяются с использованием TCP/IP, используйте --skip-networking , когда Вы перезапускаете ведущее устройство. С отключенным двоичным журналом выполните любые операции ремонта или восстановления таблицы, которые должны были обновить объекты базы данных. Двоичный журнал должен быть отключен во время этого шага, чтобы препятствовать тому, чтобы эти операции были зарегистрированы и посланы в ведомые устройства позже. Повторно включите двоичный журнал нга ведущем устройстве. Если Вы устанавливаете sql_log_bin = 0, выполните SET sql_log_bin = 1. Если Вы перезапускали ведущее устройство, чтобы отключить двоичной журнал, перезапустите его с --log-bin и без --skip-networking, чтобы клиенты и ведомые устройства могли соединиться. Перезапустите ведомые устройства, на сей раз без опции --skip-slave-start. Если Вы обновляете существующую установку репликации от версии MySQL, которая не поддерживает глобальные операционные идентификаторы к версии, которая это делает, Вы не должны включить GTID на ведущем или на ведомом устройстве прежде, чем удостоверитесь, что установка отвечает всем требованиям для GTID-репликации. Например, server_uuid, который был добавлен в MySQL 5.6, должен существовать для GTID, чтобы функционировать правильно. См. раздел 19.1.3.2, который содержит информацию о преобразовании существующих установок репликации, чтобы использовать GTID-репликацию. 19.4.4. Поиск неисправностей репликации Если Вы следовали инструкциям, но Ваша установка репликации не работает, первое, что нужно сделать проверить журнал ошибок. Много пользователей потеряли время, не делая это достаточно быстро после столкновения с проблемами. Если Вы не можете сказать из журнала ошибок, какова проблема, попробуйте следующие методы: Проверьте, что ведущему устройству включили двоичное журналирование. Проверка делается с помощью SHOW MASTER STATUS. Если журналирование включено, Position не 0. Если двоичное журналирование не включено, проверьте, что Вы выполняете ведущее устройство с опцией --log-bin . Проверьте, что ведущее и ведомое устройства оба были запущены с опцией --server-id и что значение ID уникально на каждом сервере. Проверьте, что ведомое устройство работает. Надо использовать SHOW SLAVE STATUS, чтобы проверить, что Slave_IO_Running и Slave_SQL_Running имеют значение Yes. В противном случае проверьте опции, которые использовались, запуская ведомый сервер. Например, --skip-slave-start препятствует тому, чтобы ведомые потоки запустились до START SLAVE. Если ведомое устройство работает, проверьте, основало ли оно соединение с ведущим. Надо использовать SHOW PROCESSLIST, найдите ввод/вывод и потоки SQL и проверьте их столбец State, чтобы видеть, что они выводят на экран. См. раздел 19.2.2. Если состояние потока ввода/вывода Connecting to master, то проверьте следующее: Проверьте привилегии для пользователя, используемого для репликации на ведущем устройстве. Проверьте, что имя хоста ведущего устройства правильно и что Вы используете правильный порт, чтобы соединиться с ведущим устройством. Порт, используемый для репликации, является тем же самым, как использующийся для сетевых коммуникаций клиента (значение по умолчанию 3306). Для имени хоста гарантируйте, что имя ведет к правильному IP-адресу. Проверьте, что сети не были отключены на ведущем или ведомом устройствах. Ищите опцию skip-networking в конфигурационном файле. Если существует, закомментируйте или удалите. Если у ведущего устройства есть брандмауэр или конфигурация фильтрации IP, гарантируйте, что сетевой порт, используемый для MySQL, не фильтруется. Проверьте, что Вы можете достигнуть ведущего устройства при использовании ping или traceroute/tracert. Если ведомое устройство работало ранее, но остановилось, причина обычно состоит в том, что некоторый запрос, который преуспел на ведущем устройстве, провалился на ведомом. Это никогда не должно происходить, если Вы взяли надлежащий снимок ведущего устройства и никогда не изменяли данные по ведомому устройству за пределами ведомого потока. Если ведомое устройство неожиданно останавливается, это ошибка, или Вы столкнулись с одним из известных ограничений репликации, описанных в разделе 19.4.1. Если это ошибка, см. раздел 19.4.5 для инструкций, как сообщить об этом. Если запрос, который преуспел на ведущем устройстве, отказывается работать на ведомом, попробуйте следующую процедуру, если невыполнимо сделать полную пересинхронизацию базы данных, удаляя базы данных ведомого устройства и копируя новый снимок от ведущего устройства: Определите, отличается ли затронутая таблица на ведомом устройстве от основной таблицы. Попытайтесь понять, как это произошло. Тогда сделайте таблицу ведомого устройства идентичной ведущему устройству и выполните START SLAVE. Если предыдущий шаг не работает или не применяется, попытайтесь понять, было ли бы безопасно сделать обновление вручную (если нужно) и затем проигнорировать следующий запрос от ведущего устройства. Если Вы решаете, что ведомое устройство может пропустить следующий запрос от ведущего устройства, сделайте следующие запросы: mysql> SET GLOBAL sql_slave_skip_counter = N; mysql> START SLAVE; Значение N должно быть 1, если следующий запрос от ведущего устройства не использует AUTO_INCREMENT или LAST_INSERT_ID() . Иначе значение должно быть 2. Причина использования значения 2 для запросов AUTO_INCREMENT или LAST_INSERT_ID() то, что они берут два события в двоичном журнале ведущего устройства. См. раздел 14.4.2.5 . Если Вы уверены, что ведомое устройство начиналось отлично синхронизированным с ведущим устройством, и что никто не обновил таблицы за пределами ведомого потока, то по-видимому несоответствие результат ошибки. Если Вы выполняете новую версию MySQL, пожалуйста, сообщите о проблеме. Если Вы выполняете более старую версию, попытайтесь обновиться до последнего производственного выпуска, чтобы определить, сохраняется ли проблема. 19.4.5. Как сообщить об ошибках или проблемах репликации Когда Вы решили, что нет никакой пользовательской ошибки и репликация все еще не работает вообще или непостоянна, пора послать нам отчет об ошибках. Мы должны получить настолько большую информацию, насколько возможно от Вас, чтобы быть в состоянии разыскать ошибку. Пожалуйста, проведите некоторое время и усилие в подготовке хорошего отчета об ошибках. Если у Вас есть повторимый прецедент, который демонстрирует ошибку, пожалуйста, введите ее в нашу базу данных ошибок, используя инструкции, данные в разделе 1.7. Если у Вас есть призрак проблемы (который Вы не можете дублировать по желанию), используйте следующую процедуру: Проверьте, что никакая пользовательская ошибка не вовлечена. Например, если Вы обновляете ведомое устройство за пределами ведомого потока, данные выходят из синхронизации, и у Вас могут быть уникальные ключевые нарушения на обновлениях. В этом случае ведомый поток останавливается и ждет, чтобы очистить таблицы вручную, чтобы привести их в синхронизацию. Это не проблема репликации. Это проблема внешнего вмешательства. Выполните ведомое устройство с опциями --log-slave-updates и --log-bin. Эти опции заставляют ведомое устройство регистрировать обновления, которые оно получает от ведущего устройства в его собственные двоичные журналы. Сохраните все доказательства прежде, чем сбросить статус репликации. Если у нас нет никакой информации или она только отрывочна, становится трудным или невозможным для нас разыскать проблему. Доказательства, которые Вы должны собрать: Все двоичные файлы системного журнала от ведущего устройства. Все двоичные файлы системного журнала от ведомого устройства. Вывод SHOW MASTER STATUS от ведущего устройства в то время, когда Вы обнаружили проблему. Вывод SHOW SLAVE STATUS от ведомого устройства в то время, когда Вы обнаружили проблему. Журналы ошибок от ведущего и ведомого устройств. Примените 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.