--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 8.4 двоичное логгирование включено по умолчанию, а логгирование обновлений реплики — по умолчанию, когда включено двоичное логгирование.) Однако использование глобальных идентификаторов транзакций (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.34, «Репликация и несоответствия транзакций».) Процесс восстановления журнала ретрансляции обрабатывает пробелы с использованием того же метода, что и оператор 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 8.4, режим STRICT является значением по умолчанию.

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

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

replica_load_tmpdir

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

Когда поток репликации SQL реплицирует оператор LOAD DATA, он извлекает загружаемый файл из журнала репликации в временные файлы и затем загружает их в таблицу. Если загружаемый на источнике файл большой, то временные файлы на реплике также будут большими. Поэтому рекомендуется использовать этот параметр для указания реплике разместить временные файлы в каталоге на файловой системе с большим объёмом свободного места. В этом случае журналы репликации также будут большими, поэтому вам также может потребоваться установить системную переменную 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 и записывается в репозиторий метаданных соединения реплики, отображаясь в таблице 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 8.4. Дополнительную информацию см. в Разделе 25.7.11, «NDB Cluster Replication Using the Multithreaded Applier».

Увеличение числа рабочих потоков улучшает потенциальную параллельность. Как правило, это улучшает производительность до определенного момента, после которого увеличение числа рабочих потоков снижает производительность из-за таких эффектов конкурентности, как конкуренция за блокировки. Идеальное число зависит как от аппаратного обеспечения, так и от рабочей нагрузки; его трудно предсказать и обычно его нужно определять путем тестирования. Таблицы без первичных ключей, которые всегда ухудшают производительность, могут оказывать еще большее негативное влияние на реплики с 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 8.4 для серверов репликации (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 8.4. Перед изменением значения replica_preserve_commit_order и replica_parallel_type необходимо остановить поток SQL репликации (для всех каналов репликации, если вы используете несколько каналов репликации).

Когда replica_preserve_commit_order=OFF установлено, параллельно применяемые транзакции многопоточной реплики могут подтверждаться в случайном порядке. Поэтому проверка последней выполненной транзакции не гарантирует, что все предыдущие транзакции со стороны источника были выполнены на реплике. Существует вероятность пробелов в последовательности транзакций, которые были выполнены из журнала пересылки реплики. Это имеет последствия для ведения журнала и восстановления при использовании многопоточной реплики. Дополнительную информацию см. в разделе Раздел 19.5.1.34, «Несоответствия репликации и транзакций».

Когда replica_preserve_commit_order=ON установлено, выполняющий поток ожидает, пока все предыдущие транзакции не будут подтверждены перед подтверждением. Пока данный поток ожидает, пока другие потоки не подтвердят свои транзакции, он сообщает свой статус как Waiting for preceding transaction to commit. В этом режиме многопоточная реплика никогда не попадает в состояние, в котором не находился источник. Это поддерживает использование репликации для масштабирования чтения. Дополнительную информацию см. в разделе Раздел 19.4.5, «Использование репликации для масштабирования».

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 8.4 обычно отображает REPLICA_SIDE_DISABLED вместо SLAVESIDE_DISABLED в выводе SHOW CREATE EVENT, SHOW EVENTS и запросов к таблице схемы информации EVENTS. Вы можете заставить отображаться SLAVESIDE_DISABLED, установив terminology_use_previous в BEFORE_8_0_26 или BEFORE_8_2_0.

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

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