1.Binary Logging概述

介绍

1 概念

binary log记录了数据库更改的事件，例如创建、更改等对表的更改。binary log还包含有关每个语句获取更新数据的时间长度的信息。记录二进制日志主要有两个目的：

• 用于复制技术：将Master服务器的binary log发送到Slave服务器，供Slave进行数据复制。
• 用于备份恢复：在某些情况下恢复数据库需要使用binary log。还原备份集后，可以使用binary log进行数据演绎，恢复到最新数据。

2 特点

binary log有以下特点：

• binary log不会记录不修改数据的语句，例如Select，Show等。
• binary log会对系统性能造成影响，但是为了数据安全以及其他一些技术，这些性能影响可以在大部分情况下忽略，或者用其他相关方案解决。
• binary log可以处理意外宕机，因为binary log仅记录或回读完整的事务或事件。
• 写入binary log的语句中的密码由服务器重写，不会以纯文本形式出现。

3 相关参数以及意义

• Mysql默认情况下是启用二进制日志记录的（log_bin系统变量设置为ON）。但是，如果使用mysqld通过使用–initialize或–initialize-insecure选项手动初始化数据目录，默认情况下禁用二进制日志记录，可以通过在配置文件中增加–log-bin选项启用，也可以在启动时指定–skip-log-bin或–disable-log-bin选项，启用与关闭选项谁靠后谁优先。
• 设置–log-slave-updates和–slave-preserve-commit-order选项需要启动binary log，默认情况下，当指定了–skip-log-bin或–disable-log-bin，MySQL会禁用这些选项。如果将–log-slave-updates或–slave-preserve-commit-order与–skip-log-bin或–disable-log-bin一起指定，则会发出警告或错误消息
• 设置–log-bin [= base_name]选项用于指定二进制日志文件的基本名称。如果不设置–log-bin选项，则MySQL使用binlog作为二进制日志文件的默认基本名称。为了与早期版本兼容，如果提供的-log-bin选项没有字符串或空字符串，则基本名称默认为host_name-bin，使用主机名称。建议您指定基本名称，以便在主机名更改时，您可以轻松地继续使用相同的二进制日志文件名
• mysqld将数字扩展名附加到binary log基本名称以生成二进制日志文件名。每次服务器创建新日志文件时，该数字都会增加，从而创建一系列有序的文件。每次启动或刷新日志时，服务器都会在系列中创建一个新文件。在当前日志的大小达到max_binlog_size后，服务器还会自动创建新的二进制日志文件。如果您使用大型事务，则二进制日志文件可能会变得比max_binlog_size大，因为事务是以一个部分写入文件，而不是在文件之间分割。
• 为了跟踪已使用的binary log文件，mysqld还创建了一个二进制日志索引文件，其中包含所有使用的binary log文件的名称。默认情况下，它具有与二进制日志文件相同的基本名称，扩展名为“.index”。您可以使用–log-bin-index [= file_name]选项更改二进制日志索引文件的名称。在mysqld运行时，此文件不可手动编辑。
• 二进制日志文件和二进制日志索引文件的默认位置是数据目录。您可以使用–log-bin选项指定备用位置，方法是在基本名称中添加前导绝对路径名以指定其他目录。当服务器从二进制日志索引文件中读取条目时，该文件跟踪已使用的二进制日志文件，它会检查条目是否包含相对路径。如果是，则使用–log-bin选项将路径的相对部分替换为绝对路径。二进制日志索引文件中记录的绝对路径保持不变;在这种情况下，必须手动编辑索引文件以启用新路径。二进制日志文件基本名称和任何指定的路径都可用作log_bin_basename系统变量。
• 在MySQL 5.7中，必须在启用二进制日志记录时指定服务器ID，否则服务器将无法启动。在MySQL 8.0中，server_id系统变量默认设置为1。启用二进制日志记录时，可以使用此缺省ID启动服务器，但如果未使用–server-id选项明确指定服务器标识，则会发出信息性消息。对于复制拓扑中使用的服务器，必须为每个服务器指定唯一的非零服务器ID。
• 在MySQL 5.7中，必须在启用二进制日志记录时指定服务器ID，否则服务器将无法启动。在MySQL 8.0中，server_id系统变量默认设置为1。启用二进制日志记录时，可以使用此缺省ID启动服务器，但如果未使用–server-id选项明确指定服务器标识，则会发出信息性消息。对于复制拓扑中使用的服务器，必须为每个服务器指定唯一的非零服务器ID。
• 默认情况下，服务器记录事件的长度以及事件本身，并使用它来验证事件是否正确写入。可以通过设置binlog_checksum系统变量使服务器为事件编写校验和。
• binary log中记录的事件格式取决于二进制日志记录格式。支持三种格式类型：基于行的日志记录，基于语句的日志记录和基于混合的日志记录。使用的二进制日志记录格式取决于MySQL版本。
• mysql服务器以与–replicate-do-db和–replicate-ignore-db选项相同的方式处理–binlog-do-db和–binlog-ignore-db选项。
• 启动复制从属服务器时默认启用–log-slave-updates设置，这意味着从属服务器会将从复制主服务器接收的任何数据修改写入其自己的二进制日志。必须启用二进制日志才能使此设置生效.
• 可以使用RESET MASTER语句删除所有binary log文件，或使用PURGE BINARY LOGS删除它们的子集。
• 假如使用mysql复制技术，那么不要在Slave服务器全部同步完之前删除过期的binary log，可以使用mysqladmin flush-logs技术重新生成相关的binary log日志，假如Slave服务器没有延迟3天以上，可以删除3天以前的日志。手动删除binary log后，需要用PURGE BINARY LOGS重新更新索引文件。
• binary log也可用于显示复制从属中继日志文件内容，因为它们使用与二进制日志文件相同的格式编写。
• binary log是在语句或事务完成之后但在释放任何锁定或完成任何提交之前生成，这样做的目的是为了确保以提交顺序记录日志。
• 非事务性表的更新在执行后立即存储在二进制日志中。
• 无法回滚对非事务表引擎的修改。如果回滚的事务包括对非事务表的修改，则使用ROLLBACK语句记录整个事务，以确保复制对这些表的修改。

在mysql未开启GTID模式下，显式执行的事务中如果包含了非事务表的DML，这些表的数据并不会回滚（非事务性表无回滚的概念），同时也会为了主从数据一致的缘故，生成对应的binlog日志。而开启GTID模式下，非事务表只能在autocommit=1模式下单独执行或者只包含单个SQL的事务里执行。可见，开启GTID模式，通过禁止非事务表混入显式事务的方式去更好的保证了事务ACID特性，这种方式更为安全。

• 当处理事务的线程启动时，它会将binlog_cache_size的缓冲区分配给缓冲区语句。如果语句大于此值，则线程会打开一个临时文件来存储事务。线程结束时删除临时文件。
• Binlog_cache_use（事务类）二进制日志已缓存的条数（内存中）。 Binlog_cache_disk_use （非事务类）二进志日志缓存的已经存在硬盘的条数。这两个变量可用于将binlog_cache_size调整为足够大的值，以避免使用临时文件。Binlog_stmt_cache_use （非事务类）二进制日志已缓存的条数（内存中） 非事务型的语句，都存在这儿，比如MYISAM引擎的表，插入记录就存在这儿。
• max_binlog_cache_size系统变量（默认为4GB，也是最大值）可用于限制用于缓存多语句事务的总大小。如果事务大于这么多字节，它就会失败并回滚。最小值为4096，这个的意思就是事务最大不能超过4G。
• 如果使用二进制日志和基于行的日志记录，则并发插入将转换为CREATE … SELECT或INSERT … SELECT语句的常规插入。这样做是为了确保您可以通过在备份操作期间应用日志来重新创建表的精确副本。如果使用基于语句的日志记录，则会将原始语句写入日志。
• 二进制日志格式具有一些已知的限制，可能会影响从备份中恢复。

此部分内容太多，自行查看官网手册https://dev.mysql.com/doc/refman/8.0/en/replication-features.html

• Mysql 8.0以后不兼容Mysql以前版本的binary log
• 写入二进制日志文件和二进制日志索引文件的方式与写入MyISAM表的方式相同。
• 默认情况下，二进制日志在每次写入时都会同步到磁盘（sync_binlog = 1）。如果未启用sync_binlog，并且操作系统或计算机（不仅是MySQL服务器）崩溃，则二进制日志的最后一个语句可能会丢失。要防止这种情况，请启用sync_binlog系统变量，以便在每N个提交组之后将二进制日志同步到磁盘。
• 现版本mysql不在存在表内容和二进制日志内容之间不一致可可能性，通过在XA事务中启用InnoDB支持两阶段提交解决的此问题。
• InnoDB支持XA事务中的两阶段提交，可确保二进制日志和InnoDB数据文件同步。但是，MySQL服务器还应配置为在提交事务之前将二进制日志和InnoDB日志同步到磁盘。 InnoDB日志默认是同步的，sync_binlog = 1确保二进制日志同步。隐式InnoDB支持XA事务和sync_binlog = 1中的两阶段提交的效果是在崩溃后重启时，在执行事务回滚后，MySQL服务器扫描最新的二进制日志文件以收集事务xid值并计算二进制日志文件中的最后一个有效位置。 MySQL服务器然后告诉InnoDB完成任何已成功写入二进制日志的准备事务，并将二进制日志截断到最后一个有效位置。这可确保二进制日志反映InnoDB表的确切数据，因此从站与主站保持同步，因为它没有收到已回滚的语句。