mysql复制技术 学习笔记---持续更新中

1.  mysql replicat ignore参数：

做Mysql主从时，注意使用replicate_wild_do_table和replicate-wild-ignore-table

使用replicate_do_db和replicate_ignore_db时有一个隐患，跨库更新时会出错。

如在Master（主）服务器上设置 replicate_do_db=test（my.conf中设置）
use mysql;
update test.table1 set ......
那么Slave（从）服务器上第二句将不会被执行

如Master设置 replicate_ignore_db=mysql
use mysql;
update test.table1 set ......
那么Slave上第二句会被忽略执行

原因是设置replicate_do_db或replicate_ignore_db后，MySQL执行sql前检查的是当前默认数据库，所以跨库更新语句在Slave上会被忽略。

可以在Slave上使用 replicate_wild_do_table 和 replicate_wild_ignore_table 来解决跨库更新的问题，如：
replicate_wild_do_table=test.%
或
replicate_wild_ignore_table=mysql.%

 

2.  innodb_flush_log_at_trx_commit， sync_binlog:

innodb_flush_log_at_trx_commit:

值为0 : 提交事务的时候，不立即把 redo log buffer 里的数据刷入磁盘文件的，而是依靠 InnoDB 的主线程每秒执行一次刷新到磁盘。此时可能你提交事务了，结果 mysql 宕机了，然后此时内存里的数据全部丢失。
值为1 : 提交事务的时候，就必须把 redo log 从内存刷入到磁盘文件里去，只要事务提交成功，那么 redo log 就必然在磁盘里了。注意，因为操作系统的“延迟写”特性，此时的刷入只是写到了操作系统的缓冲区中，因此执行同步操作才能保证一定持久化到了硬盘中。
值为2 : 提交事务的时候，把 redo 日志写入磁盘文件对应的 os cache 缓存里去，而不是直接进入磁盘文件，可能 1 秒后才会把 os cache 里的数据写入到磁盘文件里去。

可以看到，只有1才能真正地保证事务的持久性，但是由于刷新操作 fsync() 是阻塞的，直到完成后才返回，我们知道写磁盘的速度是很慢的，因此 MySQL 的性能会明显地下降。如果不在乎事务丢失，0和2能获得更高的性能。

 

sync_binlog:

该参数控制着二进制日志写入磁盘的过程。

该参数的有效值为0 、1、N：

0：默认值。事务提交后，将二进制日志从缓冲写入磁盘，但是不进行刷新操作（fsync()），此时只是写入了操作系统缓冲，若操作系统宕机则会丢失部分二进制日志。

1：事务提交后，将二进制文件写入磁盘并立即执行刷新操作，相当于是同步写入磁盘，不经过操作系统的缓存。

N：每写N次操作系统缓冲就执行一次刷新操作。

将这个参数设为1以上的数值会提高数据库的性能，但同时会伴随数据丢失的风险。
二进制日志文件涉及到数据的恢复，以及想在主从之间获得最大的一致性，那么应该将该参数设置为1，但同时也会造成一定的性能损耗。

 

备库落后主库的时候，可以把 sync_binlog改成30 ，innodb_flush_log_at_trx_commit改成2 ，加快同步。

 

 

3. mysql 半同步复制：（至少一个从库接收到并写到relay log）

从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念

 

异步复制（Asynchronous replication）

MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

全同步复制（Fully synchronous replication）

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

半同步复制（Semisynchronous replication）

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

 

5.7.2版本之后Loss-Less半同步复制，加入新参数： rpl_semi_sync_master_wait_point  有两种取值

 

after_commit在主机事务提交后将日志传送到从机，after_sync是先传再提交。

AFTER_SYNC

这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。

AFTER_COMMIT

老的半同步方案，如图所示。

after sync是在接收ack确认以后主库在引擎层做提交，而after commit是先在引擎层做提交后等待ACK确认。

 

rpl_semi_sync_master_wait_no_slave ：

是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on ，每一个事务都会等待，如果slave当掉后，当slave追赶上master的日志时，可以自动的切换为半同步方式，如果为off,则slave追赶上后，也不会采用半同步的方式复制了，需要手工配置。

说得直白一点，如果我的架构是1主2从，2个从都采用了半同步复制，且设置的是rpl_semi_sync_master_wait_for_slave_count=2，如果其中一个挂掉了，对于rpl_semi_sync_master_wait_no_slave设置为ON的情况，此时显示的仍然是半同步复制，如果rpl_semi_sync_master_wait_no_slave设置为OFF，则会立刻变成异步复制。

 

5.7版本的半同步复制中，独立出一个 ack collector thread ，专门用于接收slave 的反馈信息。这样master 上有两个线程独立工作，可以同时发送binlog 到slave ，和接收slave的反馈。

4. CRC32校验的简单理解：

简而言之，CRC是一个数值。该数值被用于校验数据的正确性。CRC数值简单地说就是通过让你需要做处理的数据除以一个常数而得到的余数。当你得到这个数值后你可以将这个数值附加到你的数据后，当数据被传送到其他地方后，取出原始数据(可能在传送过程中被破坏)与附加的CRC数值，然后将这里的原始数据除以之前那个常数(约定好的)然后得到新的CRC值。比较两个CRC值是否相等即可确认你的数据是否在传送过程中出现错误。 

 

mysql 5.6 同步复制性能提升的两个特性： (第5点和第6点）

5. 基于行的RBR技术中的 数据行图像控制 binlog_row_image 三个参数：

full ：默认级别，即：所有的数据列将会在写入事件后，被记录到二进制的日志中。

minimal：只有发生变化的数据列会被写入到二进制日志中。

noblob： 除非  非文本列或者 blob列被修改的时候，否则这些列的数据都会被忽略。

6. slave_parallel_workers

slave_worker_info 新数据表 会被添加到mysql这个库中，并要把这表的引擎设置成Innodb 。

 alter table mysql.slave_worker_info ENGINE=InnoDB;