Spec-Zone .ru
спецификации, руководства, описания, API
|
Можно использовать mysqld опции и системные переменные, которые описываются в этом разделе, чтобы влиять на работу двоичного журнала так же как управлять, какие операторы пишутся двоичному журналу. Для дополнительной информации о двоичном журнале см. Раздел 5.2.4, "Двоичный Журнал". Для дополнительной информации об использовании параметров сервера MySQL и системных переменных, см. Раздел 5.1.3, "Опции Команды Сервера", и Раздел 5.1.4, "Системные Переменные Сервера".
Опции запуска используются с двоичным журналированием. Следующий список описывает опции запуска для включения и конфигурирования двоичного журнала. Системные переменные, используемые с двоичным журналированием, обсуждаются позже в этом разделе.
Формат командной строки | --binlog-row-event-max-size=# |
||
Формат файла опции | binlog-row-event-max-size |
||
Разрешенные Значения | |||
Диаметр долота платформы | 32 |
||
Ввести | numeric |
||
Значение по умолчанию | 8192 |
||
Диапазон | 256 .. 4294967295 |
||
Разрешенные Значения | |||
Диаметр долота платформы | 64 |
||
Ввести | numeric |
||
Значение по умолчанию | 8192 |
||
Диапазон | 256 .. 18446744073709547520 |
Определите максимальный размер основанного на строке двоичного события журнала в байтах. Строки группируются в события, меньшие чем этот размер если возможный. Значение должно быть кратным числом 256. Значение по умолчанию 8192. См. Раздел 16.1.2, "Форматы Репликации".
Формат командной строки | --log-bin |
||
Формат файла опции | log-bin |
||
Системное Имя переменной | log_bin
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет | ||
Разрешенные Значения | |||
Ввести | file name |
||
Значение по умолчанию | OFF |
Включите двоичному журналированию. Сервер регистрирует все операторы, которые изменяют данные на двоичный журнал, который используется для резервного копирования и репликации. См. Раздел 5.2.4, "Двоичный Журнал".
Значение опции, если дано, является базовым именем для последовательности журнала. Сервер создает
двоичные файлы журнала в последовательности, добавляя числовой суффикс к базовому имени.
Рекомендуется, чтобы Вы определили базовое имя (см. Раздел
C.5.8, "Известные Проблемы в MySQL", по причине). Иначе, использование MySQL
как базовое
имя. host_name
-bin
Когда сервер читает запись из индексного файла, он проверяет, содержит ли запись относительный путь,
и если он делает, относительная часть пути в замененном набором абсолютного пути, используя --log-bin
опция. Абсолютный путь остается неизменным; в таком случае
индексирование должно быть отредактировано вручную, чтобы позволить новому пути или путям
использоваться. (В более старых версиях MySQL ручное вмешательство требовалось, перемещая двоичный
журнал или релейные файлы журнала.) (Ошибка #11745230, Ошибка #12133)
Установка этой опции вызывает log_bin
системная переменная, которая будет установлена в ON
(или 1
), а не к базовому имени. Двоичное
имя файла журнала (с путем) доступно как log_bin_basename
системная переменная.
Формат командной строки | --log-bin-index=name |
||
Формат файла опции | log-bin-index |
||
Разрешенные Значения | |||
Ввести | file name |
||
Значение по умолчанию | OFF |
Индексный файл для двоичных имен файла журнала. См. Раздел 5.2.4,
"Двоичный Журнал". Если Вы опускаете имя файла, и если Вы не определяли один с --log-bin
,
Использование MySQL
как имя файла. host_name
-bin.index
--log-bin-trust-function-creators[={0|1}]
Формат командной строки | --log-bin-trust-function-creators |
||
Формат файла опции | log-bin-trust-function-creators |
||
Системное Имя переменной | log_bin_trust_function_creators
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
Эта опция устанавливает соответствие log_bin_trust_function_creators
системная переменная. Если никакой
параметр не дается, опция устанавливает переменную в 1. log_bin_trust_function_creators
влияет, как MySQL осуществляет
ограничения на сохраненную функцию и триггерное создание. См. Раздел
18.7, "Двоичное Журналирование Сохраненных Программ".
--log-bin-use-v1-row-events[={0|1}]
Формат командной строки | --log-bin-use-v1-row-events[={0|1}] |
||
Формат файла опции | log-bin-use-v1-row-events |
||
Системное Имя переменной | log_bin_use_v1_row_events
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | 0 |
MySQL 5.7 использует двоичные события строки журнала Версии 2, которые не могут быть считаны
выпусками MySQL Server до MySQL 5.6.6. Установка этой опции к 1 причине mysqld, чтобы записать двоичный журнал,
используя события журналирования Версии 1, который является единственной версией двоичных событий
журнала, используемых в предыдущих выпусках, и таким образом производит двоичные журналы, которые
могут быть считаны более старыми ведомыми устройствами. Установка --log-bin-use-v1-row-events
к 0 (значение по умолчанию) заставляет mysqld использовать двоичные события журнала
Версии 2.
Значение, используемое для этой опции, может быть получено из только для чтения log_bin_use_v1_row_events
системная переменная.
Формат командной строки | --log-short-format |
||
Формат файла опции | log-short-format |
||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
Зарегистрируйте меньше информации к двоичному журналу и замедлите журнал запросов, если они были активированы.
Опции выбора оператора. Опции в следующем списке влияют, какие операторы пишутся двоичному журналу, и таким образом отправляются главным сервером репликации его ведомым устройствам. Есть также опции для ведомых серверов, которые управляют, какие операторы, полученные от ведущего устройства, должны быть выполнены или проигнорированы. Для получения дополнительной информации см. Раздел 16.1.4.3, "Ведомые Опции репликации и Переменные".
Формат командной строки | --binlog-do-db=name |
||
Формат файла опции | binlog-do-db |
||
Разрешенные Значения | |||
Ввести | string |
Эта опция влияет на двоичный файл, входящий в систему способ, подобный пути который --replicate-do-db
влияет на репликацию.
Эффекты этой опции зависят от того, используется ли основанный на операторе или основанный на строке
формат журналирования, таким же образом что эффекты --replicate-do-db
зависьте от, или основанная на операторе или
построчная репликация используется. Следует иметь в виду, что формат, используемый, чтобы
зарегистрировать данный оператор, возможно, обязательно не то же самое как обозначенное значением binlog_format
.
Например, операторы DDL такой как CREATE
TABLE
и ALTER
TABLE
всегда регистрируются как операторы, без отношения к формату журналирования в
действительности, таким образом, следующие основанные на операторе правила для --binlog-do-db
всегда применяйтесь в определении, регистрируется ли оператор.
Основанное на операторе журналирование. Только те операторы пишутся двоичному журналу где база
данных значения по умолчанию (то есть, тот, выбранный USE
) db_name
. Чтобы
определить больше чем одну базу данных, используйте эту опцию многократно, однажды для каждой базы
данных; однако, выполнение так не вызывает операторы
перекрестной базы данных такой как UPDATE
быть зарегистрированным, в то время как различная база данных (или никакая
база данных) выбираются.some_db.some_table
SET foo='bar'
Чтобы определить многократные базы данных, следует использовать многократные экземпляры этой опции. Поскольку имена базы данных могут содержать запятые, список будет обработан как имя единственной базы данных, если Вы предоставите список разделенных запятой значений.
Пример того, что не работает, как Вы могли бы ожидать при использовании основанного на операторе
журналирования: Если сервер запускается с --binlog-do-db=sales
и Вы делаете следующие заявления, UPDATE
оператор не
регистрируется:
USE prices;UPDATE sales.january SET amount=amount+1000;
Главная причина для этого "только проверяет, что поведение" базы данных значения по умолчанию состоит в том, что трудно от
одного только оператора знать, должно ли это быть тиражировано (например, если Вы используете
многократную таблицу DELETE
операторы или многократная таблица UPDATE
операторы, которые действуют через многократные базы
данных). Это также быстрее, чтобы проверить только базу данных значения по умолчанию, а не все базы
данных, если нет никакой потребности.
Другой случай, который, возможно, не самоочевиден, происходит, когда данная база данных тиражируется
даже при том, что это не было определено, устанавливая опцию. Если сервер запускается с --binlog-do-db=sales
, следующий UPDATE
оператор регистрируется даже при том, что prices
не был включен, устанавливая --binlog-do-db
:
USE sales;UPDATE prices.discounts SET percentage = percentage + 10;
Поскольку sales
база данных значения по умолчанию когда UPDATE
заявление делается, UPDATE
регистрируется.
Основанное на строке журналирование. Журналирование ограничивается базе данных db_name
. Только изменения к таблицам, принадлежащим db_name
регистрируются; база данных значения по умолчанию
не имеет никакого эффекта на это. Предположите, что сервер запускается с --binlog-do-db=sales
и основанное на строке журналирование в
действительности, и затем следующие операторы выполняются:
USE prices;UPDATE sales.february SET amount=amount+100;
Изменения к february
таблица в sales
база
данных регистрируется в соответствии с UPDATE
оператор; это происходит действительно ли USE
заявление было сделано. Однако, при использовании основанного
на строке формата журналирования и --binlog-do-db=sales
, изменения производятся следующим UPDATE
не регистрируются:
USE prices;UPDATE prices.march SET amount=amount-25;
Даже если USE prices
оператор был изменен на USE
sales
, UPDATE
эффекты оператора все еще не были бы записаны двоичному
журналу.
Другое важное различие в --binlog-do-db
обработка для основанного на операторе журналирования в
противоположность основанному на строке журналированию происходит относительно операторов, которые
обращаются к многократным базам данных. Предположите, что сервер запускается с --binlog-do-db=db1
, и следующие операторы выполняются:
USE db1;UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
Если Вы используете основанное на операторе журналирование, обновления к обеим таблицам пишутся
двоичному журналу. Однако, при использовании основанного на строке формата, только изменения к table1
регистрируются; table2
находится
в различной базе данных, таким образом, она не изменяется UPDATE
. Теперь предположите это, вместо USE
db1
оператор, a USE db4
оператор использовался:
USE db4;UPDATE db1.table1 SET col1 = 10, db2.table2 SET col2 = 20;
В этом случае, UPDATE
оператор не пишется двоичному журналу при использовании
основанного на операторе журналирования. Однако, при использовании основанного на строке
журналирования, изменения к table1
регистрируется, но не это к table2
— другими словами, только изменения к таблицам в базе данных,
названной --binlog-do-db
регистрируются, и выбор базы данных значения по умолчанию не имеет никакого эффекта на это
поведение.
Формат командной строки | --binlog-ignore-db=name |
||
Формат файла опции | binlog-ignore-db |
||
Разрешенные Значения | |||
Ввести | string |
Эта опция влияет на двоичный файл, входящий в систему способ, подобный пути который --replicate-ignore-db
влияет на репликацию.
Эффекты этой опции зависят от того, используется ли основанный на операторе или основанный на строке
формат журналирования, таким же образом что эффекты --replicate-ignore-db
зависьте от, или основанная на операторе или
построчная репликация используется. Следует иметь в виду, что формат, используемый, чтобы
зарегистрировать данный оператор, возможно, обязательно не то же самое как обозначенное значением binlog_format
.
Например, операторы DDL такой как CREATE
TABLE
и ALTER
TABLE
всегда регистрируются как операторы, без отношения к формату журналирования в
действительности, таким образом, следующие основанные на операторе правила для --binlog-ignore-db
всегда применяйтесь в определении, регистрируется ли оператор.
Основанное на операторе журналирование. Говорит серверу не регистрировать любой оператор где
база данных значения по умолчанию (то есть, тот, выбранный USE
) db_name
.
До MySQL 5.7.2, эта опция, вызванная любые операторы, содержащие полностью определенные имена
таблиц, которые не будут зарегистрированы, если не было никакой определенной базы данных значения по
умолчанию (то есть, когда SELECT
DATABASE()
возвратился NULL
). В MySQL 5.7.2 и позже, когда нет никакой базы данных
значения по умолчанию, нет --binlog-ignore-db
опции применяются, и такие
операторы всегда регистрируются. (Ошибка #11829838, Ошибка #60188)
Основанный на строке формат. Говорит серверу не регистрировать обновления к любым таблицам в
базе данных db_name
. Текущая база данных не имеет никакого
эффекта.
При использовании основанного на операторе журналирования не работает следующий пример, как Вы могли
бы ожидать. Предположите, что сервер запускается с --binlog-ignore-db=sales
и Вы делаете следующие заявления:
USE prices;UPDATE sales.january SET amount=amount+1000;
UPDATE
оператор зарегистрирован такой случай потому что --binlog-ignore-db
применяется только к базе данных значения по умолчанию (определенный USE
оператор). Поскольку sales
база
данных была определена явно в операторе, оператор не фильтровался. Однако, при использовании
основанного на строке журналирования, UPDATE
эффекты оператора не пишутся двоичному журналу, что означает что никакие
изменения для sales.january
таблица регистрируется; в этом экземпляре,
--binlog-ignore-db=sales
причины все изменения, произведенные в таблицах в копии
ведущего устройства sales
база данных, которая будет проигнорирована в
целях двоичного журналирования.
Чтобы определить больше чем одну базу данных, чтобы проигнорировать, используйте эту опцию многократно, однажды для каждой базы данных. Поскольку имена базы данных могут содержать запятые, список будет обработан как имя единственной базы данных, если Вы предоставите список разделенных запятой значений.
Недопустимо использовать эту опцию, если Вы используете обновления перекрестной базы данных, и Вы не хотите, чтобы эти обновления были зарегистрированы.
Опции контрольной суммы. MySQL 5.7 поддерживает чтение и запись двоичных контрольных сумм журнала. Они включаются, используя эти две опции, перечисленные здесь:
--binlog-checksum={NONE|CRC32}
Формат командной строки | --binlog-checksum=type |
||
Формат файла опции | binlog-checksum |
||
Разрешенные Значения | |||
Ввести | string |
||
Значение по умолчанию | CRC32 |
||
Допустимые Значения | NONE |
||
CRC32 |
Включение этой опции заставляет ведущее устройство писать контрольные суммы для событий, записанных
двоичному журналу. Набор к NONE
отключить, или имя алгоритма, который
будет использоваться для того, чтобы генерировать контрольные суммы; в настоящий момент только
контрольные суммы CRC32 поддерживаются, и CRC32 является значением по умолчанию.
--master-verify-checksum={0|1}
Формат командной строки | --master-verify-checksum=name |
||
Формат файла опции | master-verify-checksum |
||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | OFF |
Включение этой опции заставляет ведущее устройство проверять события от двоичного журнала, используя контрольные суммы, и останавливаться с ошибкой в случае несоответствия. Отключенный по умолчанию.
Чтобы управлять чтением контрольных сумм ведомым устройством (от реле) журнал, используйте --slave-sql-verify-checksum
опция.
Тестирование и отладка опций. Следующие двоичные опции журнала используются в тестировании репликации и отладке. Они не предназначаются для использования в нормальном функционировании.
Формат командной строки | --max-binlog-dump-events=# |
||
Формат файла опции | max-binlog-dump-events |
||
Разрешенные Значения | |||
Ввести | numeric |
||
Значение по умолчанию | 0 |
Эта опция используется внутренне тестовым комплектом MySQL для тестирования репликации и отладки.
Формат командной строки | --sporadic-binlog-dump-fail |
||
Формат файла опции | sporadic-binlog-dump-fail |
||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
Эта опция используется внутренне тестовым комплектом MySQL для тестирования репликации и отладки.
--binlog-rows-query-log-events
Формат командной строки | --binlog-rows-query-log-events |
||
Формат файла опции | binlog-rows-query-log-events |
||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
Эта опция включает binlog_rows_query_log_events
.
Системные переменные используются с двоичным журналом. Следующий
список описывает системные переменные для того, чтобы управлять двоичным журналированием. Они могут быть
установлены при запуске сервера, и некоторые из них могут быть изменены при использовании времени выполнения SET
. Параметры сервера, используемые, чтобы управлять двоичным
журналированием, перечисляются ранее в этом разделе.
Системное Имя переменной | log_bin
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет |
Включается ли двоичный журнал. Если --log-bin
опция используется, тогда значение этой переменной ON
; иначе это OFF
. Эта переменная сообщает
только относительно состояния двоичного журналирования (включил или отключил); это фактически не
сообщает о значении который --log-bin
устанавливается.
Формат командной строки | --log-slave-updates |
||
Формат файла опции | log_slave_updates |
||
Системное Имя переменной | log_slave_updates
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
Должны ли обновления, полученные ведомым сервером от главного сервера, быть зарегистрированы к собственному двоичному журналу ведомого устройства. Двоичное журналирование должно быть позволено на ведомом устройстве для этой переменной иметь любой эффект. См. Раздел 16.1.4, "Репликация и Двоичные Опции Журналирования и Переменные".
Формат командной строки | --binlog_cache_size=# |
||
Формат файла опции | binlog_cache_size |
||
Системное Имя переменной | binlog_cache_size
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Диаметр долота платформы | 32 |
||
Ввести | numeric |
||
Значение по умолчанию | 32768 |
||
Диапазон | 4096 .. 4294967295 |
||
Разрешенные Значения | |||
Диаметр долота платформы | 64 |
||
Ввести | numeric |
||
Значение по умолчанию | 32768 |
||
Диапазон | 4096 .. 18446744073709547520 |
Размер кэша, чтобы содержать изменения к двоичному журналу во время транзакции. Двоичный кэш журнала
выделяется для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы
хранения и если у сервера есть двоичный включенный журнал (--log-bin
опция). Если Вы часто используете большие транзакции,
можно увеличить этот размер кэша, чтобы получить лучшую производительность. Binlog_cache_use
и Binlog_cache_disk_use
переменные состояния могут быть полезными
для настройки размера этой переменной. См. Раздел 5.2.4, "Двоичный
Журнал".
binlog_cache_size
устанавливает размер для кэша транзакции только;
размером кэша оператора управляют binlog_stmt_cache_size
системная переменная.
Системное Имя переменной | binlog_checksum
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | string |
||
Значение по умолчанию | CRC32 |
||
Допустимые Значения | NONE |
||
CRC32 |
Когда включено, эта переменная заставляет ведущее устройство писать контрольную сумму для каждого
события в двоичном журнале. binlog_checksum
поддерживает значения NONE
(отключенный) и CRC32
. Значение по
умолчанию CRC32
.
Когда binlog_checksum
отключается (значение NONE
), сервер проверяет, что пишет только полные события в двоичный
журнал при записи и проверяя длину события (а не контрольная сумма) для каждого события.
Изменение значения этой переменной заставляет двоичный журнал быть повернутым; контрольные суммы всегда не пишутся всему двоичному файлу журнала, и никогда только части одного.
Установка этой переменной на ведущем устройстве к значению, нераспознанному ведомым устройством,
заставляет ведомое устройство устанавливать свое собственное binlog_checksum
значение к NONE
, и
остановить репликацию с ошибкой. (Ошибка #13553750, Ошибка #61096), Если обратная совместимость с
более старыми ведомыми устройствами является беспокойством, можно хотеть установить значение явно в
NONE
.
binlog_direct_non_transactional_updates
Формат командной строки | --binlog_direct_non_transactional_updates[=value] |
||
Формат файла опции | binlog_direct_non_transactional_updates |
||
Системное Имя переменной | binlog_direct_non_transactional_updates
|
||
Переменный Контекст | Глобальная переменная, Сеанс | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | OFF |
Из-за проблем параллелизма, ведомое устройство может стать непоследовательным, когда транзакция содержит обновления и к транзакционным и к нетранзакционным таблицам. MySQL пытается сохранить причинную связь среди этих операторов при записи нетранзакционных операторов в кэш транзакции, который сбрасывается на фиксацию. Однако, проблемы возникают, когда модификации, сделанные к нетранзакционным таблицам от имени транзакции сразу, становятся видимыми к другим соединениям, потому что эти изменения не могут быть сразу записаны в двоичный журнал.
binlog_direct_non_transactional_updates
переменная предлагает одно
возможное обходное решение этой проблеме. По умолчанию эта переменная отключается. Включение binlog_direct_non_transactional_updates
причины обновляют к
нетранзакционным таблицам, которые будут записаны непосредственно двоичному журналу, а не кэшу
транзакции.
binlog_direct_non_transactional_updates
работы только для операторов,
которые тиражируются, используя основанный на операторе двоичный формат журналирования;
то есть, это работает только когда значение binlog_format
STATEMENT
, или когда
binlog_format
MIXED
и данный
оператор тиражируется, используя основанный на операторе формат. Эта переменная не имеет никакого
эффекта, когда двоичный формат журнала ROW
, или когда binlog_format
устанавливается в MIXED
и данный оператор тиражируется, используя основанный на строке
формат.
Прежде, чем включить этой переменной, следует удостовериться, что нет никаких
зависимостей между транзакционными и нетранзакционными таблицами; примером такой зависимости был
бы оператор INSERT INTO myisam_table SELECT * FROM innodb_table
.
Иначе, такие операторы, вероятно, заставят ведомое устройство отклоняться от ведущего
устройства.
В MySQL 5.7 эта переменная не имеет никакого эффекта, когда двоичный формат журнала ROW
или MIXED
. (Ошибка #51291)
Формат командной строки | --binlog-format=format |
||
Формат файла опции | binlog-format |
||
Системное Имя переменной | binlog_format
|
||
Переменный Контекст | Глобальная переменная, Сеанс | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | enumeration |
||
Значение по умолчанию | STATEMENT |
||
Допустимые Значения | ROW |
||
STATEMENT |
|||
MIXED |
Эта переменная устанавливает двоичный формат журналирования, и может быть любым из STATEMENT
, ROW
, или MIXED
.
См. Раздел
16.1.2, "Форматы Репликации". binlog_format
устанавливается --binlog-format
опция при запуске, или binlog_format
переменная во времени выполнения.
В то время как можно изменить формат журналирования во времени выполнения, не рекомендуется, чтобы Вы изменили это, в то время как
репликация является продолжающейся. Это должно частично к факту, что ведомые устройства не чтят
ведущее устройство binlog_format
установка; данный MySQL Server может изменить
только свой собственный формат журналирования.
В MySQL 5.7 формат значения по умолчанию STATEMENT
.
Вы должны иметь SUPER
полномочие установить или глобальную переменную или сеанс binlog_format
значение.
Управление правил, когда изменения к этой переменной вступают в силу и сколько времени эффект
длится, является тем же самым что касается других системных переменных сервера MySQL. См. Раздел 13.7.4,"SET
Синтаксис", для получения дополнительной информации.
Когда MIXED
определяется, основанная на операторе репликация
используется, за исключением случаев, где только построчная репликация, как гарантируют, приведет к
надлежащим результатам. Например, это происходит, когда операторы содержат определяемые
пользователем функции (UDF) или UUID()
функция. Исключение к этому правилу - это MIXED
всегда использует основанную на операторе репликацию для
сохраненных функций и триггеров.
Есть исключения, когда невозможно переключить формат репликации во времени выполнения:
Изнутри сохраненной функции или триггера.
Если сеанс находится в настоящий момент в режиме построчной репликации и имеет открытые временные таблицы.
Изнутри транзакции.
Попытка переключить формат в те случаи приводит к ошибке.
Двоичный формат журнала влияет на поведение следующих параметров сервера:
Эти эффекты обсуждаются подробно в описаниях отдельных опций.
Системное Имя переменной | binlog_max_flush_queue_time
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | numeric |
||
Значение по умолчанию | 0 |
||
Диапазон | 0 .. 100000 |
Сколько времени в микросекундах, чтобы продолжить читать транзакции из очереди сброса перед
продолжением групповой фиксации (и синхронизировать журнал к диску, если sync_binlog
больше чем 0). Если значение 0 (значение по
умолчанию), нет никакого тайм-аута, и сервер продолжает читать новые транзакции, пока очередь не
пуста.
Обычно, binlog_max_flush_queue_time
может остаться установленным в 0. Если
серверные процессы большое количество соединений (например, 100 или больше) и много коротких
транзакций с требованиями низкой задержки, может быть полезно установить значение, больше чем 0,
чтобы вызвать более частые сбросы к диску.
Системное Имя переменной | binlog_order_commits
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | ON |
Если эта переменная включается (значение по умолчанию), транзакции фиксируются в том же самом порядке, который они пишутся двоичному журналу. Если отключено, транзакции могут фиксироваться параллельно. В некоторых случаях отключение этой переменной могло бы произвести инкремент производительности.
Формат командной строки | --binlog-row-image=image_type |
||
Формат файла опции | binlog_row_image |
||
Системное Имя переменной | binlog_row_image=image_type |
||
Переменный Контекст | Глобальная переменная, Сеанс | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | enumeration |
||
Значение по умолчанию | full |
||
Допустимые Значения | full (Зарегистрируйте все столбцы), |
||
minimal (Зарегистрируйте только
измененные столбцы, и столбцы должны были идентифицировать строки),
|
|||
noblob (Зарегистрируйте все
столбцы, за исключением ненужного BLOB и столбцов TEXT),
|
В построчной репликации MySQL каждое событие изменения строки содержит два изображения, "перед" изображением, столбцы которого являются соответствующими против, ища строку, которая будет обновлена, и "после" изображения, содержащего изменения. Обычно, MySQL регистрирует все строки (то есть, все столбцы) и для прежде и после изображений. Однако, не строго необходимо включать каждый столбец в оба изображения, и мы можем часто сохранять диск, память, и сетевое использование, регистрируя только те столбцы, которые фактически требуются.
Удаляя строку, только исходный вид записи регистрируется, так как нет никаких измененных значений, чтобы распространить после удаления. Вставляя строку, только после того, как изображение регистрируется, так как нет никакой существующей строки, которая будет соответствующей. Только, когда обновление строки и прежде и после изображений, требуемых, и оба записанные двоичному журналу.
Для исходного вида записи необходимо только, чтобы минимальный набор столбцов, требуемых однозначно
определять строки, был зарегистрирован. Если у таблицы, содержащей строку, есть первичный ключ, то
только столбец первичного ключа или столбцы пишутся двоичному журналу. Иначе, если у таблицы есть
уникальный ключ, все чей столбцы NOT NULL
, тогда только столбцы в
уникальном ключе должны быть зарегистрированными. (Если у таблицы нет ни первичного ключа, ни
уникального ключа ни с кем NULL
столбцы, тогда все столбцы должны
использоваться в исходном виде записи, и зарегистрированы.) В после изображения, необходимо
зарегистрировать только столбцы, которые фактически изменились.
Можно заставить сервер регистрировать все или минимальные строки, используя binlog_row_image
системная переменная. Эта переменная фактически принимает одно из трех возможных значений, как
показано в следующем списке:
full
: Зарегистрируйте все столбцы и в
исходном виде записи и в после изображения.
minimal
: Зарегистрируйте только те столбцы
в исходном виде записи, которые обязаны идентифицировать строку, которая будет изменена;
зарегистрируйте только те столбцы в после изображения, которые фактически изменяются.
noblob
: Зарегистрируйте все столбцы (то же
самое как full
), за исключением BLOB
и TEXT
столбцы, которые не обязаны идентифицировать строки,
или которые не изменились.
Значение по умолчанию full
.
В MySQL 5.5 и более ранней, всей строке изображения всегда используются для обоих исходных видов записи и после изображений. Если Вы должны тиражировать от более нового ведущего устройства в ведомое устройство рабочий MySQL 5.5 или ранее, ведущее устройство должно всегда использовать это значение.
При использовании minimal
или noblob
,
удаляет и обновления, как гарантируют, будут работать правильно на данную таблицу, если и только
если следующие условия являются истиной и для источника и для целевых таблиц:
Все столбцы должны присутствовать и в том же самом порядке; каждый столбец должен использовать тот же самый тип данных в качестве своего дубликата в другой таблице.
У таблиц должны быть идентичные определения первичного ключа.
(Другими словами таблицы должны быть идентичными с возможным исключением, индексирует, которые не являются частью первичных ключей таблиц.)
Если эти условия не соблюдают, возможно, что значения столбцов первичного ключа в целевой таблице могут оказаться недостаточными, чтобы обеспечить уникальное соответствие для удаления или обновления. В этом случае никакое предупреждение или ошибка не выпускаются; ведущее устройство и ведомое устройство тихо отклоняются, таким образом повреждая непротиворечивость.
Установка этой переменной не имеет никакого эффекта, когда двоичный формат журналирования STATEMENT
. Когда binlog_format
MIXED
, установка для binlog_row_image
применяется к изменениям, которые регистрируются,
используя основанный на строке формат, но эту установку никакого эффекта на изменения,
зарегистрированные как операторы.
Установка binlog_row_image
или на глобальном или на сеансовом уровне не
вызывает неявную фиксацию; это означает, что эта переменная может быть заменена, в то время как
транзакция происходит, не влияя на транзакцию.
Системное Имя переменной | binlog_rows_query_log_events
|
||
Переменный Контекст | Глобальная переменная, Сеанс | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | FALSE |
binlog_rows_query_log_events
системная переменная влияет на основанное на строке журналирование только. Когда включено, это
заставляет MySQL Server писать информационные события журнала, такие как события журнала запросов
строки в его двоичный журнал. Эта информация может использоваться для отладки и связанных целей;
такой как получение исходного запроса, выпущенного на ведущем устройстве, когда это не может быть
восстановлено от обновлений строки.
Эти события обычно игнорируются программами MySQL, читая двоичный журнал и так не вызовите проблемы, тиражируясь или восстанавливая от резервного копирования.
Формат командной строки | --binlog_stmt_cache_size=# |
||
Формат файла опции | binlog_stmt_cache_size |
||
Системное Имя переменной | binlog_stmt_cache_size
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Диаметр долота платформы | 32 |
||
Ввести | numeric |
||
Значение по умолчанию | 32768 |
||
Диапазон | 4096 .. 4294967295 |
||
Разрешенные Значения | |||
Диаметр долота платформы | 64 |
||
Ввести | numeric |
||
Значение по умолчанию | 32768 |
||
Диапазон | 4096 .. 18446744073709547520 |
Эта переменная определяет размер кэша для двоичного журнала, чтобы содержать нетранзакционные
заявления, сделанные во время транзакции. Разделите двоичную транзакцию журнала, и кэши оператора
выделяются для каждого клиента, если сервер поддерживает какие-либо транзакционные механизмы
хранения и если у сервера есть двоичный включенный журнал (--log-bin
опция). Если Вы часто используете большие
нетранзакционные операторы во время транзакций, можно увеличить этот размер кэша, чтобы получить
лучшую производительность. Binlog_stmt_cache_use
и Binlog_stmt_cache_disk_use
переменные состояния могут быть
полезными для настройки размера этой переменной. См. Раздел 5.2.4,
"Двоичный Журнал".
binlog_cache_size
системная переменная устанавливает размер для кэша транзакции.
Системное Имя переменной | log_bin_basename
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет | ||
Разрешенные Значения | |||
Ввести | file name |
||
Значение по умолчанию | datadir + '/' + hostname + '-bin' |
Содержит имя и полный путь к двоичному файлу журнала. В отличие от этого log_bin
системная переменная, log_bin_basename
отражает набор имени с --log-bin
параметр сервера.
Формат командной строки | --log-bin-use-v1-row-events[={0|1}] |
||
Формат файла опции | log_bin_use_v1_row_events |
||
Системное Имя переменной | log_bin_use_v1_row_events
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Нет | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | 0 |
Шоу, используется ли двоичное журналирование Версии 2. Значение 1 шоу, что сервер пишет двоичный журнал, используя события журналирования Версии 1 (единственная версия двоичных событий журнала, используемых в предыдущих выпусках), и таким образом создание двоичного журнала, который может быть считан более старыми ведомыми устройствами. 0 указывает, что двоичные события журнала Версии 2 используются.
Эта переменная только для чтения. Чтобы переключиться между двоичным двоичным журналированием
события Версии 1 и Версии 2, необходимо перезапустить mysqld с --log-bin-use-v1-row-events
опция.
Системное Имя переменной | master_verify_checksum
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | boolean |
||
Значение по умолчанию | OFF |
Включение этой переменной заставляет ведущее устройство исследовать контрольные суммы, читая из
двоичного журнала. master_verify_checksum
отключается по умолчанию; в
этом случае ведущее устройство использует длину события от двоичного журнала, чтобы проверить
события, так, чтобы только полные события были считаны из двоичного журнала.
Формат командной строки | --max_binlog_cache_size=# |
||
Формат файла опции | max_binlog_cache_size |
||
Системное Имя переменной | max_binlog_cache_size
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | numeric |
||
Значение по умолчанию | 18446744073709547520 |
||
Диапазон | 4096 .. 18446744073709547520 |
Если транзакция требует больше чем это много байтов памяти, сервер генерирует Составную транзакцию требуемые больше чем 'max_binlog_cache_size' байты ошибки хранения. Минимальное значение 4096. Минимальное значение 4096. Максимальное возможное значение 16EB (эксабайты). Максимальное рекомендуемое значение составляет 4 Гбайт; это - то, вследствие того, что MySQL в настоящий момент не может работать с двоичными позициями журнала, больше чем 4 Гбайт.
max_binlog_cache_size
устанавливает размер для кэша транзакции только;
верхним пределом для кэша оператора управляют max_binlog_stmt_cache_size
системная переменная.
В MySQL 5.7, видимости к сеансам max_binlog_cache_size
соответствия тот
из binlog_cache_size
системная переменная; другими словами изменяя его эффекты значения только новые сеансы, которые
запускаются после значения, изменяются.
Формат командной строки | --max_binlog_size=# |
||
Формат файла опции | max_binlog_size |
||
Системное Имя переменной | max_binlog_size
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | numeric |
||
Значение по умолчанию | 1073741824 |
||
Диапазон | 4096 .. 1073741824 |
Если запись к двоичному журналу заставляет текущий размер файла журнала превышать значение этой переменной, сервер вращается, двоичные журналы (закрывает текущий файл и открывает следующий). Минимальное значение составляет 4096 байтов. Максимальное и значение по умолчанию составляет 1 Гбайт.
Транзакция пишется в одном блоке двоичному журналу, таким образом, это никогда не разделяется между
несколькими двоичными журналами. Поэтому, если у Вас есть большие транзакции, Вы могли бы видеть
двоичные файлы журнала, больше чем max_binlog_size
.
Если max_relay_log_size
0, значение max_binlog_size
применяется к релейным журналам также.
Формат командной строки | --max_binlog_stmt_cache_size=# |
||
Формат файла опции | max_binlog_stmt_cache_size |
||
Системное Имя переменной | max_binlog_stmt_cache_size
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Ввести | numeric |
||
Значение по умолчанию | 18446744073709547520 |
||
Диапазон | 4096 .. 18446744073709547520 |
Если нетранзакционные операторы в пределах транзакции требуют больше чем это много байтов памяти, сервер генерирует ошибку. Минимальное значение 4096. Максимальные и значения по умолчанию составляют 4 Гбайт на 32-разрядных платформах и 16EB (эксабайты) на 64-разрядных платформах.
max_binlog_stmt_cache_size
устанавливает размер для кэша оператора
только; верхним пределом для кэша транзакции управляют исключительно max_binlog_cache_size
системная переменная.
Формат командной строки | --sync-binlog=# |
||
Формат файла опции | sync_binlog |
||
Системное Имя переменной | sync_binlog
|
||
Переменный Контекст | Глобальная переменная | ||
Динамическая Переменная | Да | ||
Разрешенные Значения | |||
Диаметр долота платформы | 32 |
||
Ввести | numeric |
||
Значение по умолчанию | 0 |
||
Диапазон | 0 .. 4294967295 |
||
Разрешенные Значения | |||
Диаметр долота платформы | 64 |
||
Ввести | numeric |
||
Значение по умолчанию | 0 |
||
Диапазон | 0 .. 18446744073709547520 |
Если значение этой переменной больше чем 0, сервер MySQL синхронизирует свой двоичный журнал с
диском (использование fdatasync()
) после sync_binlog
группы фиксации пишутся двоичному журналу. Значение
по умолчанию sync_binlog
0, который не делает никакой синхронизации с диском — в этом случае, сервер полагается на
операционную систему, чтобы время от времени сбрасывать содержание двоичного журнала что касается
любого другого файла. Значение 1 является самым безопасным выбором, потому что в случае
катастрофического отказа Вы теряете самое большее одну группу фиксации от двоичного журнала. Однако,
это - также самый медленный выбор (если у диска нет поддержанного батареей кэша, который делает
синхронизацию очень быстро).