bin log

binlog可以说是MySQL中比较 重要 的日志了，在日常开发及运维过程中，经常会遇到。 binlog即binary log，二进制日志文件，也叫作变更日志（update log）。它记录了数据库所有执行的 DDL 和 DML 等数据库更新事件的语句，但是不包含没有修改任何数据的语句（如数据查询语句select、 show等）。
binlog主要应用场景：

  • 数据恢复
  • 数据复制

image.png
查看bin log设置

  1.  show variables like '%log_bin%'

查看内容

  1. show binlog events [IN 'log_name']

使用日志恢复数据 

  1. mysqlbinlog [option] filename|mysql –uuser -ppass

这个命令可以这样理解：使用mysqlbinlog命令来读取filename中的内容，然后使用mysql命令将这些内容 恢复到数据库中。
filename ：是日志文件名。
option ：可选项，比较重要的两对option参数是—start-date、—stop-date 和 —start-position、— stop-position。
—start-date 和 —stop-date ：可以指定恢复数据库的起始时间点和结束时间点。
—start-position和—stop-position ：可以指定恢复数据的开始位置和结束位置。 

  1. mysqlbinlog --start-position=1002 --stop-position=1305 
  2. E:\mysql80\MySQL\MySQL Server 8.0\Data\DESKTOP-UQNS11N-bin |mysql –uuser -ppass

删除bin log

  1. PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名’
  2. PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’

bin log写入机制
binlog的写入时机也非常简单，事务执行过程中，先把日志写到 binlog cache ，事务提交的时候，再 把binlog cache写到binlog文件中。因为一个事务的binlog不能被拆开，无论这个事务多大，也要确保一 次性写入，所以系统会给每个线程分配一个块内存作为binlog cache。
image.png
redo log在事务执行过程 中可以不断写入，而binlog只有在提交事务时才写入，所以redo log与binlog的 写入时机 不一样。
两阶段提交
redo log与binlog两份日志之间的逻辑不一致，会出现什么问题
image.png
由于binlog没写完就异常，这时候binlog里面没有对应的修改记录
image.png
使用两阶段提交后，写入binlog时发生异常也不会有影响
redo log设置commit阶段发生异常，不会回滚， 它会执行上图框住的逻辑，虽然redo log是处于prepare阶段，但是能通过事务id找到对 应的binlog日志，所以MySQL认为是完整的，就会提交事务恢复数据。

relay log

中继日志只在主从服务器架构的从服务器上存在。从服务器为了与主服务器保持一致，要从主服务器读 取二进制日志的内容，并且把读取到的信息写入 本地的日志文件 中，这个从服务器本地的日志文件就叫 中继日志 。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主 从服务器的 数据同步
image.png

主从分离

image.png
image.png
复制三步骤
步骤1： Master 将写操作记录到二进制日志（ binlog ）。
步骤2： Slave 将 Master 的binary log events拷贝到它的中继日志（ relay log ）；
步骤3： Slave 重做中继日志中的事件，将改变应用到自己的数据库中。 MySQL复制是异步的且串行化 的，而且重启后从 接入点 开始复制。

一主一从架构搭建

image.png
主机配置文件
image.png
从机配置文件
image.png
主机： 建立账户并授权
image.png

  1. show  master status  #查看master状态

从机：配置需要复制的主机
image.png

  1. #启动slave同步
  2. START SLAVE

查看同步状态： 

  1. SHOW SLAVE STATUS\G;

image.png