--master-retry-count=count

Этот параметр устарел; ожидается его удаление в будущих выпусках MySQL. Вместо этого используйте параметр SOURCE_RETRY_COUNT оператора CHANGE REPLICATION SOURCE TO.

--max-relay-log-size=size

Размер, при котором сервер автоматически переключает файлы журнала репликации. Если это значение отличное от нуля, журнал репликации переключается автоматически, когда его размер превышает это значение. Если это значение равно нулю (по умолчанию), размер, при котором происходит переключение журнала репликации, определяется значением max_binlog_size. Дополнительную информацию см. в разделе 19.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 (применительно) нужны дополнительные события, прежде чем он сможет удалить журналы репликации. В этом случае поток приемник превышает лимит, пока потоку применительно не станет возможным удалить некоторые журналы репликации, поскольку это не приведет к тупиковой ситуации. Не следует устанавливать --relay-log-space-limit ниже чем в два раза больше значения --max-relay-log-size (или --max-binlog-size, если --max-relay-log-size равно 0). В этом случае есть вероятность, что поток приемник будет ожидать освобождения места, поскольку --relay-log-space-limit превышен, но поток применительно не имеет журнала репликации для очистки и не может удовлетворить поток приемник. Это заставляет поток приемник временно игнорировать --relay-log-space-limit.

--replicate-do-db=db_name

Создаёт фильтр репликации, используя имя базы данных. Такие фильтры также можно создать с помощью CHANGE REPLICATION FILTER REPLICATE_DO_DB.

Этот параметр поддерживает фильтры репликации, специфичные для канала, что позволяет многоисточниковым репликам использовать конкретные фильтры для разных источников. Для настройки фильтра репликации, специфичного для канала, с именем channel_1, используйте --replicate-do-db:channel_1:db_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия являются буквальными двоеточиями. Дополнительную информацию см. в Разделе 19.2.5.4, «Фильтры репликации на основе каналов».

Точное действие этого фильтра репликации зависит от того, используется ли репликация на основе инструкций или на основе строк.

Репликация на основе инструкций. Сообщите потоку репликации 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.%. См. Раздел 19.2.5, «Как серверы оценивают правила фильтрации репликации».

--replicate-ignore-db=db_name

Создаёт фильтр репликации, используя имя базы данных. Такие фильтры также можно создать, используя CHANGE REPLICATION FILTER REPLICATE_IGNORE_DB.

Этот параметр поддерживает фильтры репликации, специфичные для канала, что позволяет многоисточниковым репликам использовать специфические фильтры для различных источников. Чтобы настроить фильтр репликации, специфичный для канала, в канале с именем channel_1, используйте --replicate-ignore-db:channel_1:db_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия — как литеральные двоеточия. Дополнительную информацию см. в разделе 19.2.5.4 «Фильтры репликации, основанные на каналах».

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

Как и --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 «Как сервера оценивают правила фильтрации репликации».

--replicate-do-table=db_name.tbl_name

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

Этот параметр поддерживает фильтры репликации, специфичные для канала, что позволяет многоисточниковым репликам использовать специфические фильтры для различных источников. Чтобы настроить фильтр репликации, специфичный для канала, в канале с именем channel_1, используйте --replicate-do-table:channel_1:db_name.tbl_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия — как литеральные двоеточия. Дополнительную информацию см. в разделе 19.2.5.4 «Фильтры репликации, основанные на каналах».

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

--replicate-ignore-table=db_name.tbl_name

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

Этот параметр поддерживает канальные специфические фильтры репликации, позволяя репликам с несколькими источниками использовать специфические фильтры для разных источников. Чтобы настроить канальный специфический фильтр репликации для канала с именем channel_1, используйте --replicate-ignore-table:channel_1:db_name.tbl_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия — как буквальные двоеточия. См. Раздел 19.2.5.4, «Фильтры репликации на основе каналов» для получения дополнительной информации.

Этот параметр влияет только на заявления, относящиеся к таблицам. Он не влияет на заявления, относящиеся только к другим объектам базы данных, таким как хранимые процедуры. Для фильтрации заявлений, работающих с хранимыми процедурами, используйте один или несколько параметров --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.

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

$> mysqld --replicate-rewrite-db=channel_1:db_name1->db_name2

Если вы используете двоеточие, но не указываете имя канала, параметр настраивает фильтр репликации для канала репликации по умолчанию. См. Раздел 19.2.5.4, «Фильтры репликации на основе каналов» для получения дополнительной информации.

--replicate-same-server-id

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

Когда включено двоичное протоколирование на реплике, сочетание параметров --replicate-same-server-id и --log-replica-updates на реплике может привести к бесконечным циклам в репликации, если сервер является частью циклической топологии репликации. (В MySQL 9.2 двоичное протоколирование включено по умолчанию, а протоколирование обновлений реплики — по умолчанию при включённом двоичном протоколировании). Однако использование глобальных идентификаторов транзакций (GTID) предотвращает эту ситуацию, пропуская выполнение транзакций, которые уже были применены. Если параметр gtid_mode=ON установлен на реплике, вы можете запустить сервер с этим сочетанием параметров, но вы не можете изменить любой другой режим GTID во время работы сервера. Если установлен любой другой режим GTID, сервер не запускается с этим сочетанием параметров.

По умолчанию поток репликации I/O (приёмник) не записывает события двоичного лога в релейный журнал, если они имеют идентификатор сервера реплики (эта оптимизация помогает экономить дисковое пространство). Если вы хотите использовать --replicate-same-server-id, убедитесь, что вы запустили реплику с этим параметром перед тем, как заставить реплику прочитать собственные события, которые вы хотите, чтобы поток репликации SQL (применитель) выполнил.

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

Создаёт фильтр репликации, указывая потоку SQL-репликации (приёмнику) ограничить репликацию операциями, где любая из обновляемых таблиц соответствует заданным шаблонам имени базы данных и таблицы. Шаблоны могут содержать символы подстановки % и _, которые имеют такое же значение, как и для оператора сопоставления шаблонов LIKE. Для указания более одной таблицы используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает для межбазовых обновлений. См. Раздел 19.2.5, «Как серверы оценивают правила фильтрации репликации». Вы также можете создать такой фильтр, выполнив оператор CHANGE REPLICATION FILTER REPLICATE_WILD_DO_TABLE.

Этот параметр поддерживает канальные фильтры репликации, позволяя репликам с несколькими источниками использовать специфические фильтры для разных источников. Для настройки канального фильтра репликации на канале с именем channel_1 используйте --replicate-wild-do-table:channel_1:db_name.tbl_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия — как буквальные двоеточия. Подробнее см. Раздел 19.2.5.4, «Фильтры репликации на основе каналов».

Фильтр репликации, заданный параметром --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-потоком оператора, в котором любая таблица соответствует заданному шаблону. Для указания более одной таблицы для игнорирования используйте этот параметр несколько раз, по одному для каждой таблицы. Это работает для межбазовых обновлений. См. Раздел 19.2.5, «Как серверы оценивают правила фильтрации репликации». Вы также можете создать такой фильтр, выполнив оператор CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE.

Этот параметр поддерживает канальные фильтры репликации, позволяя репликам с несколькими источниками использовать специфические фильтры для разных источников. Для настройки канального фильтра репликации на канале с именем channel_1 используйте --replicate-wild-ignore:channel_1:db_name.tbl_name. В этом случае первая двоеточие интерпретируется как разделитель, а последующие двоеточия — как буквальные двоеточия. Подробнее см. Раздел 19.2.5.4, «Фильтры репликации на основе каналов».

Например, --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-replica-start

--skip-replica-start указывает серверу репликации не запускать потоки ввода-вывода репликации (приемник) и SQL (применитель) при запуске сервера. Чтобы запустить потоки позже, используйте оператор START REPLICA.

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

--skip-slave-start

Устаревшее псевдоним для --skip-replica-start.

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

Устаревший синоним для --replica-skip-errors.

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

Устаревший синоним для --replica-sql-verify-checksum

init_replica

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

init_slave

Устаревшее псевдоним для init_replica.

log_slow_replica_statements

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

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

log_slow_slave_statements

Устаревшее псевдоним для log_slow_replica_statements.

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. См. раздел 19.2.3, «Потоки репликации».

relay_log

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

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

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

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

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

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

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

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

relay_log_basename

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

relay_log_index

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

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

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

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

relay_log_purge

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

relay_log_recovery

Если включена, эта переменная включает автоматическое восстановление журнала ретрансляции сразу после запуска сервера. Процесс восстановления создает новый файл журнала ретрансляции, устанавливает позицию потока SQL (применителя) в этот новый журнал ретрансляции и устанавливает позицию потока ввода-вывода (приемника) в позицию потока применителя. Затем продолжается чтение журнала ретрансляции из источника. Если SOURCE_AUTO_POSITION=1 был установлен для канала репликации с помощью оператора CHANGE REPLICATION SOURCE TO, используемая для запуска репликации исходная позиция может быть получена в соединении, а не назначена в этом процессе.

Когда relay_log_recovery отключена, сервер очищает журнал ретрансляции при запуске, выполняя следующие действия:

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

Для многопоточной реплики (где replica_parallel_workers больше 0) установка --relay-log-recovery при запуске автоматически обрабатывает любые несоответствия и пробелы в последовательности транзакций, которые были выполнены из журнала ретрансляции. Эти пробелы могут возникнуть при использовании репликации на основе позиции файла. (Более подробную информацию см. в Разделе 19.5.1.35, «Репликация и несоответствия транзакций».) Процесс восстановления журнала ретрансляции обрабатывает пробелы тем же способом, что и оператор START REPLICA UNTIL SQL_AFTER_MTS_GAPS. Когда реплика достигает согласованного состояния без пробелов, процесс восстановления журнала ретрансляции переходит к получению дальнейших транзакций из источника, начиная с позиции потока SQL (применителя). Когда используется репликация на основе GTID, многопоточная реплика сначала проверяет, установлено ли SOURCE_AUTO_POSITION в ON, и если это так, пропускает шаг вычисления транзакций, которые следует пропустить или не пропускать, чтобы старые журналы ретрансляции не требовались для процесса восстановления.

relay_log_space_limit

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

replica_checkpoint_group

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

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

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

replica_checkpoint_period

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

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

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

replica_compressed_protocol

replica_compressed_protocol указывает, следует ли использовать сжатие протокола подключения источника/реплики, если обе стороны (источник и реплика) его поддерживают. Если эта переменная отключена (по умолчанию), подключения не сжимаются. Изменения в этой переменной вступают в силу при последующих попытках подключения; это включает в себя выполнение оператора START REPLICA, а также повторные подключения, выполняемые активной репликацией I/O (приёмником).

Сжатие транзакций журнала двоичных логов, включённое системной переменной binlog_transaction_compression, также может использоваться для экономии пропускной способности. Если вы используете сжатие транзакций журнала двоичных логов в сочетании со сжатием протокола, сжатие протокола имеет меньше возможностей воздействия на данные, но всё равно может сжимать заголовки и те события и загрузки транзакций, которые не сжаты. Дополнительную информацию о сжатии транзакций журнала двоичных логов см. в разделе 7.4.4.5 «Сжатие транзакций журнала двоичных логов».

Если replica_compressed_protocol включён, он имеет приоритет над любым SOURCE_COMPRESSION_ALGORITHMS параметром, указанным для оператора CHANGE REPLICATION SOURCE TO. В этом случае подключения к источнику используют zlib сжатие, если оба источни и реплика поддерживают этот алгоритм. Если replica_compressed_protocol отключён, применяется значение SOURCE_COMPRESSION_ALGORITHMS. Дополнительную информацию см. в разделе 6.2.8 «Управление сжатием подключений».

replica_exec_mode

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

Режим IDEMPOTENT предназначен для использования в сценариях репликации с несколькими источниками, циклической репликации и некоторых других специальных сценариях репликации для NDB Cluster Replication. (См. раздел 25.7.10 «NDB Cluster Replication: Взаимная и циклическая репликация» и раздел 25.7.12 «NDB Cluster Replication Разрешение конфликтов» для получения дополнительной информации.) NDB Cluster игнорирует любое явно заданное значение для replica_exec_mode и всегда обрабатывает его как IDEMPOTENT.

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

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

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

replica_load_tmpdir

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

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

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

replica_max_allowed_packet

replica_max_allowed_packet устанавливает максимальный размер пакета в байтах, который могут обрабатывать репликационные SQL (применитель) и I/O (приёмник) потоки. Установка этой переменной вступает в силу немедленно для всех репликационных каналов, включая работающие каналы. Возможно, что источник запишет события журнала двоичных логов, превышающие значение max_allowed_packet после добавления заголовка события. Значение replica_max_allowed_packet должно быть больше значения max_allowed_packet на источнике, чтобы большие обновления с помощью репликации по строкам не приводили к сбою репликации.

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

replica_net_timeout

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

Значение по умолчанию составляет 60 секунд (одна минута). Первая попытка повторного подключения происходит сразу после истечения срока ожидания. Интервал между повторными попытками контролируется опцией SOURCE_CONNECT_RETRY для оператора CHANGE REPLICATION SOURCE TO, а количество попыток повторного подключения ограничено опцией SOURCE_RETRY_COUNT.

Интервал для сигналов о состоянии, предотвращающий истечение срока ожидания соединения при отсутствии данных, если соединение всё ещё активно, управляется опцией SOURCE_HEARTBEAT_PERIOD для оператора CHANGE REPLICATION SOURCE TO. Интервал сигналов о состоянии по умолчанию составляет половину значения replica_net_timeout, и он записывается в хранилище метаданных подключений реплики и отображается в таблице Performance Schema replication_connection_configuration. Обратите внимание, что изменение значения или значения по умолчанию replica_net_timeout не автоматически изменяет интервал сигналов о состоянии, независимо от того, был ли он явно задан или вычислялся по умолчанию. Если срок ожидания соединения изменён, необходимо также выполнить оператор CHANGE REPLICATION SOURCE TO, чтобы скорректировать интервал сигналов о состоянии до соответствующего значения, чтобы он произошёл до истечения срока ожидания соединения.

replica_parallel_type

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

Когда replica_preserve_commit_order включено, необходимо использовать LOGICAL_CLOCK. Многопоточность включена по умолчанию для серверов репликации (replica_parallel_workers=4 по умолчанию), и LOGICAL_CLOCK по умолчанию. (replica_preserve_commit_order также включено по умолчанию.)

При использовании репликации с несколькими уровнями реплик, LOGICAL_CLOCK может обеспечить меньшую параллельность на каждом уровне, удалённом от источника.

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

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

replica_parallel_workers

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

Значение по умолчанию равно 4, что означает, что реплики по умолчанию многопоточные.

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

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

Чтобы отключить параллельное выполнение, установите replica_parallel_workers в 1, в этом случае реплика использует один поток координатора для чтения транзакций и один рабочий поток для их применения, что означает, что транзакции применяются последовательно. Когда replica_parallel_workers равно 1, системные переменные replica_parallel_type и replica_preserve_commit_order не имеют эффекта и игнорируются. Если replica_parallel_workers равно 0, а опция CHANGE REPLICATION SOURCE TO GTID_ONLY включена, реплика имеет один поток координатора и один рабочий поток, точно так же, как если бы replica_parallel_workers было установлено в 1. С одним рабочим потоком системная переменная replica_preserve_commit_order также не имеет эффекта.

Установка replica_parallel_workers не имеет немедленного эффекта, а применяется ко всем последующим операциям START REPLICA.

Многопоточные реплики также поддерживаются NDB Cluster 9.2. Дополнительную информацию см. в Разделе 25.7.11, «Репликация NDB Cluster с использованием многопоточного обработчика».

Увеличение числа рабочих потоков улучшает возможность параллелизма. Как правило, это улучшает производительность до определенного момента, после чего увеличение числа рабочих потоков снижает производительность из-за эффектов одновременного выполнения, таких как конкуренция за блокировки. Идеальное число зависит как от оборудования, так и от рабочей нагрузки; его сложно предсказать и обычно приходится находить путем тестирования. Таблицы без первичных ключей, которые всегда ухудшают производительность, могут оказывать еще более негативное влияние на производительность реплик, имеющих replica_parallel_workers > 1; поэтому убедитесь, что все таблицы имеют первичные ключи перед включением этой опции.

replica_pending_jobs_size_max

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

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

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

replica_preserve_commit_order

Для многопоточных реплик (реплик, для которых replica_parallel_workers установлено значение больше 0), установка replica_preserve_commit_order=ON гарантирует, что транзакции выполняются и подтверждаются на реплике в том же порядке, в котором они появляются в журнале переадресации реплики. Это предотвращает пробелы в последовательности выполненных транзакций из журнала переадресации реплики и сохраняет ту же историю транзакций на реплике, что и на источнике (с ограничениями, указанными ниже). Эта переменная не влияет на реплики, для которых многопоточность не включена.

Многопоточность включена по умолчанию в MySQL 9.2 для серверов реплик (replica_parallel_workers=4 по умолчанию), поэтому replica_preserve_commit_order=ON также является значением по умолчанию, и настройка replica_parallel_type=LOGICAL_CLOCK также имеет значение по умолчанию. Кроме того, настройка replica_preserve_commit_order игнорируется, если replica_parallel_workers установлено в 1, поскольку в этом случае порядок транзакций сохраняется в любом случае.

Для настройки replica_preserve_commit_order=ON не требуется ведение бинарных журналов и журналирование обновлений реплики на реплике, и их можно отключить при необходимости. Для установки replica_preserve_commit_order=ON требуется, чтобы replica_parallel_type было установлено в значение LOGICAL_CLOCK, являющееся значением по умолчанию в MySQL 9.2. Перед изменением значения replica_preserve_commit_order и replica_parallel_type необходимо остановить репликационный SQL поток (для всех каналов репликации, если вы используете несколько каналов репликации).

При установке replica_preserve_commit_order=OFF, транзакции, которые многопоточная реплика применяет параллельно, могут подтверждаться вне порядка. Поэтому проверка самой последней выполненной транзакции не гарантирует, что все предыдущие транзакции из источника были выполнены на реплике. Существует вероятность пробелов в последовательности выполненных транзакций из журнала переадресации реплики. Это имеет последствия для ведения журнала и восстановления при использовании многопоточной реплики. Дополнительную информацию см. в Разделе 19.5.1.35, “Replication and Transaction Inconsistencies”.

При установке replica_preserve_commit_order=ON, выполняющий поток ожидает, пока все предыдущие транзакции не будут подтверждены, прежде чем подтвердить текущую. Пока данный поток ожидает, пока другие потоки не подтвердят свои транзакции, он сообщает свой статус как Waiting for preceding transaction to commit. В этом режиме многопоточная реплика никогда не попадает в состояние, которого не было у источника. Это поддерживает использование репликации для масштабирования чтения. Дополнительную информацию см. в Разделе 19.4.5, “Using Replication for Scale-Out”.

replica_sql_verify_checksum

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

replica_transaction_retries

replica_transaction_retries устанавливает максимальное количество попыток для потоков репликации SQL на однопоточной или многопоточной реплике автоматически повторить неудачные транзакции, прежде чем остановиться. Установка этой переменной вступает в силу для всех каналов репликации немедленно, включая запущенные каналы. Значение по умолчанию равно 10. Установка переменной в 0 отключает автоматический повтор транзакций.

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

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

replica_type_conversions

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

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

replication_optimize_for_static_plugin_config

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

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

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

replication_sender_observe_commit_only

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

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

report_host

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

report_password

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

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

report_port

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

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

report_user

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

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

rpl_read_size

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

Минимальное и значение по умолчанию для rpl_read_size составляет 8192 байта. Значение должно быть кратно 4 КБ. Обратите внимание, что буфер размером с это значение выделяется для каждого потока, который считывает данные из файлов двоичного журнала и файлов ретрансляционного журнала, включая потоки дампа на источниках и потоки координатора на репликах. Поэтому установка большого значения может повлиять на потребление памяти серверами.

rpl_semi_sync_replica_enabled

rpl_semi_sync_replica_enabled управляет тем, включена ли полусинхронная репликация на сервере реплики. Чтобы включить или отключить подключаемый модуль, установите для этой переменной значение ON или OFF (или 1 или 0) соответственно. Значение по умолчанию — OFF.

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

rpl_semi_sync_replica_trace_level

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

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

rpl_semi_sync_slave_enabled

Устаревший синоним для rpl_semi_sync_replica_enabled.

rpl_semi_sync_slave_trace_level

Устаревший синоним для rpl_semi_sync_replica_trace_level.

rpl_stop_replica_timeout

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

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

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

rpl_stop_slave_timeout

Устаревший синоним для rpl_stop_replica_timeout.

skip_replica_start

skip_replica_start указывает серверу реплики не запускать потоки репликации ввода-вывода (приемник) и SQL (применители) при запуске сервера. Чтобы запустить потоки позже, используйте оператор START REPLICA .

Эта системная переменная доступна только для чтения и может быть установлена с помощью ключевого слова PERSIST_ONLY или квалификатора @@persist_only с оператором SET. Параметр командной строки --skip-replica-start также устанавливает эту системную переменную. Вы можете использовать системную переменную вместо параметра командной строки, чтобы обеспечить доступ к этой функции с использованием структуры привилегий сервера MySQL, чтобы администраторам баз данных не требовался привилегированный доступ к операционной системе.

skip_slave_start

Устаревший синоним для --skip-replica-start.

slave_checkpoint_group

Устаревший синоним для replica_checkpoint_group.

slave_checkpoint_period

Устаревший синоним для replica_checkpoint_period.

slave_compressed_protocol

Устаревший псевдоним для replica_compressed_protocol.

slave_exec_mode

Устаревший псевдоним для replica_exec_mode.

slave_load_tmpdir

Устаревший псевдоним для replica_load_tmpdir.

slave_max_allowed_packet

Устаревший псевдоним для replica_max_allowed_packet.

slave_net_timeout

Устаревший псевдоним для replica_net_timeout.

slave_parallel_type

Устаревший псевдоним для replica_parallel_type.

slave_parallel_workers

Устаревший псевдоним для replica_parallel_workers.

slave_pending_jobs_size_max

Устаревший псевдоним для replica_pending_jobs_size_max.

slave_preserve_commit_order

Устаревший псевдоним для replica_preserve_commit_order.

slave_skip_errors

Устаревший псевдоним для replica_skip_errors.

replica_skip_errors

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

slave_sql_verify_checksum

Устаревший псевдоним для replica_sql_verify_checksum.

slave_transaction_retries

Устаревший псевдоним для replica_transaction_retries.

slave_type_conversions

Устаревший псевдоним для replica_type_conversions.

sql_replica_skip_counter

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

Этот параметр несовместим с репликацией на основе GTID и не должен устанавливаться в ненулевое значение, когда установлено gtid_mode=ON. Если необходимо пропустить транзакции при использовании GTID, используйте gtid_executed из источника. Если вы включили назначение GTID на канале репликации с помощью параметра ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS оператора CHANGE REPLICATION SOURCE TO, доступна sql_replica_skip_counter. См. Раздел 19.1.7.3, «Пропуск транзакций».

sql_slave_skip_counter

Устаревший псевдоним для sql_replica_skip_counter.

sync_master_info

Устаревший псевдоним для sync_source_info.

sync_relay_log

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

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

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

sync_relay_log_info

Количество транзакций после которого реплика обновляет хранилище метаданных прикладного модуля. Когда хранилище метаданных прикладного модуля хранится в виде таблицы InnoDB, что является стандартным вариантом, оно обновляется после каждой транзакции, и эта системная переменная игнорируется. Если хранилище метаданных прикладного модуля хранится в файле (устаревший вариант), реплика синхронизирует свой файл relay-log.info на диск (с использованием fdatasync()) после указанного количества транзакций. Значение 0 (ноль) означает, что содержимое файла сбрасывается в операционную систему только операционной системой. Изменение этой переменной вступает в силу для всех каналов репликации немедленно, включая работающие каналы.

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

sync_source_info

sync_source_info определяет количество событий после которых реплика обновляет хранилище метаданных соединения. Когда хранилище метаданных соединения хранится в виде таблицы InnoDB (по умолчанию, оно обновляется после этого числа событий. Если хранилище метаданных соединения хранится в файле (устаревший вариант), реплика синхронизирует свой файл master.info на диск (используя fdatasync()) после этого числа событий. Значение по умолчанию составляет 10000, а нулевое значение означает, что хранилище никогда не обновляется. Изменение этой переменной вступает в силу для всех каналов репликации немедленно, включая работающие каналы.

terminology_use_previous

В MySQL 8.0 были внесены несовместимые изменения в имена инструментов, содержащие термины master, slave и mts (для «Многопоточного раба»), которые были соответственно изменены на source, replica и mta (для «Многопоточного прикладного модуля»). Если эти несовместимые изменения влияют на ваши приложения, установите terminology_use_previous в BEFORE_8_0_26, чтобы заставить сервер MySQL использовать старые версии имен для объектов, указанных в предыдущем списке. Это позволяет инструментам мониторинга, которые полагаются на старые имена, продолжить работу, пока они не будут обновлены для использования новых имен.

MySQL 9.2 обычно отображает REPLICA_SIDE_DISABLED вместо SLAVESIDE_DISABLED в выводе SHOW CREATE EVENT, SHOW EVENTS и запросов к таблице схемы данных Information Schema EVENTS. Вы можете заставить отобразить SLAVESIDE_DISABLED вместо этого, установив terminology_use_previous в BEFORE_8_0_26 или BEFORE_8_2_0.

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

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