--log-warnings[=level]

Заставляет сервер записывать больше сообщений в журнал ошибок о том, что он делает. Что касается репликации, сервер генерирует предупреждения о том, что он успешно переподключился после сбоя сети или соединения, и предоставляет информацию о том, как запущен каждый поток репликации. Эта переменная по умолчанию установлена в 2. Чтобы отключить её, установите значение 0. Сервер регистрирует сообщения об операторах, которые небезопасны для ведения журнала на основе операторов, если значение больше 0. Прерванные соединения и ошибки отказа в доступе для новых попыток подключения регистрируются, если значение больше 1. См. Раздел B.3.2.9, «Ошибки связи и прерванные соединения».

--master-info-file=file_name

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

--master-retry-count=count

Количество попыток реплики переподключиться к источнику, прежде чем сдаться. Значение по умолчанию — 86400 раз. Значение 0 означает «бесконечность», и реплика пытается подключаться вечно. Попытки переподключения запускаются, когда реплика достигает времени ожидания соединения (указанного системной переменной slave_net_timeout), не получая данных или сигнала синхронизации от источника. Попытка переподключения предпринимается через интервалы, установленные параметром MASTER_CONNECT_RETRY инструкции CHANGE MASTER TO (по умолчанию каждые 60 секунд).

Этот параметр устарел; ожидается, что он будет удален в будущей версии MySQL. Используйте вместо этого параметр MASTER_RETRY_COUNT инструкции CHANGE MASTER TO.

--max-relay-log-size=size

Размер, при котором сервер автоматически поворачивает файлы журнала ретрансляции. Если это значение отлично от нуля, журнал ретрансляции автоматически поворачивается, когда его размер превышает это значение. Если это значение равно нулю (по умолчанию), размер, при котором происходит поворот журнала ретрансляции, определяется значением max_binlog_size. Для получения дополнительной информации см. Раздел 16.2.4.1, «Журнал ретрансляции».

--relay-log-purge={0|1}

Отключить или включить автоматическую очистку журналов ретрансляции, как только они больше не нужны. Значение по умолчанию — 1 (включено). Это глобальная переменная, которая может быть динамически изменена с помощью SET GLOBAL relay_log_purge = N. Отключение очистки журналов ретрансляции при включении параметра --relay-log-recovery ставит под угрозу согласованность данных.

--relay-log-space-limit=size

Этот параметр устанавливает верхний предел общего размера в байтах всех журналов ретрансляции на реплике. Значение 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

Создаёт фильтр репликации, используя имя базы данных. Такие фильтры также можно создать с помощью 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, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

Если используется репликация на основе операторов, то обе таблицы обновляются на реплике. Однако при использовании репликации на основе строк изменяется только table1 на реплике; поскольку table2 находится в другой базе данных, table2 на реплике не изменяется оператором UPDATE. Теперь предположим, что вместо оператора USE db1 был использован оператор USE db4:

USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 = 10, db2.table2.col2 = 20;

В этом случае оператор UPDATE не оказывает никакого влияния на реплику при использовании репликации на основе операторов. Однако если используется репликация на основе строк, оператор UPDATE изменит table1 на реплике, но не table2 — другими словами, изменяются только таблицы в базе данных, имя которой указано с помощью --replicate-do-db, и выбор базы данных по умолчанию на это не влияет.

Если вам необходимо, чтобы межбазовые обновления работали, используйте --replicate-wild-do-table=db_name.% вместо этого. См. Раздел 16.2.5, «Как сервера оценивают правила фильтрации репликации».

--replicate-ignore-db=db_name

Создаёт фильтр репликации, используя имя базы данных. Такие фильтры также можно создавать с помощью CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB. Как и в случае с --replicate-do-db, точный эффект этого фильтра зависит от того, используется ли репликация на основе инструкций или на основе строк, и описывается в следующих нескольких абзацах.

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

Репликация на основе строк. Запрещает обновление таблиц в базе данных 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 на источнике.

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

Не следует использовать этот параметр, если вы используете обновления между базами данных и не хотите, чтобы эти обновления реплицировались. См. Раздел 16.2.5, «Как серверы оценивают правила фильтрации репликации».

Если вам необходимо, чтобы межбазовые обновления работали, используйте --replicate-wild-ignore-table=db_name.% вместо этого. См. Раздел 16.2.5, «Как серверы оценивают правила фильтрации репликации».

--replicate-do-table=db_name.tbl_name

Создаёт фильтр репликации, ограничивая репликацию заданной таблицей. Для указания более одной таблицы используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает как для межбазовых, так и для обновлений в базе данных по умолчанию, в отличие от --replicate-do-db. См. Раздел 16.2.5, «Как серверы оценивают правила фильтрации репликации». Вы также можете создать такой фильтр, выполнив инструкцию CHANGE REPLICATION FILTER REPLICATE_DO_TABLE.

Этот параметр влияет только на инструкции, относящиеся к таблицам. Он не влияет на инструкции, относящиеся только к другим объектам базы данных, таким как хранимые процедуры. Для фильтрации инструкций, работающих с хранимыми процедурами, используйте один или несколько параметров --replicate-*-db.

--replicate-ignore-table=db_name.tbl_name

Создаёт фильтр репликации, запрещающий репликацию инструкций, обновляющих указанную таблицу, даже если та же инструкция может обновлять и другие таблицы. Для указания более одной таблицы для игнорирования используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает для межбазовых обновлений, в отличие от --replicate-ignore-db. См. Раздел 16.2.5, «Как серверы оценивают правила фильтрации репликации». Вы также можете создать такой фильтр, выполнив инструкцию CHANGE REPLICATION FILTER REPLICATE_IGNORE_TABLE.

Этот параметр влияет только на инструкции, относящиеся к таблицам. Он не влияет на инструкции, относящиеся только к другим объектам базы данных, таким как хранимые процедуры. Для фильтрации инструкций, работающих с хранимыми процедурами, используйте один или несколько параметров --replicate-*-db.

--replicate-rewrite-db=from_name->to_name

Указывает реплике создать фильтр репликации, который преобразует указанную базу данных в to_name, если она была from_name на источнике. Затрагиваются только операторы, связанные с таблицами, а не операторы, такие как CREATE DATABASE, DROP DATABASE и ALTER DATABASE.

Для указания нескольких преобразований используйте этот параметр несколько раз. Сервер использует первый с from_name значением, которое соответствует. Преобразование имени базы данных выполняется перед проверкой правил --replicate-*. Вы также можете создать такой фильтр, выполнив оператор CHANGE REPLICATION FILTER REPLICATE_REWRITE_DB.

Если вы используете опцию --replicate-rewrite-db в командной строке, а символ > является специальным для вашего интерпретатора команд, укажите значение параметра в кавычках. Например:

$> mysqld --replicate-rewrite-db="olddb->newdb"

Эффект параметра --replicate-rewrite-db отличается в зависимости от того, используется ли для запроса формат двоичного протокола на основе операторов или на основе строк. При использовании формата на основе операторов операторы DML переводятся на основе текущей базы данных, как указано оператором USE. При использовании формата на основе строк операторы DML переводятся на основе базы данных, в которой существует изменённая таблица. Операторы DDL всегда фильтруются на основе текущей базы данных, как указано оператором USE, независимо от формата двоичного протокола.

Чтобы гарантировать, что переименование даст ожидаемый результат, особенно в сочетании с другими параметрами фильтрации репликации, следуйте этим рекомендациям при использовании параметра --replicate-rewrite-db:

Если эти рекомендации соблюдены, использование параметра --replicate-rewrite-db в сочетании с параметрами фильтрации репликации на уровне таблиц, такими как --replicate-do-table, безопасно.

--replicate-same-server-id

Используется на серверах-репликах. Обычно следует использовать значение по умолчанию 0, чтобы предотвратить бесконечные циклы, вызванные циклической репликацией. Если установлено 1, реплика не пропускает события, имеющие собственный идентификатор сервера. Обычно это полезно только в редких конфигурациях. Не может быть установлено в 1, если включен log_slave_updates. По умолчанию поток ввода-вывода репликации не записывает события журнала двоичных логов в журнал реле, если у них есть идентификатор сервера реплики (эта оптимизация помогает экономить место на диске). Если вы хотите использовать --replicate-same-server-id, убедитесь, что вы запустили реплику с этим параметром, прежде чем вы сделаете реплику прочитать свои собственные события, которые вы хотите, чтобы поток репликации SQL выполнил.

--replicate-wild-do-table=db_name.tbl_name

Создает фильтр репликации, сообщая потоку SQL репликации о необходимости ограничить репликацию операторами, где любые обновлённые таблицы соответствуют указанным шаблонам имени базы данных и таблицы. Шаблоны могут содержать символы подстановки % и _, которые имеют то же значение, что и для оператора соответствия шаблонам LIKE. Чтобы указать более одной таблицы, используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает для межбазовых обновлений. См. Раздел 16.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

Создаёт фильтр репликации, который предотвращает репликацию SQL-потоком репликации оператора, в котором любая таблица соответствует заданному шаблону с подстановкой. Чтобы игнорировать более одной таблицы, используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает для межбазовых обновлений. См. Раздел 16.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.

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

Например, если --replicate-ignore-db=nonreplicated настроен на сервере реплики, следующая последовательность операторов приводит к игнорированию оператора GRANT, так как в качестве базы данных по умолчанию используется nonreplicated:

USE nonreplicated;
GRANT SELECT, INSERT ON replicated.t1 TO 'someuser'@'somehost';

--skip-slave-start

Указывает реплицирующему серверу не запускать потоки репликации при запуске сервера. Чтобы запустить потоки позже, используйте оператор START SLAVE.

--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]

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

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

Для кодов ошибок следует использовать числа, предоставленные в сообщении об ошибке в журнале ошибок реплики и в выводе оператора SHOW SLAVE STATUS. Приложение B, Сообщения об ошибках и распространённые проблемы, содержит список кодов ошибок сервера.

Краткое значение ddl_exist_errors эквивалентно списку кодов ошибок 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146.

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

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

Примеры:

--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors

--slave-sql-verify-checksum={0|1}

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

init_slave

Эта переменная похожа на init_connect, но представляет собой строку, которая выполняется сервером реплики каждый раз при запуске потока SQL репликации. Формат строки такой же, как у переменной init_connect. Настройка этой переменной вступает в силу для последующих инструкций START SLAVE.

log_slow_slave_statements

При включенном журнале медленных запросов эта переменная включает протоколирование запросов, выполнение которых заняло более long_query_time секунд на реплике. Обратите внимание, что если используется репликация на основе строк (binlog_format=ROW), log_slow_slave_statements не имеет эффекта. Запросы добавляются в журнал медленных запросов реплики только в том случае, если они протоколированы в формате запросов в бинарном журнале, то есть при установке binlog_format=STATEMENT или при установке binlog_format=MIXED и запросы протоколированы в формате запросов. Медленные запросы, которые протоколированы в формате строк при установке binlog_format=MIXED или протоколированы при установке binlog_format=ROW, не добавляются в журнал медленных запросов реплики, даже если log_slow_slave_statements включен.

Установка log_slow_slave_statements не имеет немедленного эффекта. Состояние переменной применяется ко всем последующим операциям START SLAVE. Кроме того, глобальная настройка long_query_time действует в течение всего срока службы потока SQL. Если вы измените это значение, вам необходимо остановить и перезапустить поток репликации SQL, чтобы применить изменения (например, выпустив инструкции STOP SLAVE и START SLAVE с опцией SQL_THREAD).

master_info_repository

Настройка этой переменной определяет, записывает ли реплика метаданные о источнике, состоящие из статуса и информации о подключении, в таблицу InnoDB в базе данных mysql или в виде файла в каталоге данных. Дополнительную информацию о репозитории метаданных подключения см. в Разделе 16.2.4, «Журналы релеев и репозитории метаданных репликации».

Значение по умолчанию — FILE. В качестве файла репозиторий метаданных подключения реплики по умолчанию имеет имя master.info. Вы можете изменить это имя, используя опцию --master-info-file.

Альтернативное значение — TABLE. В качестве таблицы InnoDB репозиторий метаданных подключения реплики имеет имя mysql.slave_master_info. Настройка TABLE необходима при конфигурировании нескольких каналов репликации.

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

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

max_relay_log_size

Если запись репликой в свой журнал релеев приводит к превышению размера текущего файла журнала, реплика вращает журналы релеев (закрывает текущий файл и открывает следующий). Если max_relay_log_size равно 0, сервер использует max_binlog_size как для бинарного журнала, так и для журнала релеев. Если max_relay_log_size больше 0, она ограничивает размер журнала релеев, что позволяет иметь разные размеры для двух журналов. Вы должны установить max_relay_log_size в диапазон от 4096 байтов до 1 ГБ (включительно) или 0. Значение по умолчанию — 0. См. Раздел 16.2.3, «Потоки репликации».

relay_log

Базовое имя для файлов релейного журнала. Для канала репликации по умолчанию базовым именем для релейных журналов является host_name-relay-bin. Для каналов репликации, отличных от канала по умолчанию, базовым именем для релейных журналов является host_name-relay-bin-channel, где channel — это имя канала репликации, записанного в этом релейном журнале.

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

Из-за способа, которым MySQL разбирает параметры сервера, если вы указываете эту переменную при запуске сервера, вы должны указать значение; базовое имя по умолчанию используется только в том случае, если параметр фактически не указан. Если вы указываете системную переменную relay_log при запуске сервера без указания значения, скорее всего, произойдет непредвиденное поведение; это поведение зависит от используемых других параметров, порядка их указания и того, указаны ли они в командной строке или в файле параметров. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера, см. Раздел 4.2.2, «Указание параметров программы».

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

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

Системная переменная relay_log может быть полезна при выполнении следующих задач:

Вы можете получить имя файла (и путь) релейного журнала из системной переменной relay_log_basename.

relay_log_basename

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

relay_log_index

Имя файла индекса релейного журнала. Максимальная длина переменной составляет 256. Для канала репликации по умолчанию имя по умолчанию — host_name-relay-bin.index. Для каналов репликации, отличных от канала по умолчанию, имя по умолчанию — host_name-relay-bin-channel.index, где channel — это имя канала репликации, записанного в этом индексе релейного журнала.

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

Из-за способа, которым MySQL разбирает параметры сервера, если вы указываете эту переменную при запуске сервера, вы должны указать значение; базовое имя по умолчанию используется только в том случае, если параметр фактически не указан. Если вы указываете системную переменную relay_log_index при запуске сервера без указания значения, скорее всего, произойдет непредвиденное поведение; это поведение зависит от используемых других параметров, порядка их указания и того, указаны ли они в командной строке или в файле параметров. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера, см. Раздел 4.2.2, «Указание параметров программы».

relay_log_info_file

Имя файла, в котором реплика записывает информацию о релейных журналах, когда relay_log_info_repository=FILE. Если relay_log_info_repository=TABLE, это имя файла, которое будет использоваться в случае, если репозиторий будет изменен на FILE). Имя по умолчанию — relay-log.info в каталоге данных. Для получения информации о репозитории метаданных приложения см. Раздел 16.2.4.2, «Репозитории метаданных репликации».

relay_log_info_repository

Настройка этой переменной определяет, хранит ли сервер реплики свой репозиторий метаданных приложения в виде таблицы InnoDB в системной базе данных mysql или в виде файла в каталоге данных. Для получения дополнительной информации о репозитории метаданных приложения см. Раздел 16.2.4, «Релейный журнал и репозитории метаданных репликации».

Настройка по умолчанию — FILE. В виде файла репозиторий метаданных приложения реплики по умолчанию называется relay-log.info, и вы можете изменить это имя с помощью системной переменной relay_log_info_file.

С настройкой TABLE, как таблица InnoDB, репозиторий метаданных приложения реплики называется mysql.slave_relay_log_info. Настройка TABLE необходима при настройке нескольких каналов репликации. Настройка TABLE для репозитория метаданных приложения реплики также необходима для обеспечения отказоустойчивости репликации к неожиданным остановкам. См. Раздел 16.3.2, «Обработка неожиданной остановки реплики» для получения дополнительной информации.

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

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

relay_log_purge

Отключает или включает автоматическую очистку файлов релейного журнала, как только они больше не нужны. Значение по умолчанию — 1 (ON).

relay_log_recovery

Если включена, эта переменная включает автоматическое восстановление журнала ретрансляции сразу после запуска сервера. Процесс восстановления создает новый файл журнала ретрансляции, инициализирует позицию потока SQL в этом новом журнале ретрансляции и инициализирует поток I/O в позицию потока SQL. Затем продолжается чтение журнала ретрансляции из источника.

Эта глобальная переменная является доступной только для чтения во время выполнения. Ее значение может быть установлено с помощью параметра --relay-log-recovery при запуске сервера реплики, который следует использовать после неожиданного останова реплики, чтобы гарантировать, что не будут обрабатываться потенциально поврежденные журналы ретрансляции, и который необходимо использовать для обеспечения отказоустойчивой реплики. Значение по умолчанию равно 0 (отключено). Информацию о сочетании параметров на реплике, наиболее устойчивой к неожиданным остановкам, см. в разделе 16.3.2, «Обработка неожиданного останова реплики».

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

Для многопоточной реплики (где slave_parallel_workers больше 0), начиная с MySQL 5.7.13, установка relay_log_recovery = ON автоматически обрабатывает любые несоответствия и пробелы в последовательности транзакций, которые были выполнены из журнала ретрансляции. Эти пробелы могут возникать при использовании репликации на основе позиции файла. (Для получения более подробной информации см. раздел 16.4.1.32, «Репликация и несоответствия транзакций».) Процесс восстановления журнала ретрансляции обрабатывает пробелы, используя тот же метод, что и оператор START SLAVE UNTIL SQL_AFTER_MTS_GAPS. Когда реплика достигает согласованного состояния без пробелов, процесс восстановления журнала ретрансляции переходит к извлечению дальнейших транзакций из источника, начиная с позиции потока SQL репликации. В версиях MySQL до MySQL 5.7.13 этот процесс не был автоматическим и требовал запуска сервера с relay_log_recovery=0, запуска реплики с START SLAVE UNTIL SQL_AFTER_MTS_GAPS для исправления любых несоответствий транзакций, а затем перезапуска реплики с relay_log_recovery=1. При использовании репликации на основе GTID, начиная с MySQL 5.7.28, многопоточная реплика сначала проверяет, установлено ли MASTER_AUTO_POSITION в ON, и если это так, пропускает шаг вычисления транзакций, которые следует пропустить или не пропускать, так что старые журналы ретрансляции не требуются для процесса восстановления.

relay_log_space_limit

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

replication_optimize_for_static_plugin_config

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

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

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

replication_sender_observe_commit_only

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

report_host

Имя хоста или IP-адрес реплики, который будет сообщен источнику во время регистрации реплики. Это значение отображается в выводе SHOW SLAVE HOSTS на сервере источника. Оставьте значение не установленным, если вы не хотите, чтобы реплика регистрировалась в источнике.

report_password

Пароль учетной записи пользователя репликации реплики, который будет сообщен источнику во время регистрации реплики. Это значение отображается в выводе SHOW SLAVE HOSTS на сервере источника, если источник был запущен с --show-slave-auth-info.

Хотя название этой переменной может указывать на обратное, report_password не связана с системой привилегий пользователей MySQL и поэтому не обязательно (или даже, вероятно, не) совпадает с паролем для учетной записи пользователя репликации MySQL.

report_port

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

Значение по умолчанию для этого параметра — номер порта, фактически используемый репликой. Это также значение по умолчанию, отображаемое в SHOW SLAVE HOSTS.

report_user

Имя учетной записи пользователя реплики, которое должно быть сообщено источнику при регистрации реплики. Это значение отображается в выводе SHOW SLAVE HOSTS на сервере источника, если источник был запущен с --show-slave-auth-info.

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

rpl_semi_sync_slave_enabled

Управляет включением полусинхронной репликации на реплике. Для включения или отключения плагина установите эту переменную в ON или OFF (соответственно 1 или 0). Значение по умолчанию — OFF.

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

rpl_semi_sync_slave_trace_level

Уровень отладки трассировки полусинхронной репликации на реплике. Смотрите rpl_semi_sync_master_trace_level для допустимых значений.

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

rpl_stop_slave_timeout

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

Максимальное и значение по умолчанию для rpl_stop_slave_timeout составляет 31536000 секунд (1 год). Минимальное — 2 секунды. Изменения в этой переменной вступают в силу для последующих команд STOP SLAVE.

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

slave_checkpoint_group

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

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

Минимальное разрешенное значение для этой переменной — 32, если сервер не был скомпилирован с помощью -DWITH_DEBUG, в этом случае минимальное значение равно 1. Эффективное значение всегда кратно 8; вы можете установить значение, которое не кратно 8, но сервер округляет его вниз до ближайшего меньшего кратного 8 перед сохранением значения. (Исключение: такой округления не выполняет отладочный сервер.) Независимо от того, как был скомпилирован сервер, значение по умолчанию — 512, а максимальное разрешенное значение — 524280.

slave_checkpoint_period

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

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

Минимальное допустимое значение для этой переменной равно 1, если сервер не был скомпилирован с помощью -DWITH_DEBUG; в противном случае минимальное значение равно 0. Независимо от способа компиляции сервера, значение по умолчанию равно 300 миллисекундам, а максимальное возможное значение равно 4294967295 миллисекундам (приблизительно 49,7 дня).

slave_compressed_protocol

Используется ли сжатие протокола источник/реплика, если обе стороны его поддерживают. Если эта переменная отключена (что является значением по умолчанию), соединения не сжимаются. Изменения в этой переменной вступают в силу при последующих попытках подключения; это включает в себя после выполнения команды START SLAVE, а также при повторных подключениях, выполняемых потоком репликации I/O (например, после установки параметра MASTER_RETRY_COUNT для команды CHANGE MASTER TO). См. также Раздел 4.2.6 «Управление сжатием подключений».

slave_exec_mode

Управляет тем, как поток репликации разрешает конфликты и ошибки во время репликации. Режим IDEMPOTENT приводит к подавлению ошибок дублирования ключей и отсутствия ключа; STRICT означает, что такого подавления не происходит.

Режим IDEMPOTENT предназначен для использования в репликации с несколькими источниками, циклической репликации и других специальных сценариях репликации для NDB Cluster Replication. (См. Раздел 21.7.10 «NDB Cluster Replication: Bidirectional and Circular Replication» и Раздел 21.7.11 «NDB Cluster Replication Conflict Resolution» для получения дополнительной информации). NDB Cluster игнорирует явное значение, установленное для slave_exec_mode, и всегда обрабатывает его как IDEMPOTENT.

В MySQL Server 5.7, режим STRICT является значением по умолчанию.

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

slave_load_tmpdir

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

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

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

slave_max_allowed_packet

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

Эта глобальная переменная всегда имеет значение, являющееся положительным целым кратным 1024; если вы установите какое-то другое значение, оно округляется вниз до ближайшего большего кратного 1024 при хранении или использовании; установка slave_max_allowed_packet в 0 приводит к использованию 1024. (В таких случаях выдается предупреждение об усечении). Значение по умолчанию и максимальное значение равно 1073741824 (1 ГБ); минимальное значение — 1024.

slave_net_timeout

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

Первая попытка повторного подключения происходит сразу после истечения срока ожидания. Интервал между повторными попытками контролируется параметром MASTER_CONNECT_RETRY для команды CHANGE MASTER TO, а количество попыток повторного подключения ограничено параметром MASTER_RETRY_COUNT для команды CHANGE MASTER TO.

Интервал отправки сигналов подтверждения, предотвращающий истечение срока ожидания подключения при отсутствии данных, если подключение всё ещё работает, контролируется параметром MASTER_HEARTBEAT_PERIOD для команды CHANGE MASTER TO. Интервал отправки сигналов подтверждения по умолчанию равен половине значения slave_net_timeout, и он записывается в репозиторий метаданных подключений реплики и отображается в таблице Performance Schema replication_connection_configuration. Обратите внимание, что изменение значения или значения по умолчанию для slave_net_timeout не автоматически изменяет интервал отправки сигналов подтверждения, независимо от того, был ли он задан явно или использовался ранее вычисленный параметр по умолчанию. При изменении срока ожидания подключения необходимо также выполнить команду CHANGE MASTER TO для корректировки интервала отправки сигналов подтверждения до подходящего значения, чтобы оно происходило до истечения срока ожидания подключения.

slave_parallel_type

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

Если slave_preserve_commit_order=1 установлено, можно использовать только LOGICAL_CLOCK.

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

slave_parallel_workers

Устанавливает количество потоков прикладного уровня для параллельного выполнения транзакций репликации. Установка этого значения на число больше 0 создаёт многопоточную реплику с указанным количеством потоков прикладного уровня. При установке в 0 (значение по умолчанию) параллельное выполнение отключено, и реплика использует один поток прикладного уровня. Установка slave_parallel_workers не имеет немедленного эффекта. Состояние переменной применяется ко всем последующим командам START SLAVE.

Многопоточная реплика обеспечивает параллельное выполнение с помощью координирующего потока и количества потоков прикладного уровня, настроенного этой переменной. Способ распределения транзакций между потоками прикладного уровня настроен переменной slave_parallel_type. Транзакции, которые реплика применяет параллельно, могут завершаться не в порядке, если не установлено slave_preserve_commit_order=1. Поэтому проверка наиболее недавно выполненной транзакции не гарантирует, что все предыдущие транзакции с источника были выполнены на реплике. Это имеет последствия для ведения журнала и восстановления при использовании многопоточной реплики. Например, в многопоточной реплике команда START SLAVE UNTIL поддерживает только использование SQL_AFTER_MTS_GAPS.

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

Многопоточные реплики в настоящее время не поддерживаются NDB Cluster. Более подробную информацию о том, как NDB обрабатывает настройки этой переменной, см. в Разделе 21.7.3, «Известные проблемы в репликации NDB Cluster».

slave_pending_jobs_size_max

Для реплик с многопоточностью эта переменная задает максимальный объём памяти (в байтах), доступный для очередей обработки событий, которые ещё не были применены. Установка этой переменной не влияет на реплики, для которых многопоточность не включена. Установка этой переменной не имеет немедленного эффекта. Состояние переменной применяется ко всем последующим командам START SLAVE.

Минимальное возможное значение для этой переменной равно 1024; значение по умолчанию равно 16 МБ. Максимальное возможное значение равно 18446744073709551615 (16 эксабайт). Значения, которые не являются точными кратными 1024, округляются вниз до ближайшего большего кратного 1024 перед сохранением.

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

slave_preserve_commit_order

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

slave_preserve_commit_order=1 требует, чтобы --log-bin и --log-slave-updates были включены на реплике, и slave_parallel_type было установлено в значение LOGICAL_CLOCK. Перед изменением этой переменной все потоки репликации (для всех каналов репликации, если вы используете несколько каналов репликации) должны быть остановлены.

При включённом slave_preserve_commit_order, исполняемый поток ожидает, пока все предыдущие транзакции не будут подтверждены, прежде чем подтвердить текущую. Пока поток ожидает подтверждения других рабочих потоков, он сообщает о своём статусе как Waiting for preceding transaction to commit. (До MySQL 5.7.8 это отображалось как Waiting for its turn to commit.) Включение этого режима на многопоточной реплике гарантирует, что она никогда не переходит в состояние, в котором не была исходная. Это поддерживает использование репликации для масштабирования чтения. См. Раздел 16.3.4, «Использование репликации для масштабирования чтения».

Если slave_preserve_commit_order=0 установлено, транзакции, которые реплика применяет параллельно, могут быть подтверждены не в порядке. Поэтому проверка последней выполненной транзакции не гарантирует, что все предыдущие транзакции из источника были выполнены на реплике. Возможны разрывы в последовательности транзакций, выполненных из журнала репликации реплики. Это имеет последствия для ведения журнала и восстановления при использовании многопоточной реплики. Обратите внимание, что настройка slave_preserve_commit_order=1 предотвращает разрывы, но не предотвращает отставание позиции исходного двоичного журнала (где Exec_master_log_pos отстаёт от позиции, до которой транзакции были выполнены). См. Раздел 16.4.1.32, «Репликация и несогласованности транзакций» для получения дополнительной информации.

slave_rows_search_algorithms

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

Укажите список значений, разделённых запятыми, из следующих комбинаций 2 значений из списка INDEX_SCAN, TABLE_SCAN, HASH_SCAN. Ожидаемое значение — строка, поэтому, если переменная устанавливается во время выполнения, а не при запуске сервера, значение должно быть заключено в кавычки. Кроме того, значение не должно содержать пробелов. Рекомендуемые комбинации (списки) и их эффекты показаны в следующей таблице:

Порядок, в котором алгоритмы указаны в списке, не влияет на порядок, в котором они отображаются операцией SELECT или SHOW VARIABLES.

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

slave_skip_errors

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

slave_sql_verify_checksum

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

slave_transaction_retries

Если поток SQL репликации не может выполнить транзакцию из-за тупика в InnoDB или время выполнения транзакции превысило InnoDB's innodb_lock_wait_timeout или NDB's TransactionDeadlockDetectionTimeout или TransactionInactiveTimeout, то он автоматически повторяет попытку slave_transaction_retries раз, прежде чем остановить выполнение с ошибкой. Транзакции с ошибкой, не являющейся временной, не повторяются.

Значение по умолчанию для slave_transaction_retries равно 10. Установка переменной в 0 отключает автоматическое повторное выполнение транзакций. Изменение этой переменной вступает в силу для всех каналов репликации сразу, включая работающие каналы.

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

Таблица Performance Schema replication_applier_status отображает количество повторов, произошедших в каждом канале репликации, в столбце COUNT_TRANSACTIONS_RETRIES.

slave_type_conversions

Управляет режимом преобразования типов на реплике при использовании репликации на основе строк. В MySQL 5.7.2 и выше, его значение — это список из нуля или более элементов, разделённых запятыми из списка: ALL_LOSSY, ALL_NON_LOSSY, ALL_SIGNED, ALL_UNSIGNED. Установите эту переменную в пустую строку, чтобы запретить преобразования типов между источником и репликой. Изменение этой переменной вступает в силу для всех каналов репликации сразу, включая работающие каналы.

ALL_SIGNED и ALL_UNSIGNED были добавлены в MySQL 5.7.2 (Bug#15831300). Для дополнительной информации о режимах преобразования типов, применимых к продвижению и понижению атрибутов при репликации на основе строк, см. Репликация на основе строк: продвижение и понижение атрибутов.

sql_slave_skip_counter

Количество событий из источника, которое реплика должна пропустить. Установка параметра не имеет немедленного эффекта. Переменная применяется к следующему оператору START SLAVE; следующий оператор START SLAVE также изменяет значение обратно на 0. Когда эта переменная установлена в ненулевое значение и настроено несколько каналов репликации, оператор START SLAVE может быть использован только с клаузой FOR CHANNEL channel.

Этот параметр несовместим с репликацией на основе GTID и не должен быть установлен в ненулевое значение при gtid_mode=ON. Если необходимо пропустить транзакции при использовании GTID, используйте gtid_executed из источника. См. Раздел 16.1.7.3, “Пропуск транзакций”.

sync_master_info

Влияние этой переменной на реплику зависит от того, установлено ли для реплики 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

Если значение этой переменной больше 0, сервер MySQL синхронизирует свой релейный журнал на диск (используя fdatasync()) после каждых sync_relay_log событий, записанных в релейный журнал. Установка этой переменной вступает в силу для всех каналов репликации немедленно, включая работающие каналы.

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

Значение 1 является наиболее безопасным выбором, потому что в случае непредвиденной остановки вы потеряете не более одного события из релейного журнала. Однако это также самый медленный выбор (если диск не имеет кэша с батарейным питанием, что делает синхронизацию очень быстрой). Для получения информации о сочетании настроек на реплике, обеспечивающей наибольшую устойчивость к непредвиденным остановкам, см. Раздел 16.3.2, «Обработка непредвиденной остановки реплики».

sync_relay_log_info

Значение по умолчанию для sync_relay_log_info равно 10000. Установка этой переменной вступает в силу для всех каналов репликации немедленно, включая работающие каналы.

Влияние этой переменной на реплику зависит от настройки сервера relay_log_info_repository (FILE или TABLE). Если настройка равна TABLE, то влияние переменной также зависит от того, является ли используемый движок хранения для таблицы relay log info транзакционным (таким как InnoDB) или нетранзакционным (MyISAM). Влияние этих факторов на поведение сервера для значений sync_relay_log_info равных нулю и больше нуля таково: