mysql半同步复制
半同步的特性
收到ack或者超时关闭半同步
从库只有将binlog flush到repay log才会给主库的等待线程发送ack
超时转换为异步复制后,当至少一个半同步从节点赶上来是,主库便会自动转换为半同步复制
半同步必须在主从库上都是打开的状态,否则便为异步复制
相较于异步复制,半同步变慢时间至少是TCP/IP一次发送与接收所用的时间(多IDC部署本地至少有一个slave)
半同步主库端
after_flush -- 最后一个event才需要发送ACK
after_sync -- 从库数据可能会多余主库数据
after_commit -- 从库会丢数据,主库是commit后再等待
after_rollback -- 同after_commit
transmit_start -- 发送binlog之前做判断,所有等待这个点的主库线程都可以不等了,直接commit
transmit_stop -- 主库想从库发送完binlog结束之后
defore_send_event -- 发送binlog之前,是否需要从库发送ACK信息
after_send_event -- binlog发送完成之后,
after_reset_master -- reset_master语句执行之后
半同步从库端
半同步实现
插件安装
半同步自动开关
MySQL5.7多线程复制
延迟优化方法
增加buffer_pool的大小、缓存更多数据,减少IO压力
增大log_buffer_size及group,减少buffer_pool的刷盘IO,提升写入性能
修改flush_method为O_DIRECT,提升写入性能
如果可以的话,关掉从库binlog,或者log_slave_uodates
修改参数innodb_flush_log_at_trx_commit为0或者2
如果没有关掉binlog,修改参数sync_binlog为0或者更大的数,减少IO的压力
MySQL5.6多线程复制
1.数据库比较多
2.每个数据库的写入比较均匀
因为MySQL5.6复制分发级别设置的是库
MySQL5.7多线程复制
所有处于prepare阶段的事务都可以并行提交
last_commit
ordered commit
flush:stage #1 flushing trans to bin log
binlog写入文件
写入成功后通知dump线程dump binlog发送给slave
sync:stage #2 syncing binlog file to disk
commit:stage #3 commit all trans in order.(取决于参数binlog_order_commits设置)
多线程复制分发原理
比较last_commit与sequence_number
异常故障恢复
1.找到链接主库的信息-- slave_master_info
2.找到复制位置及线程个数 -- slave_relay_log_info
3.找到每个线程的复制信息 -- slave_worker_info
大量MySQL表导致复制变慢的问题
performance_schema_max_file_instances=open_file_limit/0.65
快速删除大表
buffer pool mutex
flush list mutex
通过创建硬链接的方式删除ibd文件 --分块truncate os大文件
galera cluster的处理
单实例set @@session.wsrep_on=off;ln硬链接;drop table xxx; -- 循环所有实例
两条不同的插入语句导致的死锁
环形死锁
唯一索引,联合唯一索引
隔离级别
gap锁
MySQL在并发删除同一行数据时导致死锁的分析
并发数
隔离级别
业务控制
参数sql_slave_skip_counter的奥秘
sql_slave_skip_counter=1,跳过整个事务,多个事件,有可能包含多个dml,跳过后确定是否需要修补数据
sql_slave_skip_counter>1,跳过一个事件减1,不可控
binlog中的时间戳