怎么判断复制有没有延迟

• 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高可用核心思想
  • 传统复制&GTID复制
    • 当主服务器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
  • Gtid中引入的新特性,自动补全空洞
• Channel_name
  • 多源复制中哪个来源的标识

复制过滤

• MySQL5.7可以动态的更改从库的过滤规则

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参数时,接收的日志以文本格式写入(意义不大)

复制结构注意事项

• 复制结构数据是不是一致性
• 基于半同步复制,性能方面怎么样
• 如何能高效并安全的使用复制结构
  • 基于5.7增强半同步
  • 将binlog放到存储上