IDEA激活码一.bin log日志
它记录数据库所有执行的DDL和DML等数据库更新事件的语句，但不包含没有修改任何数据的语句(select，show等)。
应用场景：
- 用于数据恢复：数据库宕机，可以使用该日志进行恢复。
- 用于数据复制：主节点发送数据到从节点。
写入机制：事务开始的时候，先把日志写到binlog cache中，事务提交，再刷新到bin log文件中。
刷盘策略：参数：sync_binlog
- 0：默认，每次提交事务都会刷新到page cache中，什么时候刷到磁盘由操作系统决定。
- 1：每次提交事务会同时刷到page cache和磁盘。
- n：每次提交事务都会write，积累到n个事务之后才fsync。
与redo log 的区别？
- redo log是物理日志，记录数据做了什么修改。比如哪条数据改为多少了。
- bin log是逻辑日志，记录原生的SQL语句。
- redo log为了数据库宕机恢复数据
- bin log是为了保持主从一致
两阶段提交
- 引出问题：redo log如果已经完成，写bin log 的时候服务器宕机了(redo log在执行完SQL就写入，而bin log是在事务结束的时候才写入，所以就可能发生这样的问题)，此时主库完成数据的更新，从库没有获得此次更新，就造成主从数据库不一致。
- 为了解决上述问题，innodb使用两阶段提交，将redo log的写入分为2个步骤：prepare和commit。
二.主从复制
分类：
- 一主一从模式
- 双主双从模式
mysql主从同步的原理? 主要靠3个线程,2个日志
- 三个线程：master主节点(bin log dump thread),slave子节点(I/O thread,SQL thread)
- 两个日志：bin log，relay log(中继日志)
- 原理：数据发生变化,主节点bin log 就发生变化,bin log dump thread线程就会把bin log的 数据发送给从节点,从节点的i/o 线程就会读取发来的数据,并写入到relay log中,然后 sql thread线程就会执行relay log中的操作,从而保证数据的一致性。
- 注意:采用"增量同步"。从节点会使用 bin log文件+position偏移量 来定位需要开始同步的位置
数据一致性问题的解决方案：
- 引出问题：mysql的复制方法默认采用异步的,就是主节点发送了同步数据之后,就不会管从节点是否 同步成功。这样做的弊端是,如果主节点宕机了,从节点还没有同步成功,那么数据就会丢失。 (因为主节点宕机,会选择一个从节点升级未主节点,这样刚才主节点的binlog 文件就丢失了)
- 方案一：全同步复制：只有所有的从库同步完成,才能通知主库继续下面的操作。但是这样做效率太低。
- 方案二：半同步复制：只要有一个从库同步完成,就通知主库继续下面的操作。效率提高
- 方案三：组复制(MGR)：
寄语：涓滴之水终可以磨损大石，不是由于它力量强大，而是由于昼夜不舍的滴坠。
