09 主从复制 redo、undo、binLog

1. 为什么mysql要做主从复制？

1. 让主库负责写，从库负责读，这样即使主库出现了锁表，也可以通过读取从库来保证业务的正常运行。通过这种主从复制来进行读写分离，减轻了主数据库的负载。
2. 如果主数据库宕机，可以快速将业务系统切换到从数据库上，避免数据丢失。
3. 如果对数据库的读写都在同一个数据库服务器中，那随着业务量越来越大，IO访问频率越来越高，从而导致单机无法满足，所以需要做多库的存储，降低磁盘I/O访问的频率，提高单个机器的IO性能。

2. 主从复制的原理（异步实时的将主库二进制日志(binlog)重做并应用到从库）

1. 主数据库的更新事件(update、insert、delete)被写到 binlog 二进制日志文件中。
2. 从库发起连接，连接到主库，并请求从binlog二进制日志文件中指定位置之后的日志内容。
3. 主库接收到请求后，创建一个 binlog dump thread（binlog 转储线程），把binlog的内容发送到从库。
4. 从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到 relay log（中继日志）。
5. 从库还会创建一个SQL线程，从relay log里面读取内容，从指定位置开始执行读取到的更新事件，将更新内容写入到从数据库。
   

redo、undo、binLog

redo log （重做日志）（保证事务的原子性和持久性）

• InnoDB 存储引擎层特有的一种物理日志，负责把事务对数据库所做的所有修改都记录下来。（系统奔溃重启时可以通过 redo log 日志找回记录）
• redo log 在事务进行中不断的被写入到磁盘，由于是并发写入的，所以日志不是随事务提交的顺序写入磁盘的。
• 循环写的，空间固定，如果用完了就会覆盖以前的日志。

binlog （二进制日志）

• binlog 是 server 层的一种逻辑日志，记录的是对应的 sql 语句，任何存储引擎对数据库的修改都会产生 binlog 日志。
• binlog 日志只在事务提交完成后进行一次写入磁盘的操作。
• binlog 是可以追加写入的，也就是写到一定大小后会切换到下一个，并不会覆盖以前的日志。

undo log （回滚日志）（保证事务的一致性）

• 如果事务执行过程中发生错误，导致执行一半就结束了，但执行过程中已经修改了数据，为了保证事务的原子性，就需要把数据恢复为原来的样子，所以引入了 undo log 来提供回滚功能。undo log 是逻辑日志，当delete一条记录时，- undo log中会记录一条对应的insert记录，当update一条记录时，它会记录一条对应相反的update记录。根据记录来进行记录。
• undo log 另一个作用是实现多版本并发控制（MVCC），当用户读取一行记录时，若该记录已经被其他事务占用，当前事务可以通过 undo log 读取之前的行版本信息，以此实现非锁定读取。
• undo log 也会产生 redo log，这是因为 undo log 也需要保证持久性。