怎么判断复制有没有延迟
- show slave status
- 比较Master_Log_File和Relay_Master_Log_File一致不,不一致延迟大于一个binlog,已经比较大了
- 上面一致在比较Read_Master_Log_Pos和Exec_Master_Log_Pos差多少,如果一致说明没有延迟,差距比较大说明延迟大
- 没有延迟->Master_Log_File==Relay_Master_Log_File&&Read_Master_Log_Pos==Exec_Master_Log_Pos
- 多源复制要用gtid,用Retrieved_Gtid_Set和Executed_Gtid_Set去做对比,判断是否延迟
- mysql高可用核心思想
- 传统复制>ID复制
- 当主服务器crash之后,检测从库是否复制完成
- 复制完成的标志是Master_Log_File==Relay_Master_Log_File&&Read_Master_Log_Pos==Exec_Master_Log_Pos
- 如果没有完成用while等待完成,保证sql_thread在运行,没运行要讲sql_thread启动
- 上述等待时长过长可以直接报警
- 下一步是所有复制完成的机器做冒泡排序,排序的东西是(Master_Log_File,Read_Master_Log_Pos)
- 选出最靠前的一个从库,将其变成主库
- 如果上述从库有大于一个相等的情况,可以自行做一个算法选择
- GTID复制
- 推荐用Retrieved_Gtid_Set和Executed_Gtid_Set去做对比
- 选择执行靠前的做主库
- 复制错误监控
- 先看
- Slave_IO_Running Man=Yes
- Slave_SQL_Running Man=Yes
- 如果为双Yes
- Second_Behind_Master是否大于0
- 如果为NO
- Last_IO_Errno
- Laster_IO_Error
- Last_SQL_Errno
- Laster_SQL_Error
- Relay_Log_Space
- Relay_log什么时间会删除掉
- 代码里的逻辑:在产生新的Relay_log时,会把执行完的Relay_log删除
- 或者从库上调用flush logs也会删除执行完的Relay_log
- Until Condition
- None
- Master:指定Slave必须执行到Master的某个binlog及位置
- Relay:指定Slave必须执行到Relay log里的指定的binlog及位置
- SQL_Before_gtids:指定的某个GTID之前停下来 小于概念
- SQL_After_gtids:指定的某个GTID之后,等于指定的GTID停下来 等于概念
- start slave ... until
- 指定同步到某个位置
- 并行复制
- start slave until SQL_AFTER_MTS_GAPS;
- set global slave_parallel_workers=0; #停止并行复制
- start slave sql_thread;
- Last_IO_Errno & Laster_IO_Error
- IO_thread的出错代码以及消息出错的时间位置可以结合:Last_SQL_Error_Timestamp方便在主库上找到位置
- Last_SQL_Errno & Laster_SQL_Error
- SQL_thread出错信息,如果这里有信息会输出到Error log中
- 在5.7.2后这个信息会记录到performance_schema.replication_applier_status_coordinator中
- 处理位置的时间可以参考:Last_SQL_Error_Timestamp
- SQL_Delay
- Master_bind
- Master_Server_id
- Master_UUID
- Retrieved_Gtid_Set
- Slave获取到Master上的GTID,并不马上执行,有可能在Relay-log中存放.reset slave:change master to,relay-log-recover对这个值有影响
- Executed_Gtid_Set
- 表示已经执行写入Binlog中的GTID事务,和gtid_executed值相同
- Auto_Position
- Channel_name
复制过滤
CHANGE REPLICATION FILTER filter[, filter][, ...]
filter:
REPLICATE_DO_DB = (db_list)
| REPLICATE_IGNORE_DB = (db_list)
| REPLICATE_DO_TABLE = (tbl_list)
| REPLICATE_IGNORE_TABLE = (tbl_list)
| REPLICATE_WILD_DO_TABLE = (wild_tbl_list)
| REPLICATE_WILD_IGNORE_TABLE = (wild_tbl_list)
| REPLICATE_REWRITE_DB = (db_pair_list)
db_list:
db_name[, db_name][, ...]
tbl_list:
db_name.table_name[, db_table_name][, ...]
wild_tbl_list:
'db_pattern.table_pattern'[, 'db_pattern.table_pattern'][, ...]
db_pair_list:
(db_pair)[, (db_pair)][, ...]
db_pair:
from_db, to_db
- 建议:
- binlog_format=row
- 过滤规则在从库设置
binlog server
- binlog放置在共享存储
- 利用mysqlbinlog命令备份远程的Binlog
mysqlbinlog --read-from-remote-server --raw --host=xxx --port=xxx --user=xxx --password=xxx --stop-never mysql-bin.000001
- read-from-remote-server|-R 指定需要备份的实现IP或Hostname
- raw 指定存储格式是binary log format
- host 需要有一个复制replication slave权限
- port 端口号
- stop-never 不要停,直到远程Server退出或是终止本连接
- stop-never-slave-server-id 默认使用65535这个ID,如果冲突,可以声明
- to-last-log 备份到哪个日志停止,如果stop-never声明了.这个参数会被忽略
- 特别注意:
- 使用raw连接master时,以4K为单位写入磁盘.并不能实时写入磁盘.和主库断开,flush logs都会实时把日志写入磁盘
- 如果不使用raw参数时,接收的日志以文本格式写入(意义不大)
复制结构注意事项
- 复制结构数据是不是一致性
- 基于半同步复制,性能方面怎么样
- 如何能高效并安全的使用复制结构
