mysql扩展

遇到主从不能正常同步，提示uuid相同的错误

1原因：
配置mysql主从时，使用A机器与从A机器克隆出来B机器，B机器拷贝了A机器的mysql目录，导致主从机器的mysql_uuid相同，Slave_IO无法启动，并出现下列信息

The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

2 . 解决办法：
修该主或者从上/usr/local/mysql/data/mysql/auto.cnf 下的uuid的值，使主、从上的mysql不同，修该后重启mysql服务即可

---

mysql主从延迟

1. 延迟原理:
   mysql数据库主从复制都是单线程的操作。

   主库对所有的DDL（数据定义语言）和DML（数据操纵语言）产生binlog，binlog是顺序写，所以效率很高，从上的Slave_IO_Running线程到主库取日志，效率也很高，当从上的slave_SQL_Running线程将主库的DDL和DML操作在从上实施。DDL与DML的IO操作是随机的，不是顺序的，效率会比较慢，还可能slave的其他查询产生lock争用，由于slave_SQL_Running也是单线程的，所以一个DDL卡住了，之后所有的DDL都会等待这个DDL执行完才会继续，这时就出现了延时。如果主库上那个相同的DDL需要执行几分钟，那么slave也会需要等待几分钟。原因是master可以并发，Slave_SQL_Running线程却不可以。

2 . 主从同步延时产生的原因：
当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程的最大承受范围，这时延时就出现了。

3 . 查看mysql延迟（）
（1） 使用show slave status\G查看Seconds_behind_Master下的几个值：

NULL 表示io_thread或者sql_thread有一个发生故障，那么该线程的Running状态为NO

0 表示主从复制良好

正值 表示主从已出现延时，数字越大说明从库落后主库越多。

负值 一般不会出现，出现了也可能是因为BUG

通过比较sql thread接受events时间的时间戳与io thread执行事件events的时间戳的差值（秒数），来确定salve落后master多少，从库relaylog和主库binlog里面的内容是一样的，主从库是通过io_thread来通信的，当主库上IO负载很大或是因为网络堵塞时，io_threada不能实时复制binlog,而sql_thread却能和io_thread保持一致，这时候seconds_behind_master的值显示是0，实际上却不是，所以该方法不准

Seconds_Behind_Master表示slave上SQL thread与IO thread之间的延迟，在MySQL的复制环境中，slave先从master上将binlog拉取到本地（通过IO thread），然后通过SQL thread将binlog重放，而Seconds_Behind_Master表示本地relaylog中未被执行完的那部分的差值

（2）使用pt-heartbeat工具
它可以计算出mysql复制或者是PostgreSQL，借助timestmp来比较实现。保证主从的时间是一致的。
通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面的时间戳ts就是当前的时间戳 now()，该结构也会被复制到从库上。表建好以后

，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这 个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期

+0.5S（默认0.5S延迟检查）去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示 延时的秒数越多

使用工具

1.在主库上建立heartbeat表
pt-heartbeat -h localhost -D test  --create-table --update 

2.更新主库上的heartbeat
pt-heartbeat -D test --master-server-id=1 --update

3.在从库上监控复制延迟
pt-heartbeat --user=tongbu --password='123456' -D test --monitor -h 192.168.244.128 --print-master-server-id



其他一些操作命令：
#将主库上的update使用守护进程方式调度
pt-heartbeat -D test --master-server-id=1 --update --daemonize

#修改主库上的更新时间间隔为2s
pt-heartbeat -D test --update --daemonize --interval=2

#修改主库上的pt-heartbeat守护进程
pt-heartbeat --stop
Successfully created file /tmp/pt-heartbeat-sentinel

rm -rf /tmp/pt-heartbeat-sentinel

#单词查看从库上的延迟情况
pt-heartbeat --user=tongbu --password='123456' -D test  -h 192.168.2.9 --check
0.00

#使用守护进程监控从库并输出日志
pt-heartbeat --user=tongbu --password='123456' -h 192.168.2.9 -D test --master-server-id=1 --monitor --print-master-server-id --daemonize --log=/var/log/pt_slave_lag.log

---

异步复制/半同步复制之间的区别

异步复制： master上的操作记录binlog的同时不关心binlog是否已经被slave接收。

半同步复制：master上的操作记录binlog的同时会关心binlog是否被slave接受。但是由于它的处理逻辑问题可能丢一个事务，

这样的处理流程存在一个问题，当存储引擎提交（storage commit）后，此时如果master挂了那么会存在主从不一致

---