MySQL主从复制简单介绍、重建、中断处理-----给开发、测试人员的培训

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
日志服务 SLS,月写入数据量 50GB 1个月
简介:

前几天给开发做了MySQL主从复制相关的培训,主要是让他们了解一下相关的情况,对中断进行简单的处理。

本文主要对MySQL主从复制进行简单的介绍,包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。

欢迎转载,请注明作者、出处。

作者:张正
blog:http://space.itpub.net/26355921 
QQ:176036317
如有疑问,欢迎联系。



MySQL主从复制

MySQL主从复制、搭建、状态检查、中断排查及备库重做

2014/8/27

 


本文档主要对MySQL主从复制进行简单的介绍,包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。

 


 TOC \o "1-3" \h \z \u 一、MySQL主从复制概述... 

1、主从复制简介... 

2、主从复制原理、机制... 

3、主从复制原理图... 

二、MySQL主从复制搭建... 

1Master端配置部署... 

2Slave端配置部署... 

3、建立主从同步... 

三、主从复制状态检查及异常处理... 

1、主从复制状态检查... 

2IO_thread异常... 

3sql_thread异常... 

4、主从复制延迟... 

一、MySQL主从复制概述

1、主从复制简介

MySQL主从复制就是将一个MySQL实例(Master)中的数据实时复制到另一个MySQL实例(slave)中,而且这个复制是一个异步复制的过程。

实现整个复制操作主要由三个进程完成的,其中两个进程在Slavesql_threadIO_thread),另外一个进程在 MasterIO进程)上。

2、主从复制原理、机制

要实施复制,首先必须打开Master端的binary logbin-log)功能,否则无法实现。因为整个复制过程实际上就是SlaveMaster端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

复制的基本过程如下:

1)、Slave上面的IO_thread连接上Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容;

2)、Master接收到来自SlaveIO_thread的请求后,通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息,返回给Slave IO_thread。返回信息中除了日志所包含的信息之外,还包括本次返回的信息已经到Master端的bin-log file的以及bin-log pos

3)、SlaveIO_thread接收到信息后,将接收到的日志内容依次添加到Slave端的relay-log文件的最末端,并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中,以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪 个位置开始往后的日志内容,请发给我”;

4)、SlaveSql_thread检测到relay-log中新增加了内容后,会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容,并在本数据库中执行。

 3、主从复制原理图


 


 

 

二、MySQL主从复制搭建

MySQL主从复制搭建主要步骤有:Master端配置部署、Slave端配置部署、建立主从同步

 

1、Master端配置部署

         a、 配置参数:

[mysqld]

server-id=101  # 这个要保证一个主从复制环境中,不要有相同的server-id

log-bin=/data/mysql6001/binlog/mysql-bin.log

log-bin-index=/data/mysql6001/binlog/mysql-bin.index

expire_logs_days=30

         b、 创建用户,并赋予权限:

         GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%' IDENTIFIED BY PASSWORD '******';

       

2、Slave端配置部署

         a、 配置参数:

[mysqld]

server-id=102 

relay-log=/data/mysql6001/relaylog/mysql-relay-bin.log

relay-log-index=/data/mysql6001/relaylog/mysql-relay-bin.index

relay_log_purge=on

 

3、建立主从同步

(重建备库也是使用该方法)

 

         建立主从同步可以从主库上导出数据,也可以从已有的从库上导出数据,然后再导入到新的从库中,change master to建立同步。

3.1 、导出数据

在主库上导出数据:

mysqldump -u*** -p*** -S /data/mysql6001/mysql.sock --default-character-set=utf8 -q --single-transaction --master-data -A  >  /tmp/all_database.sql

(或者)在从库上导出数据:

mysqldump -u*** -p*** -S /data/mysql6001/mysql.sock --default-character-set=utf8 -q --single-transaction --dump-slave -A  >  /tmp/all_database.sql

NOTES

--master-data--dump-slave导出的备份中,会包含master_log_filemaster_log_pos信息。

3.2 、从库导入数据

mysql -u*** -p*** --default-character-set=utf8 < all_database.sql

NOTES

此处导入脚本,就已经在从库中执行了以下操作:

change_master_to

master_log_file=' mysql-bin.000xxx',

master_log_pos=xxxxxx;

3.3 、从库与主机建立同步

以下为建立主从同步最基本的6个项:

change master to

master_host='xxx.xxx.xxx.xxx',     # 主库IP

master_port=6001,              # 主库mysqld的端口

master_user='repl',              # 主库中创建的有REPLICATION SLAVE 权限的用户

master_password='xxxxxxxx',      # 该用户的密码

master_log_file=' mysql-bin.000xxx', # 已在导入时指定了

master_log_pos=xxxxxx;          #已在导入时指定了

指定与主库同步的基本信息后,就可以启动slave进程了:(IO_threadsql_thread

start slave;

三、主从复制状态检查及异常处理

1、主从复制状态检查

主库查看binlog情况:

show master status\G

*************************** 1. row ***************************

            File: mysql-bin.000303

        Position: 18711563

    Binlog_Do_DB:

Binlog_Ignore_DB:

 

在从库上主要是使用以下命令查看从库与主库的同步状态:

show slave status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.43.128    #主库IP

                  Master_User: repl             #主库复制的用户

                  Master_Port: 6001             #主库mysqld端口

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000303   #io_thread读取主库master_log_file

          Read_Master_Log_Pos: 18711563        # io_thread读取主库master_log_pos

               Relay_Log_File: mysql-relay-bin.000900

                Relay_Log_Pos: 18711709

        Relay_Master_Log_File: mysql-bin.000303  #sql_thread执行主库的master_log_file

             Slave_IO_Running: Yes             #关键的,io_thread是否running

            Slave_SQL_Running: Yes             #关键的,sql_thread是否running

              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: 18711563       #sql_thread执行主库的master_log_pos

              Relay_Log_Space: 18711908

              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: 101

1 row in set (0.00 sec)

 

2、IO_thread异常

         IO_thread异常,状态往往是Slave_IO_Running: Connecting NO

         IO_thread是向Master发送请求读取master binlog,如果处于Connecting状态,说明无法正确地与Master进行连接,可能的原因有:

         a网络不通(是否打开防火墙)

         b复制用户的密码不对

         c指定的master_port端口不对

         dmaster上的mysql-bin.xxxxxx被误删

         e主库磁盘空间满了

         通过show slave status\G可以看到相关错误信息,例如:

show slave status\G

Last_IO_Errno: 2003

Last_IO_Error: error connecting to master 'repl@192.168.43.128:3306' - retry-time: 60      

            retries: 86400

或者通过错误日志看到相关信息,如:

140828 15:47:20 [ERROR] Slave I/O: error connecting to master 'repl@192.168.43.128:3306' -  

              retry-time: 60  retries: 86400, Error_code: 2003

140828 15:47:21 [Note] Event Scheduler: Loaded 0 events

140828 15:47:21 [Note] /home/mysql/mysql/bin/mysqld: ready for connections.

3、sql_thread异常

         sql_thread发生异常,状态就会变为Slave_SQL_Running: NO

         sql_thread发生异常的情况非常多,发生异常后,需要通过以下方法排查和解决:

         a、对比主库和从库的二进制日志的情况:

主库:

show master status\G

            File: mysql-bin.000303

        Position: 18711563

从库:

show slave status\G

               Master_Log_File: mysql-bin.000303   --IO_thread

          Read_Master_Log_Pos: 18711563          --IO_thread

          Relay_Master_Log_File: mysql-bin.000303   --sql_thread

           Exec_Master_Log_Pos: 18711163          --sql_thread

 

         b、通过show slave status\G查看错误信息:

show slave status\G

Last_SQL_Errno: 1062

Last_SQL_Error: Error 'Duplicate entry '1' for key 'PRIMARY'' on query. Default database:

             'test'. Query: 'insert into test values(1,2,3,4,5,6)'

 

         c、 通过错误日志查看错误信息:

140828 16:27:51 [ERROR] Slave SQL: Error 'Duplicate entry '1' for key 'PRIMARY'' on query.

              Default database: 'test'. Query: 'insert into test values(1,2,3,4,5,6)',

              Error_code: 1062

140828 16:27:51 [Warning] Slave: Duplicate entry '1' for key 'PRIMARY' Error_code: 1062

140828 16:27:51 [ERROR] Error running query, slave SQL thread aborted. Fix the problem,

              and restart the slave SQL thread with "SLAVE START". We stopped at log

              'mysql-bin.000303' position 18711163

 

         根据这些报错信息,往往就能够定位到发生异常的原因。如果我们了解产生异常的具体事件,而且能够掌控,可以通过设置sql_slave_skip_counter参数来跳过当前错误。

set global sql_slave_skip_counter=1;

         或者使用slave_skip_errors参数(read only variable),指定跳过某种类型的错误:

参数文件中设置:

slave_skip_errors=1062     #跳过1062错误

         遇到错误时,不要一通百度后,然后根据看起来很类似的操作直接来进行操作。因为网上大部分解决sql_thread异常的方法是:

         a直接set global sql_slave_skip_counter=n; n设置很大的值,即:跳过所有错误),

         b设置slave_skip_errors=all;  跳过所有类型的错误

         c直接查看主库的binlog,然后在从库上直接执行change master to

         这些方法都会导致主从数据不一致。

 

         如果发现从库与主库差异太大,无法通过手动操作数据修改重新建立同步。可以参考上述"MySQL主从复制搭建" 重新搭建从库。

4、主从复制延迟

主从复制延迟,可能的原因有:

a主从同步延迟与系统时间的关系,查看主从两台机器间系统时间差

b主从同步延迟与压力、网络、机器性能的关系,查看从库的iocpumem及网络            

c主从同步延迟与lock锁的关系(myisam表读时会堵塞写),尽量避免使用myisam      表。         一个实例里面尽量减少数据库的数量。

d、主从复制发生异常而中断,过很久之后才发现复制异常。可通过查看masterslavestatus估算相差的日志。如果相差太大,则可以考虑重做从库。

最后附上本文的完整文档,需要忽悠开发或测试人员的,赶紧get了:
MySQL主从复制.docx
本文转自ITPUB博客84223932的博客,原文链接:MySQL主从复制简单介绍、重建、中断处理-----给开发、测试人员的培训,如需转载请自行联系原博主。
相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
相关文章
|
1月前
|
存储 测试技术 API
数据驱动开发软件测试脚本
今天刚提交了我的新作《带着ChatGPT玩转软件开发》给出版社,在写作期间跟着ChatGPT学到许多新知识。下面分享数据驱动开发软件测试脚本。
51 0
|
7月前
|
数据采集 算法 测试技术
【硬件测试】基于FPGA的1024QAM基带通信系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文介绍了基于FPGA的1024QAM基带通信系统的硬件测试版本,包含testbench、高斯信道模块和误码率统计模块。系统新增ila在线数据采集和vio在线SNR设置模块,支持不同SNR条件下的性能测试。1024QAM调制将10比特映射到复平面上的1024个星座点之一,实现高效数据传输。硬件测试结果表明,在SNR=32dB和40dB时,系统表现出良好的性能。Verilog核心程序展示了各模块的连接与功能实现。
163 7
|
6月前
|
机器学习/深度学习 人工智能 并行计算
AI部署架构:A100、H100、A800、H800、H20的差异以及如何选型?开发、测试、生产环境如何进行AI大模型部署架构?
AI部署架构:A100、H100、A800、H800、H20的差异以及如何选型?开发、测试、生产环境如何进行AI大模型部署架构?
AI部署架构:A100、H100、A800、H800、H20的差异以及如何选型?开发、测试、生产环境如何进行AI大模型部署架构?
|
4月前
|
传感器 人工智能 JavaScript
鸿蒙开发:DevEcoTesting中的稳定性测试
DevEcoTesting主要的目的也是用于软件的测试,可以让开发者无需复杂的配置,即可一键执行测试任务,同时提供了测试报告和分析,无论是对于开发者还是测试同学来说,都是一个非常方便的工具。
163 3
鸿蒙开发:DevEcoTesting中的稳定性测试
|
3月前
|
敏捷开发 运维 数据可视化
DevOps看板工具中的协作功能:如何打破开发、测试与运维之间的沟通壁垒
在DevOps实践中,看板工具通过可视化任务管理和自动化流程,提升开发与运维团队的协作效率。它支持敏捷开发、持续交付,助力团队高效应对需求变化,实现跨职能协作与流程优化。
|
3月前
|
运维 jenkins 测试技术
"还在苦等开发部署环境?3步教你用Jenkins拿回测试主动权"
测试工程师最头疼的问题是什么?依赖开发部署环境! 开发延期→测试时间被压缩→紧急上线后BUG频出→测试背锅。传统流程中,测试被动等待部署,效率低下。而Jenkins自动化部署让测试人员自主搭建环境,实现: ✅ 随时触发测试,不再苦等开发 ✅ 部署效率提升10倍,抢回测试时间 ✅ 改善团队协作,减少互相甩锅 学习Jenkins部署能力,成为高效测试工程师,告别被动等待!
|
7月前
|
数据采集 算法 数据安全/隐私保护
【硬件测试】基于FPGA的4ASK调制解调通信系统开发与硬件片内测试,包含信道模块,误码统计模块,可设置SNR
本文介绍了基于FPGA的4ASK调制解调系统的硬件测试版本,该系统包括testbench、高斯信道模块和误码率统计模块,并新增了ILA在线数据采集和VIO在线SNR设置功能。通过VIO设置不同SNR(如15dB和25dB),实现了对系统性能的实时监测与调整。4ASK是一种通过改变载波幅度表示数据的数字调制方式,适用于多种通信场景。FPGA平台的高效性和灵活性使其成为构建高性能通信系统的理想选择。
168 17
|
6月前
|
SQL 缓存 关系型数据库
使用温InnoDB缓冲池启动MySQL测试
使用温InnoDB缓冲池启动MySQL测试
122 0
|
6月前
|
SQL 缓存 关系型数据库
MySQL8.4 Enterprise安装Firewall及测试
MySQL8.4 Enterprise安装Firewall及测试
161 0
|
6月前
|
安全 关系型数据库 MySQL
MySQL8使用物理文件恢复MyISAM表测试
MySQL8使用物理文件恢复MyISAM表测试
104 0

推荐镜像

更多