mysql主从复制过程和监控

mysql主从复制过程

  • 1. 主库与从库的进程
  • 2. 主从复制监控
  • 3. 故障
    • 3.1 io线程故障
    • 3.2 sql 线程故障
  • 4. 主从延时的原因

1. 主库与从库的进程

主库:

Binglog_DUMP Thread  dump

从库:

SLAVE_IO_THREAD    io
SLAVE_SQL_THREAD    sql

图片
mysql主从复制过程和监控_第1张图片
过程:

1.从库执行change master to命令(主库的连接信息+复制的起点)
2.从库会将以上的信息,记录到master.info文件
3.从库执行start slave,立即开启io sql线程
4.从库io_t,读取master.info的信息,获取到ip port user pass bninlog 的位置信息
5.从库io请求连接主库,主库专门提供一个dump,负责和io交互
6.io根据binlog的位置信息,请求主库的新的binlog的
7.主库通过dump将最新的binlog的,通过网络tp诶小从库的io
8.io接收到新的binlog的信息,存储到缓存tcp/ip,立即返回ack给主库,并更新master.info 
9.io将tcp/ip中缓存的数据,转储到磁盘relaylog
10.sql读取relay.info的信息,获取上次已经用过的relaylog的位置信息
11.sql会按照上次的位置回放最新的reloylog的,再次更新relay.info
12.从库会自动的purge应用过得relay进行定期的清理
msyql>help change master to 
CHANGE MASTER TO
  MASTER_HOST='master2.example.com',
  MASTER_USER='replication',
  MASTER_PASSWORD='password',
  MASTER_PORT=3306,
  MASTER_LOG_FILE='master2-bin.001',
  MASTER_LOG_POS=4,
  MASTER_CONNECT_RETRY=10;

补充:

一旦主从复制构建完成,主库中发生了新的变化,都会通过dump发送信号给io,增强了主从复制的实时性

2. 主从复制监控

命令

show slave status \G

信息:

                 主库有关的信息
                  Master_Host: 192.168.80.90
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 10


              
              Master_Log_File: mysql-bin.000014
          Read_Master_Log_Pos: 194
                     从库的relay应用信息
               Relay_Log_File: sjk1-relay-bin.000011
                Relay_Log_Pos: 407
        Relay_Master_Log_File: mysql-bin.000014
                      从库线程的运行状态
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
            过滤复制有关的信息
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:

                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 194
              Relay_Log_Space: 866
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
               从库延时主库的时间(秒
        Seconds_Behind_Master: 0
        
Master_SSL_Verify_Server_Cert: No
          
                      错误查看,原因
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 6
                  Master_UUID: dcb138da-4360-11ec-985d-000c29d2f486
             Master_Info_File: /data/mysql/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           
       GTID复制有关的状态信息
           Retrieved_Gtid_Set: 61deb43b-3b02-11ec-a22a-000c29d2f486:17-56
            Executed_Gtid_Set: 61deb43b-3b02-11ec-a22a-000c29d2f486:1-56
                Auto_Position: 0


         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:

3. 故障

3.1 io线程故障

1.连接主库
网络 连接信息变更过 防火墙 连接数上限
排错:

手动登录
mysql -urepl -p123 -h 192.168.80.90 -P 3306

解决:

stop slave
reset slave all;
change master to 
start slave

  1. binlog没有打开
    主库没有开启binlog
    binlog文件不完整 损坏

主库的reset master 处理
从库

stop slave ;
reset slave all; 
CHANGE MASTER TO 
MASTER_HOST='10.0.0.51',
MASTER_USER='repl',
MASTER_PASSWORD='123',
MASTER_PORT=3307,
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=154,
MASTER_CONNECT_RETRY=10;
start slave;

3.存储binlog到relaylog

3.2 sql 线程故障

relay-log损坏
回放relaylog
研究sql语句失败的原因
库 或 表已经存在
约束冲突,主键,唯一键,非空

处理:
原则:一切以主库为准
反操作,删除从库已存在的库或表

暴力的解决:不建议

方法一:

stop slave; 
set global sql_slave_skip_counter = 1;
start slave;

#将同步指针向下移动一个,如果多次不同步,可以重复操作。
start slave;

方法二:
/etc/my.cnf
slave-skip-errors = 1032,1062,1007

常见错误代码:
1007:对象已存在
1032:无法执行DML
1062:主键冲突,或约束冲突
为了很程度的避免SQL线程故障

为了很程度的避免SQL线程故障
(1) 从库只读
read_only
super_read_only
(2) 使用读写分离中间件
atlas
mycat
ProxySQL
MaxScale

4. 主从延时的原因

主库

1.binlog写入的bujishi
2.默认情况下dump是串行传输的,一步一步按照顺序,到时慢
解决:必须gtid使用gtid commit的方式,支持dump并行
3.主库很繁忙
慢语句
锁等待
从库的个数
网络延时

从库:

1.如果主库的并发事务量很大,由于从库的单sql的线程,导致你不管传多少日志,一次只能执行一个事务
5.6 版本,有了GTID,可以实现多SQL线程,但是只能基于不同库的事务进行并发回放.(database) 
5.7 版本中,有了增强的GTID,增加了seq_no,增加了新型的并发SQL线程模式(logical_clock),MTS技术
2.主从硬件差别大
3.主从的参数配置
4.索引不一样
5.版本有差异
主从延时的监控

show slave  status\G
Seconds_Behind_Master: 0

主库方面原因的监控

主库:
mysql> show master status ;
File: mysql-bin.000001
Position: 1373

从库
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 1373

从库方面原因监控:

拿了多少:
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 691688
执行了多少:
Relay_Log_File: db01-relay-bin.000004
Relay_Log_Pos: 690635
Exec_Master_Log_Pos: 691000
Relay_Log_Space: 690635

你可能感兴趣的:(mysql,mysql,数据库,database)