16.1.4.3. Ведомые Опции репликации и Переменные

--abort-slave-event-count

Когда эта опция устанавливается в некоторое положительное целое число value кроме 0 (значение по умолчанию) это влияет на поведение репликации следующим образом: После того, как ведомый поток SQL запустился, value событиям журнала разрешают быть выполненными; после этого ведомый поток SQL больше не получает события, так же, как если бы сетевое соединение от ведущего устройства было сокращено. Ведомый поток продолжает работать, и вывод от SHOW SLAVE STATUS дисплеи Yes в обоих Slave_IO_Running и Slave_SQL_Running столбцы, но никакие дальнейшие события читаются из релейного журнала.

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

--disconnect-slave-event-count

Эта опция используется внутренне тестовым комплектом MySQL для тестирования репликации и отладки.

--log-slave-updates

Обычно, ведомое устройство не регистрирует к его собственному двоичному журналу обновлений, которые получаются от главного сервера. Эта опция говорит ведомому устройству регистрировать обновления, выполняемые его потоком SQL к его собственному двоичному журналу. Для этой опции, чтобы иметь любой эффект, ведомое устройство должно также быть запущено с --log-bin опция, чтобы включить двоичному журналированию. До MySQL 5.5 сервер не запустился бы при использовании --log-slave-updates опция, также не запуская сервер с --log-bin опция, и перестала бы работать с ошибкой; в MySQL 5.6 сгенерировано только предупреждение. (Ошибка #44663) --log-slave-updates используется, когда Вы хотите объединить сервера репликации в цепочку. Например, Вы могли бы хотеть установить сервера репликации, используя это расположение:

A -> B -> C

Здесь, A служит ведущим устройством для ведомого устройства B, и B служит ведущим устройством для ведомого устройства C. Для этого, чтобы работать, B должно быть и ведущее устройство и ведомое устройство. Следует запустить обоих A и B с --log-bin включать двоичному журналированию, и B с --log-slave-updates опция так, чтобы обновления, полученные из A регистрируются B к его двоичному журналу.

--log-slow-slave-statements

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

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

--log-warnings[=level]

Эта опция заставляет сервер печатать больше сообщений к журналу ошибок о том, что это делает. Относительно репликации сервер генерирует предупреждения, что это преуспело в том, чтобы повторно соединиться после отказа сети/соединения, и сообщает Вам относительно как каждый ведомый запущенный поток. Эта опция включается по умолчанию; чтобы отключить это, использовать --skip-log-warnings. Если значение больше чем 1, прерванные соединения пишутся журналу ошибок, и ошибки доступа запрещен для новых попыток подключения пишутся. См. Раздел C.5.2.11, "Коммуникационные Ошибки и Прерванные Соединения".

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

--master-info-file=file_name

Имя, чтобы использовать для файла, в котором ведомое устройство записывает информацию о ведущем устройстве. Имя по умолчанию master.info в каталоге данных. Для получения информации о формате этого файла см. Раздел 16.2.2.2, "Ведомые Журналы Состояния".

--master-retry-count=count

Число раз, которое ведомое устройство пытается соединить с ведущим устройством перед отказом. Повторно соединяется предпринимаются с промежутками установленные MASTER_CONNECT_RETRY опция CHANGE MASTER TO оператор (значение по умолчанию 60). Повторно соединяется инициированы, когда данные читают к ведомому времени согласно --slave-net-timeout опция. Значение по умолчанию 86400. Значение 0 означает "бесконечный"; ведомое устройство пытается соединиться навсегда.

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

--max-relay-log-size=size

Размер, в котором сервер поворачивает релейные файлы журнала автоматически. Для получения дополнительной информации см. Раздел 16.2.2, "Реле репликации и Журналы Состояния". Размер значения по умолчанию составляет 1 Гбайт.

--read-only

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

--relay-log=file_name

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

Из-за способа, которым MySQL анализирует параметры сервера, если Вы определяете эту опцию, следует предоставить значение; базовое имя значения по умолчанию используется, только если опция фактически не определяется. Если Вы используете --relay-log опция, не определяя значение, неожиданное поведение, вероятно, закончится; это поведение зависит от других используемых опций, порядок, в котором они определяются, и определяются ли они на командной строке или в файле опции. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера, см. Раздел 4.2.3, "Определение Опций Программы".

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

Запускаясь с MySQL 5.6.5, когда сервер читает запись из индексного файла, он проверяет, содержит ли запись относительный путь. Если это делает, относительная часть пути в замененном набором абсолютного пути, используя --relay-log опция. Абсолютный путь остается неизменным; в таком случае индексирование должно быть отредактировано вручную, чтобы позволить новому пути или путям использоваться. До MySQL 5.6.5 ручное вмешательство требовалось, перемещая двоичный журнал или релейные файлы журнала. (Ошибка #11745230, Ошибка #12133)

Можно найти --relay-log опция, полезная в выполнении следующих задач:

Начиная с MySQL 5.6.2, можно получить релейное имя файла журнала (и путь) от relay_log_basename системная переменная.

--relay-log-index=file_name

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

Из-за способа, которым MySQL анализирует параметры сервера, если Вы определяете эту опцию, следует предоставить значение; базовое имя значения по умолчанию используется, только если опция фактически не определяется. Если Вы используете --relay-log-index опция, не определяя значение, неожиданное поведение, вероятно, закончится; это поведение зависит от других используемых опций, порядок, в котором они определяются, и определяются ли они на командной строке или в файле опции. Для получения дополнительной информации о том, как MySQL обрабатывает параметры сервера, см. Раздел 4.2.3, "Определение Опций Программы".

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

--relay-log-info-file=file_name

Имя, чтобы использовать для файла, в котором ведомое устройство записывает информацию о релейных журналах. Имя по умолчанию relay-log.info в каталоге данных. Для получения информации о формате этого файла см. Раздел 16.2.2.2, "Ведомые Журналы Состояния".

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

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

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

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

До MySQL 5.6.6, если эта опция включается для многопоточного ведомого устройства, и ведомых сбоев с ошибками, невозможно выполниться CHANGE MASTER TO на том ведомом устройстве. В MySQL 5.6.6 или позже, можно использовать START SLAVE UNTIL SQL_AFTER_MTS_GAPS гарантировать, что любые разрывы в релейном журнале обрабатываются; после выполнения этого оператора можно тогда использовать CHANGE MASTER TO приводить это ведомое устройство к сбою нового ведущего устройства. (Ошибка #13893363)

--relay-log-space-limit=size

Эти места опции верхний предел полного размера в байтах всего реле входят в систему ведомое устройство. Значение 0 не означает "предела." Это полезно для ведомого узла сервера, который ограничил дисковое пространство. Когда предел достигается, поток ввода-вывода прекращает читать двоичные события журнала из главного сервера, пока поток SQL не нагнал и удалил некоторые неиспользованные релейные журналы. Отметьте, что этот предел не является абсолютным: есть случаи, где поток SQL нуждается в большем количестве событий прежде, чем он сможет удалить релейные журналы. В этом случае поток ввода-вывода превышает предел, пока для потока SQL не становится возможно удалить некоторые релейные журналы, потому что не выполнение так вызвало бы мертвую блокировку. Недопустимо установить --relay-log-space-limit к меньше чем дважды значение --max-relay-log-size (или --max-binlog-size если --max-relay-log-size 0). В этом случае есть шанс, что поток ввода-вывода ожидает свободного пространства потому что --relay-log-space-limit превышается, но поток SQL не имеет никакого релейного журнала, чтобы произвести чистку и неспособен удовлетворить поток ввода-вывода. Это вынуждает поток ввода-вывода проигнорировать --relay-log-space-limit временно.

--replicate-do-db=db_name

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

Основанная на операторе репликация. Скажите ведомому потоку SQL ограничивать репликацию операторами где база данных значения по умолчанию (то есть, тот, выбранный USE) db_name. Чтобы определить больше чем одну базу данных, используйте эту опцию многократно, однажды для каждой базы данных; однако, выполнение так не тиражирует операторы перекрестной базы данных такой как UPDATE some_db.some_table SET foo='bar' в то время как различная база данных (или никакая база данных) выбираются.

Пример того, что не работает, как Вы могли бы ожидать при использовании основанной на операторе репликации: Если ведомое устройство запускается с --replicate-do-db=sales и Вы делаете следующие заявления на ведущем устройстве, UPDATE оператор не тиражируется:

USE prices;UPDATE sales.january SET amount=amount+1000;

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

Построчная репликация. Говорит ведомому потоку SQL ограничивать репликацию базой данных db_name. Только таблицы, принадлежащие db_name изменяются; текущая база данных не имеет никакого эффекта на это. Предположите, что ведомое устройство запускается с --replicate-do-db=sales и построчная репликация в действительности, и затем следующие операторы выполняются на ведущем устройстве:

USE prices;UPDATE sales.february SET amount=amount+100;

february таблица в sales база данных на ведомом устройстве изменяется в соответствии с UPDATE оператор; это происходит действительно ли USE заявление было сделано. Однако, делание следующих заявлений на ведущем устройстве не имеет никакого эффекта на ведомое устройство при использовании построчной репликации и --replicate-do-db=sales:

USE prices;UPDATE prices.march SET amount=amount-25;

Даже если оператор USE prices были изменены на USE sales, UPDATE эффекты оператора все еще не были бы тиражированы.

Другое важное различие, в как --replicate-do-db обрабатывается в основанной на операторе репликации в противоположность построчной репликации, происходит относительно операторов, которые обращаются к многократным базам данных. Предположите, что ведомое устройство запускается с --replicate-do-db=db1, и следующие операторы выполняются на ведущем устройстве:

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

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

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

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

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

--replicate-ignore-db=db_name

Как с --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 база данных, которая будет проигнорирована ведомым устройством.

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

Недопустимо использовать эту опцию, если Вы используете обновления перекрестной базы данных, и Вы не хотите, чтобы эти обновления были тиражированы. См. Раздел 16.2.3, "Как Серверы Оценивают Правила Фильтрации Репликации".

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

--replicate-do-table=db_name.tbl_name

Говорит ведомому потоку SQL ограничивать репликацию указанной таблицей. Чтобы определить больше чем одну таблицу, используйте эту опцию многократно, однажды для каждой таблицы. Это работает и на обновления перекрестной базы данных и на обновления базы данных значения по умолчанию, в отличие от --replicate-do-db. См. Раздел 16.2.3, "Как Серверы Оценивают Правила Фильтрации Репликации".

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

--replicate-ignore-table=db_name.tbl_name

Говорит ведомому потоку SQL не тиражировать любой оператор, который обновляет указанную таблицу, даже если какие-либо другие таблицы могли бы быть обновлены тем же самым оператором. Чтобы определить больше чем одну таблицу, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновления перекрестной базы данных, в отличие от --replicate-ignore-db. См. Раздел 16.2.3, "Как Серверы Оценивают Правила Фильтрации Репликации".

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

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

Говорит ведомому устройству преобразовывать базу данных значения по умолчанию (то есть, тот, выбранный USE) к to_name если это было from_name на ведущем устройстве. Только на операторы, включающие таблицы, влияют (не операторы такой как CREATE DATABASE, DROP DATABASE, и ALTER DATABASE), и только если from_name база данных значения по умолчанию на ведущем устройстве. Это не работает на обновления перекрестной базы данных. Чтобы определить многократные перезаписи, используйте эту опцию многократно. Сервер использует первый с a from_name значение, которое соответствует. Преобразование имени базы данных делается перед --replicate-* правила тестируются.

Если Вы используете эту опцию на командной строке и">"символ является особенным для Вашего интерпретатора команд, заключите значение опции в кавычки. Например:

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

--replicate-same-server-id

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

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

Говорит ведомому потоку ограничивать репликацию операторами, где любая из обновленных таблиц соответствует указанную базу данных и образцы имени таблицы. Образцы могут содержать"%"и"_"подстановочные символы, у которых есть то же самое значение что касается LIKE оператор сопоставления с образцом. Чтобы определить больше чем одну таблицу, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновления перекрестной базы данных. См. Раздел 16.2.3, "Как Серверы Оценивают Правила Фильтрации Репликации".

Эта опция применяется к таблицам, представлениям, и триггерам. Это не применяется к хранимым процедурам и функциям, или событиям. Чтобы фильтровать операторы, работающие на последних объектах, используйте один или больше --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. Если Вы используете опцию на командной строке, Вы, возможно, должны были бы удвоить наклонные черты влево или заключить значение опции в кавычки, в зависимости от Вашего интерпретатора команд. Например, с оболочкой удара, Вы должны были бы ввести --replicate-wild-do-table=my\\_own\\%db.

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

Говорит ведомому потоку не тиражировать оператор, где любая таблица соответствует данный подстановочный образец. Чтобы определить больше чем одну таблицу, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой таблицы. Это работает на обновления перекрестной базы данных. См. Раздел 16.2.3, "Как Серверы Оценивают Правила Фильтрации Репликации".

Пример: --replicate-wild-ignore-table=foo%.bar% не тиражирует обновления, которые используют таблицу, где имя базы данных запускается с foo и имя таблицы запускается с bar.

Для получения информации о том, как работает соответствие, см. описание --replicate-wild-do-table опция. Правила для включения литеральных подстановочных символов в значении опции являются тем же самым что касается --replicate-wild-ignore-table также.

--report-host=host_name

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

--report-password=password

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

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

--report-port=slave_port_num

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

До MySQL 5.6.5 значение по умолчанию для этой опции было 3306. В MySQL 5.6.5 и позже, показанное значение является номером порта, фактически используемым ведомым устройством (Ошибка #13333431). Это изменение также влияет на значение по умолчанию, выведенное на экран SHOW SLAVE HOSTS.

--report-user=user_name

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

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

--show-slave-auth-info

Выведите на экран ведомые имена пользователей и пароли в выводе SHOW SLAVE HOSTS на главном сервере для ведомых устройств, запущенных с --report-user и --report-password опции.

--slave-checkpoint-group=#

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

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

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

--slave-checkpoint-group был добавлен в MySQL 5.6.3.

--slave-checkpoint-period=#

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

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

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

--slave-checkpoint-period был добавлен в MySQL 5.6.3.

--slave-parallel-workers

Определяет номер потоков раба для того, чтобы выполнить события репликации (транзакции) параллельно. Установка этой переменной к 0 (значение по умолчанию) отключает параллельное выполнение. Максимум 1024.

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

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

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

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

Эта опция была добавлена в MySQL 5.6.3.

--slave-pending-jobs-size-max=#

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

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

Эта опция была добавлена в MySQL 5.6.3.

--skip-slave-start

Говорит ведомому серверу не запускать ведомые потоки, когда сервер запускается. Чтобы запустить потоки позже, используйте a START SLAVE оператор.

--slave_compressed_protocol={0|1}

Если эта опция устанавливается в 1, используйте сжатие для ведомого/основного протокола если и ведомое устройство и основная поддержка она. Значение по умолчанию 0 (никакое сжатие).

--slave-load-tmpdir=file_name

Имя каталога, где ведомое устройство создает временные файлы. Эта опция по умолчанию равна значению tmpdir системная переменная. Когда ведомый поток SQL тиражирует a LOAD DATA INFILE оператор, это извлекает файл, который будет загружен из релейного журнала во временные файлы, и затем загружает их в таблицу. Если файл, загруженный на ведущем устройстве, огромен, временные файлы на ведомом устройстве огромны, также. Поэтому, могло бы быть желательно использовать эту опцию, чтобы сказать ведомому устройству помещать временные файлы в каталог, расположенный в некоторой файловой системе, у которой есть много свободного места. В этом случае релейные журналы огромны также, таким образом, Вы могли бы также хотеть использовать --relay-log опция, чтобы поместить реле входит в систему та файловая система.

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

slave-max-allowed-packet=bytes

В MySQL 5.6.6 и позже, эта опция устанавливает максимальный пакетный размер в байтах для ведомого SQL и потоков ввода-вывода, так, чтобы большие обновления, используя построчную репликацию не заставили репликацию перестать работать потому что превышенное обновление max_allowed_packet. (Ошибка #12400221, Ошибка #60926)

Соответствующая переменная сервера slave_max_allowed_packet всегда имеет значение, которое является положительным целочисленным кратным числом 1024; если Вы устанавливаете это в некоторое значение, которое не является таким кратным числом, значение автоматически округляется в меньшую сторону до следующего самого высокого кратного числа 1024. (Например, если Вы запускаете сервер с --slave-max-allowed-packet=10000, используемое значение 9216; установка 0 как значение заставляет 1024 использоваться.) Усечение, предупреждающее, выпускается в таких случаях.

Максимум (и значение по умолчанию) значение 1073741824 (1 Гбайт); минимум 1024.

--slave-net-timeout=seconds

Число секунд, чтобы ожидать большего количества данных от ведущего устройства перед ведомым устройством считает соединение поврежденным, прерывает чтение, и пытается повторно соединиться. Первая повторная попытка сразу происходит после тайм-аута. Интервалом между повторениями управляют MASTER_CONNECT_RETRY опция для CHANGE MASTER TO оператор, и число перепопыток подключения ограничиваются --master-retry-count опция. Значение по умолчанию составляет 3600 секунд (один час).

slave-rows-search-algorithms=list

Готовя пакеты строк для основанного на строке использования журналирования и репликации slave_allow_batching, эта опция управляет, как строки ищутся соответствия — то есть, используется ли хеширование для поисков, используя первичный или уникальный ключ, некоторый другой ключ, или никакой ключ вообще. Эта опция берет список разделенных запятой значений любых 2 (или возможно 3) значения от списка INDEX_SCAN, TABLE_SCAN, HASH_SCAN. Список не должен быть заключен в кавычки, но не должен содержать пробелы, используются ли кавычки. Возможные комбинации (списки) и их эффекты показывают в следующей таблице:

Порядок, в котором алгоритмы определяются в списке, не имеет никакого значения в порядке, в котором они выводятся на экран a SELECT или SHOW VARIABLES оператор (который является тем же самым как используемым в таблице, только показанной ранее).The значение по умолчанию TABLE_SCAN,INDEX_SCAN, что означает, что все поискы, которые могут использовать, индексируют, действительно используют их, и поискы ни с кем индексируют сканирования таблицы использования.

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

Эта опция была добавлена в MySQL 5.6.6.

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

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

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

Для кодов ошибки следует использовать числа, обеспеченные сообщением об ошибке в Вашем ведомом журнале ошибок и в выводе SHOW SLAVE STATUS. Приложение C, Ошибки, Коды ошибки, и Типичные проблемы, перечисляет коды ошибки сервера.

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

MySQL 5.6 поддерживает дополнительное краткое значение ddl_exists_errors, который эквивалентен списку кода ошибки 1007,1008,4050,1051,1054,1060,1061,1068,1094,1146.

Примеры:

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

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

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

Эта опция была добавлена в MySQL 5.6.2.

--master-host

--master-user

--master-password

--master-port

--master-connect-retry

--master-ssl

--master-ssl-ca

--master-ssl-capath

--master-ssl-cert

--master-ssl-cipher

--master-ssl-key

slave_allow_batching

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

init_slave

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

log_slow_slave_statements

Когда медленный журнал запросов включается, эта переменная позволяет регистрировать для запросов, которые взяли больше чем long_query_time секунды, чтобы выполниться на ведомом устройстве. Эта переменная была добавлена в MySQL 5.6.11.

master_info_repository

Установка этой переменной определяет, регистрирует ли ведомое устройство основное состояние и информацию о соединении к a FILE (master.info), или к a TABLE (mysql.slave_master_info).

Эта переменная была добавлена в MySQL 5.6.2.

relay_log

Имя релейного файла журнала.

relay_log_basename

Содержит имя и полный путь к релейному файлу журнала.

relay_log_basename системная переменная была добавлена в MySQL 5.6.2.

relay_log_index

Имя релейного индексного файла журнала. Имя по умолчанию host_name-relay-bin.index в каталоге данных, где host_name имя ведомого сервера.

relay_log_info_file

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

relay_log_info_repository

Эта переменная определяет, пишется ли позиция ведомого устройства в релейных журналах a FILE (relay-log.info) или к a TABLE (mysql.slave_relay_log_info).

Эта переменная была добавлена в MySQL 5.6.2.

relay_log_recovery

сразу включает автоматическому релейному восстановлению журнала после запуска сервера, что означает, что ведомое устройство репликации отбрасывает все необработанные релейные журналы и получает их от ведущего устройства репликации. В MySQL 5.6.5 и ранее, было возможно изменить эту глобальную переменную динамически; начинаясь с MySQL 5.6.6, это только для чтения. (Ошибка #13840948) Независимо от версии MySQL Server, ее значение может быть изменено, запуская ведомое устройство с --relay-log-recovery опция, которая должна использоваться после катастрофического отказа на ведомом устройстве репликации, чтобы гарантировать, что не возможно поврежденные релейные журналы обрабатываются, и должен использоваться, чтобы гарантировать отказоустойчивое ведомое устройство. Значение по умолчанию 0 (отключено).

Когда relay_log_recovery включается и ведомое устройство остановилось из-за ошибок, с которыми встречаются, работая в многопоточном режиме, невозможно выполниться CHANGE MASTER TO если есть какие-либо разрывы в журнале. Начиная с MySQL 5.6.6, следует использовать START SLAVE UNTIL SQL_AFTER_MTS_GAPS гарантировать, что все разрывы обрабатываются прежде, чем переключиться назад на однопоточный режим или выполнить a CHANGE MASTER TO оператор.

slave_checkpoint_group

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

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

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

slave_checkpoint_group был добавлен в MySQL 5.6.3.

slave_checkpoint_period

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

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

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

slave_checkpoint_period был добавлен в MySQL 5.6.3.

slave_compressed_protocol

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

slave_exec_mode

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

slave_load_tmpdir

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

slave_max_allowed_packet

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

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

slave_max_allowed_packet может также быть установлен при запуске, используя --slave-max-allowed-packet опция.

slave_net_timeout

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

slave_parallel_workers

Определяет номер потоков раба для того, чтобы выполнить события репликации (транзакции) параллельно. Установка этой переменной к 0 (значение по умолчанию) отключает параллельное выполнение. Максимум 1024.

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

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

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

Эта переменная была добавлена в MySQL 5.6.3.

slave_pending_jobs_size_max

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

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

slave_pending_jobs_size_max был добавлен в MySQL 5.6.3.

slave_rows_search_algorithms

Готовя пакеты строк для основанного на строке использования журналирования и репликации slave_allow_batching, slave_rows_search_algorithms переменная управляет, как строки ищутся соответствия — то есть, используется ли хеширование для поисков, используя первичный или уникальный ключ, используя некоторый другой ключ, или не используя ключа вообще. Эта опция берет список разделенных запятой значений по крайней мере 2 значений от списка INDEX_SCAN, TABLE_SCAN, HASH_SCAN. Значение, ожидаемое как строка, таким образом, значение должно быть заключено в кавычки. Кроме того, значение не должно содержать пробелы. Возможные комбинации (списки) и их эффекты показывают в следующей таблице:

Порядок, в котором алгоритмы определяются в списке, не имеет никакого значения в порядке, в котором они выводятся на экран a SELECT или SHOW VARIABLES оператор, как показано здесь:

mysql> SET GLOBAL
                    slave_rows_search_algorithms = "INDEX_SCAN,TABLE_SCAN";Query OK, 0 rows affected (0.00 sec)mysql> SHOW VARIABLES LIKE '%algorithms%';+------------------------------+-----------------------+| Variable_name                | Value                 |+------------------------------+-----------------------+| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |+------------------------------+-----------------------+1 row in set (0.00 sec)mysql> SET GLOBAL slave_rows_search_algorithms = "TABLE_SCAN,INDEX_SCAN";Query OK, 0 rows affected (0.00 sec)mysql> SHOW VARIABLES LIKE '%algorithms%';+------------------------------+-----------------------+| Variable_name                | Value                 |+------------------------------+-----------------------+| slave_rows_search_algorithms | TABLE_SCAN,INDEX_SCAN |+------------------------------+-----------------------+1 row in set (0.00 sec)

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

Определение INDEX_SCAN,TABLE_SCAN,HASH_SCAN имеет тот же самый эффект как определение INDEX_SCAN,HASH_SCAN. Чтобы использовать хеширование для любых поисков, которое не использует первичный или уникальный ключ, устанавливает эту переменную в INDEX_SCAN,HASH_SCAN. Чтобы вызвать хеширование для всех поисков, установите это в TABLE_SCAN,HASH_SCAN.

Эта переменная была добавлена в MySQL 5.6.6.

slave_skip_errors

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

slave_sql_verify_checksum

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

slave_sql_verify_checksum был добавлен в MySQL 5.6.2.

slave_transaction_retries

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

Транзакции не могут быть повторены при использовании многопоточного ведомого устройства. Другими словами, всякий раз, когда slave_parallel_workers больше чем 0, slave_transaction_retries обрабатывается как равный 0, и не может быть изменен.

slave_type_conversions

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

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

sql_slave_skip_counter

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

Эта опция является несовместимой с GTID-на-основе репликацией, и не должна быть установлена в ненулевое значение когда --gtid-mode=ON. В MySQL 5.6.10 и позже, пытаясь сделать так определенно отвергается. (Ошибка #15833516), Если Вы должны пропустить транзакции, используя GTIDs, использовать gtid_executed от ведущего устройства вместо этого. См. Вводящие пустые транзакции для информации о том, как сделать это.

sync_master_info

Эффекты этой переменной на ведомом устройстве репликации зависят от ли ведомое устройство master_info_repository устанавливается в FILE или TABLE, как объяснено в следующих абзацах.

master_info_repository = FILE. Если значение sync_master_info больше чем 0, ведомое устройство синхронизирует master.info файл к диску (использование fdatasync()) после каждого sync_master_info события. Если это 0, сервер MySQL не выполняет синхронизации master.info файл к диску; вместо этого, сервер полагается на операционную систему, чтобы периодически сбрасывать ее содержание как с любым другим файлом.

master_info_repository = TABLE. Если значение sync_master_info больше чем 0, ведомое устройство обновляет свою основную таблицу репозитария информации после каждого sync_master_info события. Если это 0, таблица никогда не обновляется.

Значение по умолчанию для sync_master_info 10000 с MySQL 5.6.6, 0 перед этим.

sync_relay_log

Если значение этой переменной больше чем 0, сервер MySQL синхронизирует свой релейный журнал с диском (использование fdatasync()) после каждого sync_relay_log записи к релейному журналу. Есть одна запись к релейному журналу на оператор, если автоматическая фиксация включается, и одна запись на транзакцию иначе. Значение 0 не делает никакой синхронизации с диском — в этом случае, сервер полагается на операционную систему, чтобы время от времени сбрасывать содержание релейного журнала что касается любого другого файла. Значение 1 является самым безопасным выбором, потому что в случае катастрофического отказа Вы теряете самое большее один оператор или транзакцию от релейного журнала. Однако, это - также самый медленный выбор (если у диска нет поддержанного батареей кэша, который делает синхронизацию очень быстро). Значение по умолчанию 10000 с MySQL 5.6.6, 0 перед этим.

sync_relay_log_info

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

Значение по умолчанию для sync_relay_log_info 10000 с MySQL 5.6.6, 0 перед этим.

--master-info-repository={FILE|TABLE}

Эта опция заставляет сервер писать свой основной журнал информации в файл или таблицу. Имя значений по умолчанию файла к master.info; можно поменять имя файла, используя --master-info-file параметр сервера.

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

--master-info-repository опция была добавлена в MySQL 5.6.2.

--relay-log-info-repository={FILE|TABLE}

Эта опция заставляет сервер регистрировать свою релейную информацию журнала к файлу или таблице. Имя значений по умолчанию файла к relay-log.info; можно поменять имя файла, используя --relay-log-info-file параметр сервера.

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

--relay-log-info-repository опция была добавлена в MySQL 5.6.2.