花都网站设计,宁波静态网站建设,大数据培训班,angularjs 做团购网站官网地址#xff1a; MySQL :: MySQL Replication :: 2.6.4 Binary Logging Options and Variables
欢迎关注留言#xff0c;我是收集整理小能手#xff0c;工具翻译#xff0c;仅供参考#xff0c;笔芯笔芯. MySQL 复制 / ... / 二进制日志记录选项和变量 2.6.4 二进…官网地址 MySQL :: MySQL Replication :: 2.6.4 Binary Logging Options and Variables
欢迎关注留言我是收集整理小能手工具翻译仅供参考笔芯笔芯. MySQL 复制 / ... / 二进制日志记录选项和变量 2.6.4 二进制日志记录选项和变量 与二进制日志记录一起使用的启动选项 与二进制日志记录一起使用的系统变量 您可以使用本节中描述的mysqld选项和系统变量来影响二进制日志的操作以及控制将哪些语句写入二进制日志。有关二进制日志的其他信息请参阅二进制日志。有关使用 MySQL 服务器选项和系统变量的其他信息请参阅服务器命令选项和 服务器系统变量。 与二进制日志记录一起使用的启动选项 以下列表描述了用于启用和配置二进制日志的启动选项。本节稍后讨论与二进制日志记录一起使用的系统变量。 --binlog-row-event-max-sizeN 命令行格式--binlog-row-event-max-size#类型整数默认值8192最小值256最大值64 位平台18446744073709551615最大值32 位平台4294967295单元字节 指定基于行的二进制日志事件的最大大小以字节为单位。如果可能行将被分组为小于此大小的事件。该值应该是 256 的倍数。默认值为 8192。请参见第 5.1 节 “复制格式”。 --log-bin[base_name] 命令行格式--log-binfile_name类型文件名 启用二进制日志记录。启用二进制日志记录后服务器会将所有更改数据的语句记录到二进制日志中用于备份和复制。二进制日志是具有基本名称和数字扩展名的文件序列。有关二进制日志的格式和管理的信息请参阅二进制日志。 如果您为该--log-bin 选项提供一个值则该值将用作日志序列的基本名称。服务器通过在基本名称中添加数字后缀来按顺序创建二进制日志文件。在 MySQL 5.7 中基本名称默认为 host_name-bin使用主机的名称。建议您指定基本名称以便无论默认名称如何更改都可以继续使用相同的二进制日志文件名。 二进制日志文件的默认位置是数据目录。您可以使用该--log-bin选项来指定备用位置方法是将前导绝对路径名添加到基本名称以指定不同的目录。当服务器从跟踪已使用的二进制日志文件的二进制日志索引文件中读取条目时它会检查该条目是否包含相对路径。如果是则路径的相对部分将替换为使用以下命令设置的绝对路径 --log-bin选项。二进制日志索引文件中记录的绝对路径保持不变在这种情况下必须手动编辑索引文件以启用新路径或要使用的路径。在旧版本的 MySQL 中每当重新定位二进制日志或中继日志文件时都需要手动干预。Bug #11745230、Bug #12133 设置此选项会导致 log_bin系统变量设置为ON(或1)而不是基本名称。二进制日志文件基本名称和任何指定的路径都可用作 log_bin_basename系统变量。 如果指定该--log-bin选项而不指定 server_id系统变量则不允许启动服务器。错误#11763963错误#56739 当服务器上使用GTID时如果异常关闭后重新启动服务器时未启用二进制日志记录则可能会丢失部分GTID从而导致复制失败。在正常关闭时当前二进制日志文件中的 GTID 集保存在 mysql.gtid_executed桌子。在异常关闭但未发生这种情况之后在恢复期间GTID 将从二进制日志文件添加到表中前提是二进制日志记录仍处于启用状态。如果在服务器重新启动时禁用二进制日志记录服务器将无法访问二进制日志文件来恢复 GTID因此无法启动复制。正常关闭后可以安全地禁用二进制日志记录。 如果要禁用服务器启动时的二进制日志记录但保持--log-bin设置不变可以在启动时指定 --skip-log-bin 或 --disable-log-bin 选项。在选项后指定选项 --log-bin使其优先。当二进制日志记录被禁用时 log_bin系统变量设置为 OFF。 --log-bin-index[file_name] 命令行格式--log-bin-indexfile_name系统变量log_bin_index范围全球的动态的不类型文件名 二进制日志索引文件的名称其中包含二进制日志文件的名称。默认情况下它具有与使用选项为二进制日志文件指定的值相同的位置和基本名称--log-bin 加上扩展名.index. 如果不指定--log-bin则默认二进制日志索引文件名为 binlog.index. 如果省略文件名并且不指定 1 --log-bin则默认二进制日志索引文件名为 host_name-bin.index使用主机的名称。 有关二进制日志的格式和管理的信息请参阅二进制日志。 语句选择选项。 以下列表中的选项会影响哪些语句写入二进制日志从而由复制源服务器发送到其副本。副本服务器还有一些选项可以控制应执行或忽略从源接收的哪些语句。有关详细信息请参见 第 2.6.3 节 “副本服务器选项和变量”。 --binlog-do-dbdb_name 命令行格式--binlog-do-dbname类型细绳 此选项影响二进制日志记录的方式与 --replicate-do-db影响复制的方式类似。 此选项的效果取决于是否使用基于语句或基于行的日志记录格式就像 的效果取决于 --replicate-do-db是否使用基于语句或基于行的复制一样。您应该记住用于记录给定语句的格式不一定与 值指示的格式相同 binlog_format。例如DDL 语句如CREATE TABLE和 ALTER TABLE始终记录为语句而不考虑有效的日志记录格式因此以下基于语句的规则 for--binlog-do-db 始终适用于确定是否记录该语句。 基于语句的日志记录。 只有那些语句才会写入默认数据库即由 选定的数据库 USE为 的 二进制日志db_name。要指定多个数据库请多次使用此选项每个数据库一次但是这样做不会 导致跨数据库语句例如在选择不同数据库或没有数据库时被记录。 UPDATE some_db.some_table SET foobar 警告 要指定多个数据库您 必须使用此选项的多个实例。由于数据库名称可以包含逗号因此如果您提供以逗号分隔的列表则该列表将被视为单个数据库的名称。 使用基于语句的日志记录时可能无法正常工作的示例如果服务器启动时 --binlog-do-dbsales发出以下语句则 不会UPDATE记录该语句 USE prices;
UPDATE sales.january SET amountamount1000; 这种“只检查默认数据库”行为 的主要原因是仅从语句中很难知道是否应该复制它例如如果您正在使用多表 DELETE语句或多表UPDATE 语句跨多个数据库。如果不需要仅检查默认数据库而不是所有数据库也更快。 另一种可能不明显的情况发生在复制给定数据库时即使在设置选项时未指定该数据库。如果服务器以以下方式启动则即使设置时未包含--binlog-do-dbsales以下 语句也会记录以下语句 UPDATEprices--binlog-do-db USE sales;
UPDATE prices.discounts SET percentage percentage 10; 因为是发出语句sales时的默认数据库所以会记录下来。 UPDATEUPDATE 基于行的日志记录。 日志记录仅限于数据库 db_name。db_name仅记录所属表的更改默认数据库对此没有影响。假设服务器启动并且启用了 --binlog-do-dbsales基于行的日志记录然后执行以下语句 USE prices;
UPDATE sales.february SET amountamount100; 按照语句记录数据库february中表 的变化无论是否 发表该声明都会发生这种情况。但是当使用基于行的日志记录格式 和 时 不会记录 以下内容所做的更改salesUPDATEUSE--binlog-do-dbsalesUPDATE USE prices;
UPDATE prices.march SET amountamount-25; 即使该USE prices语句更改为USE sales该 UPDATE语句的效果仍然不会写入二进制日志。 处理基于语句的日志记录与基于行的日志记录的另一个重要区别 --binlog-do-db在于引用多个数据库的语句。假设服务器启动为 --binlog-do-dbdb1并执行以下语句 USE db1;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 10, db2.table2.col2 20; 如果您使用基于语句的日志记录则两个表的更新都会写入二进制日志。table1但是当使用基于行的格式时仅记录 的更改 table2位于不同的数据库中因此它不会被UPDATE. 现在假设使用了以下语句 USE db1 而不是该语句USE db4 USE db4;
UPDATE db1.table1, db2.table2 SET db1.table1.col1 10, db2.table2.col2 20; 在这种情况下UPDATE 使用基于语句的日志记录时该语句不会写入二进制日志。table1但是当使用基于行的日志记录时会记录对的更改但不会table2记录对的更改换句话说仅记录对名为 by 的数据库中的表的更改 --binlog-do-db并且默认数据库的选择对此行为没有影响。 --binlog-ignore-dbdb_name 命令行格式--binlog-ignore-dbname类型细绳 此选项影响二进制日志记录的方式与 --replicate-ignore-db影响复制的方式类似。 此选项的效果取决于是否使用基于语句或基于行的日志记录格式就像 的效果取决于 --replicate-ignore-db是否使用基于语句或基于行的复制一样。您应该记住用于记录给定语句的格式不一定与 值指示的格式相同 binlog_format。例如DDL 语句如CREATE TABLE和 ALTER TABLE始终记录为语句而不考虑有效的日志记录格式因此以下基于语句的规则 for --binlog-ignore-db始终适用于确定是否记录该语句。 基于语句的日志记录。 告诉服务器不要记录默认数据库即由 选定的数据库 USE为 的 任何语句db_name。 在 MySQL 5.7.2 之前如果没有指定默认数据库即 返回 时此选项会导致不记录任何包含完全限定表名的语句。在 MySQL 5.7.2 及更高版本中当没有默认数据库时不会 应用任何选项并且始终记录此类语句。错误#11829838错误#60188 SELECT DATABASE()NULL--binlog-ignore-db 基于行的格式。 告诉服务器不要记录对数据库中任何表的更新db_name。当前数据库没有影响。 使用基于语句的日志记录时以下示例不会按您的预期工作。假设服务器已启动并且 --binlog-ignore-dbsales您发出以下语句 USE prices;
UPDATE sales.january SET amountamount1000; 在这种情况下 会记录 该UPDATE语句 因为仅适用于默认数据库由该 语句确定。由于 在语句中显式指定了数据库因此该语句未被过滤。但是当使用基于行的日志记录时 语句的效果不会写入二进制日志这意味着不会 记录对表的任何更改在这种情况下 会导致对源副本中的表进行的所有更改--binlog-ignore-dbUSEsalesUPDATEsales.january--binlog-ignore-dbsalessales 出于二进制日志记录的目的而忽略的数据库。 要指定多个要忽略的数据库请多次使用此选项每个数据库一次。由于数据库名称可以包含逗号因此如果您提供以逗号分隔的列表则该列表将被视为单个数据库的名称。 如果您正在使用跨数据库更新并且不希望记录这些更新则不应使用此选项。 校验和选项。 MySQL 支持二进制日志校验和的读写。这些可以使用此处列出的两个选项来启用 --binlog-checksum{NONE|CRC32} 命令行格式--binlog-checksumtype类型细绳默认值CRC32有效值 NONE CRC32 启用此选项会导致源为写入二进制日志的事件写入校验和。设置为 NONE禁用或用于生成校验和的算法的名称目前仅支持 CRC32 校验和且默认为 CRC32。您无法在事务中更改此选项的设置。 要控制副本从中继日志读取校验和请使用该 --slave-sql-verify-checksum 选项。 测试和调试选项。 以下二进制日志选项用于复制测试和调试。它们不适合在正常操作中使用。 --max-binlog-dump-eventsN 命令行格式--max-binlog-dump-events#类型整数默认值0 MySQL 测试套件内部使用此选项进行复制测试和调试。 --sporadic-binlog-dump-fail 命令行格式--sporadic-binlog-dump-fail[{OFF|ON}]类型布尔值默认值OFF MySQL 测试套件内部使用此选项进行复制测试和调试。 与二进制日志记录一起使用的系统变量 以下列表描述了用于控制二进制日志记录的系统变量。它们可以在服务器启动时设置其中一些可以在运行时使用 SET. 本节前面列出了用于控制二进制日志记录的服务器选项。 binlog_cache_size 命令行格式--binlog-cache-size#系统变量binlog_cache_size范围全球的动态的是的类型整数默认值32768最小值4096最大值64 位平台18446744073709547520最大值32 位平台4294963200单元字节块大小4096 事务期间保存二进制日志更改的缓存大小。 如果服务器支持任何事务存储引擎并且服务器启用了二进制日志--log-bin选项则会为每个客户端分配二进制日志缓存。如果您经常使用大型事务则可以增加此缓存大小以获得更好的性能。和 status 变量对于调整该变量的大小非常有用Binlog_cache_use。 Binlog_cache_disk_use请参阅二进制日志。 binlog_cache_size仅设置事务缓存的大小语句高速缓存的大小由 binlog_stmt_cache_size 系统变量控制。 binlog_checksum 命令行格式--binlog-checksumtype系统变量binlog_checksum范围全球的动态的是的类型细绳默认值CRC32有效值 NONE CRC32 启用后此变量会导致源为二进制日志中的每个事件写入校验和。 binlog_checksum支持值 NONE禁用和 CRC32。默认为 CRC32. binlog_checksum您无法更改交易内 的值 。 当binlog_checksum禁用值 NONE时服务器通过写入和检查每个事件的事件长度而不是校验和来验证它是否只将完整的事件写入二进制日志。 更改该变量的值会导致二进制日志轮转校验和始终写入整个二进制日志文件而不是仅写入其中的一部分。 在源上将此变量设置为副本无法识别的值会导致副本将其自己的 binlog_checksum值设置为 NONE并停止复制并出现错误。Bug #13553750、Bug #61096如果担心与旧副本的向后兼容性您可能需要将该值显式设置为NONE。 binlog_direct_non_transactional_updates 命令行格式--binlog-direct-non-transactional-updates[{OFF|ON}]系统变量binlog_direct_non_transactional_updates范围全局、会话动态的是的类型布尔值默认值OFF 由于并发问题当事务同时包含对事务性表和非事务性表的更新时副本可能会变得不一致。MySQL 试图通过将非事务性语句写入事务缓存来保留这些语句之间的因果关系事务缓存在提交时会被刷新。但是当代表事务对非事务表所做的修改对其他连接立即可见时就会出现问题因为这些更改可能不会立即写入二进制日志。 该 binlog_direct_non_transactional_updates 变量为该问题提供了一种可能的解决方法。默认情况下该变量被禁用。启用 binlog_direct_non_transactional_updates 后会将非事务表的更新直接写入二进制日志而不是写入事务缓存。 binlog_direct_non_transactional_updates 仅适用于使用基于语句的二进制日志记录格式复制的语句也就是说它仅在 binlog_formatis STATEMENT或当 binlog_formatis MIXED且使用基于语句的格式复制给定语句时才起作用。ROW当二进制日志格式为或 binlog_format设置 MIXED为 且使用基于行的格式复制给定语句 时此变量无效 重要的 在启用此变量之前您必须确保事务性表和非事务性表之间不存在依赖关系这种依赖关系的一个例子是语句INSERT INTO myisam_table SELECT * FROM innodb_table。否则此类语句可能会导致副本与源有所不同。 ROW当二进制日志格式为或 时该变量无效 MIXED。 binlog_error_action 命令行格式--binlog-error-action[value]系统变量binlog_error_action范围全球的动态的是的类型枚举默认值ABORT_SERVER有效值 IGNORE_ERROR ABORT_SERVER 控制当服务器遇到错误例如无法写入、刷新或同步二进制日志时发生的情况这可能导致源的二进制日志变得不一致并且副本失去同步。 在 MySQL 5.7.7 及更高版本中此变量默认为 ABORT_SERVER这使得服务器在二进制日志遇到此类错误时停止记录并关闭。重新启动时恢复将按照服务器意外停止的情况进行请参阅 第 3.2 节 “处理副本意外停止”。 当binlog_error_action设置为 时 IGNORE_ERROR如果服务器遇到此类错误它将继续正在进行的事务记录错误然后停止记录并继续执行更新。要恢复二进制日志记录 log_bin必须再次启用这需要重新启动服务器。此设置提供与旧版本 MySQL 的向后兼容性。 在以前的版本中该变量被命名为 binlogging_impossible_mode。 binlog_format 命令行格式--binlog-formatformat系统变量binlog_format范围全局、会话动态的是的类型枚举默认值ROW有效值 MIXED STATEMENT ROW 该系统变量设置二进制日志记录格式可以是STATEMENT、 ROW、 或 中的任意一个MIXED。请参见 第 5.1 节“复制格式”。当服务器上启用二进制日志记录时该设置才会生效即 log_bin系统变量设置为时的情况ON。在 MySQL 5.7 中默认情况下不启用二进制日志记录您可以使用该 --log-bin选项启用它。 binlog_format可以在启动时或运行时设置但在某些情况下不可能在运行时更改此变量或导致复制失败如下所述。 在 MySQL 5.7.7 之前默认格式是 STATEMENT. 在 MySQL 5.7.7 及更高版本中默认值为ROW. 例外在 NDB Cluster 中默认值为MIXED; NDB Cluster 不支持基于语句的复制。 设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅 系统变量权限。 管理对此变量的更改何时生效以及效果持续多长时间的规则与其他 MySQL 服务器系统变量相同。有关详细信息请参阅变量赋值的 SET 语法。 指定时MIXED将使用基于语句的复制但仅保证基于行的复制能够产生正确结果的情况除外。例如当语句包含可加载函数或UUID() 函数时就会发生这种情况。 有关设置每种二进制日志记录格式时如何处理存储程序存储过程和函数、触发器和事件的详细信息请参阅 存储程序二进制日志记录。 当您无法在运行时切换复制格式时存在例外情况 来自存储的函数或触发器。 如果会话当前处于基于行的复制模式并且打开了临时表。 来自事务内部。 在这些情况下尝试切换格式会导致错误。 更改复制源服务器上的日志记录格式不会导致副本更改其日志记录格式以进行匹配。如果副本启用了二进制日志记录则在复制过程中切换复制格式可能会导致问题并且更改会导致副本使用 STATEMENT格式日志记录而源正在使用ROW格式MIXED 日志记录。副本无法将以日志ROW记录格式接收的二进制日志条目转换为 STATEMENT用于其自己的二进制日志的格式因此这种情况可能会导致复制失败。有关详细信息请参阅 设置二进制日志格式。 二进制日志格式影响以下服务器选项的行为 --replicate-do-db --replicate-ignore-db --binlog-do-db --binlog-ignore-db 这些影响将在各个选项的描述中详细讨论。 binlog_group_commit_sync_delay 命令行格式--binlog-group-commit-sync-delay#系统变量binlog_group_commit_sync_delay范围全球的动态的是的类型整数默认值0最小值0最大值1000000单元微秒 控制将二进制日志文件同步到磁盘之前二进制日志提交等待的微秒数。默认 binlog_group_commit_sync_delay 设置为0表示没有延迟。设置 binlog_group_commit_sync_delay 为微秒延迟可以使更多事务同时同步到磁盘从而减少提交一组事务的总时间因为较大的组每组需要的时间单位较少。 当设置sync_binlog0或 sync_binlog1时指定的延迟 binlog_group_commit_sync_delay 将在同步之前应用于每个二进制日志提交组或者在 的情况下 sync_binlog0在继续之前。当 sync_binlog设置为大于 1 的值n时在每n 个二进制日志提交组 之后应用延迟。 设置 binlog_group_commit_sync_delay 可以增加具有或故障转移后可能具有副本的任何服务器上并行提交事务的数量因此可以增加副本上的并行执行。要受益于此效果副本服务器必须已 设置并且 在也设置slave_parallel_typeLOGICAL_CLOCK 时效果更显着 。binlog_transaction_dependency_trackingCOMMIT_ORDER在调整 的设置时考虑源的吞吐量和副本的吞吐量非常重要 binlog_group_commit_sync_delay。 设置 还可以减少 任何具有二进制日志的服务器源或副本上对二进制日志 binlog_group_commit_sync_delay 的调用次数。fsync() 请注意设置 binlog_group_commit_sync_delay 会增加服务器上事务的延迟这可能会影响客户端应用程序。此外在高度并发的工作负载上延迟可能会增加争用从而降低吞吐量。通常设置延迟的好处大于缺点但应始终进行调整以确定最佳设置。 binlog_group_commit_sync_no_delay_count 命令行格式--binlog-group-commit-sync-no-delay-count#系统变量binlog_group_commit_sync_no_delay_count范围全球的动态的是的类型整数默认值0最小值0最大值100000 在中止指定的当前延迟之前要等待的最大事务数 binlog_group_commit_sync_delay。如果 binlog_group_commit_sync_delay 设置为 0则该选项无效。 binlog_max_flush_queue_time 命令行格式--binlog-max-flush-queue-time#已弃用是的系统变量binlog_max_flush_queue_time范围全球的动态的是的类型整数默认值0最小值0最大值100000单元微秒 以前这控制了在继续进行组提交之前从刷新队列中继续读取事务的时间以微秒为单位。在 MySQL 5.7 中该变量不再有任何作用。 binlog_max_flush_queue_time从 MySQL 5.7.9 开始已弃用并标记为在未来的 MySQL 版本中最终删除。 binlog_order_commits 命令行格式--binlog-order-commits[{OFF|ON}]系统变量binlog_order_commits范围全球的动态的是的类型布尔值默认值ON 当在复制源服务器上启用此变量这是默认设置时向存储引擎发出的事务提交指令将在单个线程上序列化因此事务的提交顺序始终与写入二进制日志的顺序相同。禁用此变量允许使用多个线程发出事务提交指令。与二进制日志组提交结合使用可以防止单个事务的提交率成为吞吐量的瓶颈因此可能会提高性能。 当所有涉及的存储引擎都确认事务已准备好提交时事务就会写入二进制日志。然后二进制日志组提交逻辑在二进制日志写入发生后提交一组事务。什么时候 binlog_order_commits被禁用因为此过程使用多个线程提交组中的事务可能会按照与二进制日志中的顺序不同的顺序提交。来自单个客户端的事务总是按时间顺序提交。在许多情况下这并不重要因为在单独的事务中执行的操作应该产生一致的结果如果不是这种情况则应该使用单个事务。 如果要确保源和多线程副本上的事务历史记录保持相同请 slave_preserve_commit_order1 在副本上设置。 binlog_row_image 命令行格式--binlog-row-imageimage_type系统变量binlog_row_image范围全局、会话动态的是的类型枚举默认值full有效值 full记录所有列 minimal仅记录更改的列以及识别行所需的列 noblob记录所有列除了不需要的 BLOB 和 TEXT 列 对于 MySQL 基于行的复制此变量确定如何将行图像写入二进制日志。 在MySQL基于行的复制中每个行更改事件包含两个图像一个“之前”图像其列在搜索要更新的行时进行匹配以及一个包含更改的“之后”图像。通常MySQL 会记录前后图像的完整行即所有列。但是并非严格需要在两个映像中都包含每一列并且我们通常可以通过仅记录实际需要的那些列来节省磁盘、内存和网络使用量。 笔记 删除行时仅记录之前的图像因为删除后没有要传播的更改值。插入行时仅记录后图像因为没有要匹配的现有行。仅当更新一行时才需要之前和之后的图像并且都写入二进制日志。 对于之前的图像只需要记录唯一标识行所需的最小列集。如果包含该行的表具有主键则仅将主键列写入二进制日志。否则如果表有一个唯一键其所有列都是NOT NULL则只需要记录唯一键中的列。如果表既没有主键也没有唯一键没有任何 NULL列则所有列都必须在前映像中使用并记录。在后映像中只需记录实际更改的列。 您可以使用系统变量使服务器记录完整或最少的行binlog_row_image。该变量实际上采用三个可能值之一如下列表所示 full记录前图像和后图像中的所有列。 minimal仅记录前映像中识别要更改的行所需的那些列仅记录后映像中由 SQL 语句指定值或通过自动增量生成值的那些列。 noblob记录所有列与 相同 full除了 不需要识别行或未更改的列 BLOB。 TEXT 笔记 NDB Cluster 不支持此变量设置它对表的日志记录没有影响 NDB。 默认值为full。 使用minimalor 时noblob当且仅当源表和目标表都满足以下条件时才能保证给定表的删除和更新正确工作 所有列必须存在且顺序相同每列必须使用与另一个表中对应列相同的数据类型。 这些表必须具有相同的主键定义。 换句话说除了不属于表主键一部分的索引之外表必须相同。 如果不满足这些条件则目标表中的主键列值可能不足以为删除或更新提供唯一匹配。在这种情况下不会发出警告或错误源和副本默默地发生分歧从而破坏了一致性。 当二进制日志记录格式为 时设置此变量无效STATEMENT。当 binlog_formatis 时 MIXED 的设置 binlog_row_image将应用于使用基于行的格式记录的更改但此设置对记录为语句的更改没有影响。 binlog_row_image在全局或会话级别上 进行设置都不会导致隐式提交这意味着可以在事务正在进行时更改此变量而不会影响事务。 binlog_rows_query_log_events 命令行格式--binlog-rows-query-log-events[{OFF|ON}]系统变量binlog_rows_query_log_events范围全局、会话动态的是的类型布尔值默认值OFF 该系统变量仅影响基于行的日志记录。启用后它会导致服务器将信息日志事件例如行查询日志事件写入其二进制日志。此信息可用于调试和相关目的例如当无法从行更新重建源时获取在源上发出的原始查询。 这些信息事件通常会被读取二进制日志的 MySQL 程序忽略因此在复制或从备份恢复时不会出现问题。要查看它们请使用 mysqlbinlog --verbose选项两次as-vv或 来增加详细级别--verbose --verbose。 binlog_stmt_cache_size 命令行格式--binlog-stmt-cache-size#系统变量binlog_stmt_cache_size范围全球的动态的是的类型整数默认值32768最小值4096最大值64 位平台18446744073709547520最大值32 位平台4294963200单元字节块大小4096 该变量确定二进制日志的缓存大小以保存事务期间发出的非事务性语句。 如果服务器支持任何事务存储引擎并且服务器启用了二进制日志--log-bin 选项则会为每个客户端分配单独的二进制日志事务和语句缓存。如果您经常在事务期间使用大型非事务性语句则可以增加此缓存大小以获得更好的性能。和 status 变量对于调整该变量的大小非常有用Binlog_stmt_cache_use。 Binlog_stmt_cache_disk_use请参阅二进制日志。 系统binlog_cache_size 变量设置事务缓存的大小。 binlog_transaction_dependency_tracking 命令行格式--binlog-transaction-dependency-trackingvalue介绍5.7.22系统变量binlog_transaction_dependency_tracking范围全球的动态的是的类型枚举默认值COMMIT_ORDER有效值 COMMIT_ORDER WRITESET WRITESET_SESSION 依赖关系信息源源用于确定哪些事务可以由副本的多线程应用程序并行执行。该变量可以采用以下列表中描述的三个值之一 COMMIT_ORDER依赖信息是根据源的提交时间戳生成的。这是默认设置。 WRITESET依赖信息是从源的写入集生成的任何写入不同元组的事务都可以并行化。 WRITESET_SESSION依赖信息是从源的写入集生成的任何写入不同元组的事务都可以并行化但来自同一会话的两个更新不能重新排序。 在WRITESETor WRITESET_SESSION模式下除非您还设置了 否则事务可能会无序提交 slave_preserve_commit_order1。 对于某些事务WRITESET和 WRITESET_SESSION模式无法改进模式中返回的结果 COMMIT_ORDER。对于具有空或部分写入集的事务、更新没有主键或唯一键的表的事务以及更新外键关系中的父表的事务就是这种情况。在这些情况下源使用COMMIT_ORDER模式来生成依赖关系信息。 该变量的值不能设置为COMMIT_ORDERif transaction_write_set_extraction is以外的任何值OFF。您还应该注意如果 的当前值为或 transaction_write_set_extraction 则无法更改 的 值。如果更改该值则在使用和 语句停止并重新启动副本之前新值不会对副本生效 。 binlog_transaction_dependency_trackingWRITESETWRITESET_SESSIONSTOP SLAVESTART SLAVE 为更改给定行的最新事务而要保留和检查的行哈希数由 的值确定 binlog_transaction_dependency_history_size。 binlog_transaction_dependency_history_size 命令行格式--binlog-transaction-dependency-history-size#介绍5.7.22系统变量binlog_transaction_dependency_history_size范围全球的动态的是的类型整数默认值25000最小值1最大值1000000 设置保留在内存中并用于查找最后修改给定行的事务的行哈希数的上限。一旦达到这个哈希值历史记录就会被清除。 expire_logs_days 命令行格式--expire-logs-days#系统变量expire_logs_days范围全球的动态的是的类型整数默认值0最小值0最大值99单元天 自动二进制日志文件删除的天数。默认为0表示“不自动删除”。”可能的删除发生在启动时和刷新二进制日志时。日志刷新的发生如MySQL 服务器日志中所示。 要手动删除二进制日志文件请使用该 PURGE BINARY LOGS语句。请参阅PURGE BINARY LOGS 语句。 log_bin 系统变量log_bin范围全球的动态的不类型布尔值 是否启用二进制日志。如果 --log-bin使用该选项则该变量的值为ON否则就是OFF。该变量仅报告二进制日志记录的状态启用或禁用它实际上并不报告所设置的值 --log-bin。 请参阅二进制日志。 log_bin_basename 系统变量log_bin_basename范围全球的动态的不类型文件名 保存二进制日志文件的基本名称和路径可以使用--log-bin 服务器选项进行设置。最大变量长度为256。在MySQL 5.7中默认的基本名称是带有后缀的主机名称-bin。默认位置是数据目录。 log_bin_index 命令行格式--log-bin-indexfile_name系统变量log_bin_index范围全球的动态的不类型文件名 保存二进制日志索引文件的基本名称和路径可以使用 --log-bin-index服务器选项进行设置。最大变量长度为 256。 log_bin_trust_function_creators 命令行格式--log-bin-trust-function-creators[{OFF|ON}]系统变量log_bin_trust_function_creators范围全球的动态的是的类型布尔值默认值OFF 该变量在启用二进制日志记录时应用。它控制是否可以信任存储函数创建者不会创建导致不安全事件写入二进制日志的存储函数。如果设置为 0默认值则不允许用户创建或更改存储的函数除非他们拥有除或权限SUPER之外的权限。设置为 0 还强制执行这样的限制必须使用 特性或或来 声明函数CREATE ROUTINEALTER ROUTINEDETERMINISTICREADS SQL DATANO SQL特征。如果该变量设置为 1MySQL 不会对存储函数的创建强制执行这些限制。此变量也适用于触发器创建。请参阅存储程序二进制日志记录。 log_bin_use_v1_row_events 命令行格式--log-bin-use-v1-row-events[{OFF|ON}]系统变量log_bin_use_v1_row_events范围全球的动态的是的类型布尔值默认值OFF 是否正在使用版本 2 二进制日志记录。如果此变量为 0禁用默认值则正在使用版本 2 二进制日志事件。如果此变量为 1启用则服务器使用版本 1 日志记录事件以前版本中使用的二进制日志事件的唯一版本写入二进制日志从而生成可由较旧副本读取的二进制日志。 MySQL 5.7 默认使用版本 2 二进制日志行事件。但是MySQL 5.6.6 之前的 MySQL Server 版本无法读取版本 2 事件。启用会 log_bin_use_v1_row_events 导致mysqld使用版本 1 日志记录事件写入二进制日志。 该变量在运行时是只读的。要在版本 1 和版本 2 二进制事件二进制日志记录之间切换需要 log_bin_use_v1_row_events 在服务器启动时进行设置。 除了执行 NDB Cluster Replication 的升级之外 log_bin_use_v1_row_events 主要在设置复制冲突检测和解决方案时使用 NDB$EPOCH_TRANS()作为冲突检测功能这需要版本 2 二进制日志行事件。因此这个变量和 --ndb-log-transaction-id不兼容。 笔记 MySQL NDB Cluster 7.5 默认使用版本 2 二进制日志行事件。在计划升级或降级以及使用 NDB Cluster Replication 进行设置时您应该记住这一点。 有关详细信息请参阅 NDB Cluster 复制冲突解决方案。 log_builtin_as_identified_by_password 命令行格式--log-builtin-as-identified-by-password[{OFF|ON}]系统变量log_builtin_as_identified_by_password范围全球的动态的是的类型布尔值默认值OFF 该变量影响用户管理语句的二进制日志记录。启用后该变量具有以下效果 CREATE USER涉及内置身份验证插件的语句 的二进制日志记录会重写语句以包含IDENTIFIED BY PASSWORD 子句。 SET PASSWORD语句被记录为SET PASSWORD语句而不是被重写为ALTER USER 语句。 SET PASSWORD语句已更改为记录密码的哈希值而不是提供的明文未加密密码。 启用此变量可确保与 5.6 和 5.7.6 之前的副本的跨版本复制以及在二进制日志中期望此语法的应用程序具有更好的兼容性。 log_slave_updates 命令行格式--log-slave-updates[{OFF|ON}]系统变量log_slave_updates范围全球的动态的不类型布尔值默认值OFF 副本服务器从源服务器接收的更新是否应记录到副本自己的二进制日志中。 通常副本不会将从源服务器接收到的任何更新记录到其自己的二进制日志中。启用此变量会导致副本将其复制 SQL 线程执行的更新写入其自己的二进制日志。要使此选项生效副本还必须使用 --log-bin启用二进制日志记录的选项启动。请参见第 2.6 节“复制和二进制日志记录选项和变量”。 log_slave_updates当您想要链接复制服务器时启用。例如您可能希望使用以下安排来设置复制服务器 A - B - C 在此A充当副本 的源B 并B 充当副本 的源C。为此B必须同时是源 和副本。您必须同时启动 A和B来 --log-bin启用二进制日志记录并B启用 log_slave_updates以便A将接收到的更新记录B到其二进制日志中。 log_statements_unsafe_for_binlog 命令行格式--log-statements-unsafe-for-binlog[{OFF|ON}]介绍5.7.11系统变量log_statements_unsafe_for_binlog范围全球的动态的是的类型布尔值默认值ON 如果遇到错误 1592则控制是否将生成的警告添加到错误日志中。 master_verify_checksum 命令行格式--master-verify-checksum[{OFF|ON}]系统变量master_verify_checksum范围全球的动态的是的类型布尔值默认值OFF 启用此变量会导致源通过检查校验和来验证从二进制日志中读取的事件并在不匹配的情况下停止并出现错误。 master_verify_checksum默认情况下禁用在这种情况下源使用二进制日志中的事件长度来验证事件以便仅从二进制日志中读取完整的事件。 max_binlog_cache_size 命令行格式--max-binlog-cache-size#系统变量max_binlog_cache_size范围全球的动态的是的类型整数默认值64 位平台18446744073709547520默认值32 位平台4294967295最小值4096最大值64 位平台18446744073709547520最大值32 位平台4294967295单元字节块大小4096 如果事务需要超过这么多字节服务器会生成多语句事务需要超过“max_binlog_cache_size”字节存储错误。当 gtid_mode不是 时 ON最大推荐值为 4GB因为在这种情况下MySQL 无法使用大于 4GB 的二进制日志位置当 gtid_mode是 时ON此限制不适用并且服务器可以使用任意大小的二进制日志位置。 如果因为gtid_mode不是ON或者由于某些其他原因您需要保证二进制日志不超过给定的大小maxsize则应该根据此处显示的公式设置此变量 max_binlog_cache_size (((maxsize - max_binlog_size) / max_connections) - 1000) / 1.2 此计算考虑以下条件 只要开始写入之前的大小小于服务器就会写入二进制日志 max_binlog_size。 服务器不写入单个事务而是写入一组事务。一个组中的最大可能交易数量等于 max_connections。 服务器写入未包含在缓存中的数据。这包括每个事件的 4 字节校验和虽然这使交易规模增加了不到 20%但这个数额是不可忽略的。另外服务器Gtid_log_event为每笔交易写入一个这些事件中的每一个都会使写入二进制日志的内容再增加 1 KB。 max_binlog_cache_size仅设置事务缓存的大小语句高速缓存的上限由 max_binlog_stmt_cache_size 系统变量控制。 会话的可见性 与系统变量max_binlog_cache_size的可见性相匹配 binlog_cache_size换句话说更改其值仅影响该值更改后启动的新会话。 max_binlog_size 命令行格式--max-binlog-size#系统变量max_binlog_size范围全球的动态的是的类型整数默认值1073741824最小值4096最大值1073741824单元字节块大小4096 如果写入二进制日志导致当前日志文件大小超过此变量的值服务器将轮换二进制日志关闭当前文件并打开下一个文件。最小值为 4096 字节。最大值和默认值为 1GB。 事务以一个块的形式写入二进制日志因此永远不会拆分到多个二进制日志中。因此如果您有大型事务您可能会看到大于 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范围全球的动态的是的类型整数默认值18446744073709547520最小值4096最大值18446744073709547520单元字节块大小4096 如果事务中的非事务性语句需要超过这么多字节的内存则服务器会生成错误。最小值为 4096。最大值和默认值在 32 位平台上为 4GB在 64 位平台上为 16EB艾字节。 max_binlog_stmt_cache_size仅设置语句缓存的大小事务缓存的上限仅由 max_binlog_cache_size 系统变量控制。 sql_log_bin 系统变量sql_log_bin范围会议动态的是的类型布尔值默认值ON 该变量控制是否为当前会话启用记录到二进制日志假设二进制日志本身已启用。默认值为 ON。要禁用或启用当前会话的二进制日志记录请将会话 sql_log_bin变量设置为 OFF或ON。 将此变量设置为OFF会话以在对不希望复制到副本的源进行更改时临时禁用二进制日志记录。 设置此系统变量的会话值是一项受限制的操作。会话用户必须具有足够的权限才能设置受限会话变量。请参阅 系统变量权限。 无法 sql_log_bin在事务或子查询中设置会话值。 设置此变量可防止OFF 将 GTID 分配给二进制日志中的事务。如果您使用 GTID 进行复制这意味着即使稍后再次启用二进制日志记录从此时写入日志的 GTID 也不会考虑同时发生的任何事务因此实际上这些事务都会丢失。 全局sql_log_bin 变量是只读的不能修改。全局范围已被弃用预计它会在未来的 MySQL 版本中被删除。 sync_binlog 命令行格式--sync-binlog#系统变量sync_binlog范围全球的动态的是的类型整数默认值1最小值0最大值4294967295 控制 MySQL 服务器将二进制日志同步到磁盘的频率。 sync_binlog0禁用 MySQL 服务器将二进制日志同步到磁盘。相反MySQL 服务器依赖操作系统将二进制日志不时刷新到磁盘就像处理任何其他文件一样。此设置提供最佳性能但在发生电源故障或操作系统崩溃时服务器可能已提交尚未同步到二进制日志的事务。 sync_binlog1在提交事务之前启用二进制日志到磁盘的同步。这是最安全的设置但由于磁盘写入次数增加可能会对性能产生负面影响。如果发生电源故障或操作系统崩溃二进制日志中丢失的事务仅处于准备状态。这允许自动恢复例程回滚事务从而保证二进制日志中不会丢失任何事务。 sync_binlogN其中N是非 0 或 1 的值 N收集二进制日志提交组后将二进制日志同步到磁盘。如果发生电源故障或操作系统崩溃服务器可能已提交尚未刷新到二进制日志的事务。由于磁盘写入次数增加此设置可能会对性能产生负面影响。较高的值可以提高性能但数据丢失的风险也会增加。 InnoDB为了在与事务一起 使用的复制设置中获得最大可能的持久性和一致性请使用以下设置 sync_binlog1。 innodb_flush_log_at_trx_commit1。 警告 许多操作系统和一些磁盘硬件会欺骗刷新到磁盘操作。他们可能会告诉 mysqld刷新已经发生即使它还没有发生。在这种情况下即使采用推荐的设置也无法保证事务的持久性并且在最坏的情况下断电可能会损坏InnoDB数据。在 SCSI 磁盘控制器或磁盘本身中使用电池支持的磁盘缓存可以加快文件刷新速度并使操作更安全。您还可以尝试禁用硬件缓存中的磁盘写入缓存。 transaction_write_set_extraction 命令行格式--transaction-write-set-extraction[value]系统变量transaction_write_set_extraction范围全局、会话动态的是的类型枚举默认值OFF有效值≥ 5.7.14 OFF MURMUR32 XXHASH64 有效值≤ 5.7.13 OFF MURMUR32 定义用于生成标识与事务关联的写入的哈希的算法。如果您使用组复制则哈希值用于分布式冲突检测和处理。在运行组复制的 64 位系统上我们建议将其设置为 XXHASH64以避免不必要的哈希冲突从而导致认证失败和用户事务回滚。请参阅 组复制要求。 binlog_format必须设置为ROW更改此变量的值。STOP SLAVE如果更改该值则在使用和语句停止并重新启动副本之前新值不会对副本生效START SLAVE。 笔记 当WRITESET或 WRITESET_SESSION被设置为 的值 时binlog_transaction_dependency_tracking transaction_write_set_extraction 必须设置为指定算法不能设置为 OFF。当 的当前值为 或 时 binlog_transaction_dependency_tracking WRITESET您 WRITESET_SESSION无法更改 的值 transaction_write_set_extraction。
