1.如何解决主从复制延迟的问题？
(1)主从复制原理
- 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 statusG
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
-
Read_Master_Log_Pos==Exec_Master_Log_Pos，则认为是同步的 -
主库
show master statusG的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--