mysql小白系列_10 mysql主从复制原理

1.如何解决主从复制延迟的问题？

(1)主从复制原理

http://www.cnblogs.com/jenvid/p/8410922.html

• 1.salve执行slave start，salve服务IO线程会通过授权的用户连接上master，并请求master从指定的文件和位置之后发送bin-log日志内容
• 2.master服务器接收到来自slave服务器的IO线程请求后，master服务器上的IO线程根据slave服务器发送的指定bin-log日志之后的内容，然后返回给slave的IO线程，返回的信息中出了bin-log日志内容wait，还有本次返回日志内容后在master服务器端新的binlog文件名已经在binlog中的下一个指定更新位
• 3.slave的IO线程接收到信息后，将接收到的日志内容依次添加到salve端的relay-log文件的最末端，并将读取到的master端的bin-log的文件名和位置记录到master-info文件中，以便下一次读取的时候能够清楚的告诉master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”、
• 4.slave的SQL线程检测到relay-log中新增了内容后，会马上解析relay-log的内容成为master端真实执行时候的那些可执行的内容，并在自身执行。

(2)产生延迟的原因

• 1.主从复制是单线程操作，异步进行
• 2.master的binlog是顺序读写，效率高、吞吐量高，DDL/DML是并发操作的
• 3.slave的relay-log实施的时候，DML和DLL是随机操作且Slave_SQL_Running是单线程的，如果还有lock争用，成本就更高了
• 4.master TPS并发高峰时，产生的DDL数量超过slave一个sql线程所能承受的范围，延迟就产生了
• 5.max_allowed_packet主从不一致
• 6.自增ID起始位置不一样
• 7.主高从低版本不一致，新特性不兼容

(3)解决延迟问题

• 1.主库DDL快速执行DDL操作
• 2.主库设置双1，sync_binlog=1 innodb_flush_log_at_trx_commit=1
• 3.从库上可以设置为双0
• 4.slave_net_timeoutslave读取log数据失败后，等待多久重新建立连接并获取数据
• 5.master-connect-retry重新建立主从连接时，如果连接失败，重试的等待时间
• 6.从库使用更好的硬件
• 7.专用slave服务器，专用读服务器，专用备份服务器
• 8.使用semi_sync插件进行半同步，损失性能

2.如何判断主从复制是否同步？

(1)show slave status\G

             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 0

Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较的差值

(2)如果Relay_master_Log_File == Master_Log_File

1. Read_Master_Log_Pos == Exec_Master_Log_Pos，则认为是同步的

2. 主库show master status\G的Position与从库的Read_Master_Log_Pos相等，也是同步的

(3)使用第三方工具

mk-heartbeat，Maatkit

3.以下参数设为1怎么理解？

set global sql_slave_skip_counter=1;

https://dev.mysql.com/doc/refman/5.6/en/set-global-sql-slave-skip-counter.html

• (1)从库需要跳过某个无法执行的命令，在slave stop的状态下设置global sql_slave_skip_counter=N，跳过接下来的N个事件

一个event group包含多个有序的events

一个insert包含三个event，begin/insert/commit

对于事务性的表，一个event group代表一个事务

对于非事务性的表，一个event group代表一个单独的SQL语句

• (2)N=1，会跳过若干个event，直到当前所在事务结束
• (3)N>1，则每跳过一个event都要N--

http://dinglin.iteye.com/blog/1236330