mysql主从复制
1、MySQL主从复制
1.1 为何须要主从？
数据库损坏了（业务不能使用数据库）
缘由：mysql
- 外在缘由
- 网络
- 业务应用有问题
- 自己缘由
- 物理损坏：机器坏了、硬盘损坏、存储坏了、数据文件损坏
- 逻辑损坏：错误的drop、delete、truncate、update。。。
解决方案：linux
- 备份（物理损坏丢失数据）
- 主从复制
1.2 MySQL复制介绍
复制是MySQL的一项功能，容许服务器将更改从一个实例复制到另外一个实例。web
- 主服务器将全部数据和结构更改记录到二进制日志中。
- 从属服务器从主服务器请求该二进制日志并在本地应用其内容。
1.2.1 复制做用：
- 高可用
- 辅助备份
- 分担负载
1.2.2 应用场景：
- 应用场景1：从服务器做为主服务器的实时数据备份
- 应用场景2：主从服务器实现读写分离，从服务器实现负载均衡
- 应用场景3：把多个从服务器根据业务重要性进行拆分访问
1.2.3 复制前提
- 主服务器必须开启二进制日志（binlog）
- 多台服务器
- 保证开始复制时主从服务器结构一致。
- 对于新建的数据库能够直接进行复制；
- 对于运行了一段时间的数据库，就要经过备份让主从数据库结构保证一致。
- 主库必需要有对从库复制请求的用户
- 从库须要有relay-log设置，存放从主库传来的binlog
- 首次链接，从库须要change master to链接主库
- 须要保存change master信息须要存放在master.info文件中
- 经过relay-log.info里记录的已经使用过的事件，从库知道主库发生了变化
- 复制中的线程
- 主库
- dump thread：负责响应从库的IO线程
- 从库
- IO thread ：负责链接主库，请求binlog，接收binlog并写入relay-log
- SQL thread ：复制执行relay-log中的事件
- 主库
1.2.4 复制原理
异步复制过程
整体来讲，复制有3个步骤：sql
- 主服务器把数据更改记录到二进制日志中。（这叫作二进制日志事件）
- 从服务器把主服务器的二进制日志拷贝到本身的中继日志中。
- 从服务器和主服务器之间创建master/slave链接，相关信息存放在从服务器的master.info文件中
- 从服务器用IO线程询问主服务器是否有新的binlog
- 主服务器用dump线程读取binlog并发送给从服务器
- 从服务器接收binlog并存放在relay-log中
- 从服务器的SQL线程执行relay-log中的binlog，写入数据库
- 执行完毕的relay-log放在relay-log.info文件中
- 从服务器重放中继日志中的事件，把更改应用到本身的数据上。
1.3 主从复制部署
两台主机安装mysql 5.6
注意在两台主机的配置文件中/etc/my.cnf中须要添加server-id=参数。shell
-
建立复制用户数据库
grant replication slave on *.* to repl@'10.0.0.%' identified by '123';
-
初始化从库安全
[root@db01 ~]# mysqldump -uroot -poldboy123 -A -F > /tmp/server.sql [root@db01 ~]# scp /tmp/server.sql 10.0.0.8:/tmp 在从库中source执行
-
开启主从复制服务器
- 在主库中查看binlog起始点：
mysql> mysql> show master; +----------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------------+----------+--------------+------------------+-------------------+ | log-bin.000013 | 120 | | | | +----------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
- 从库开启复制：
mysql> change master to master_host='10.0.0.51', master_port=3306, master_user='repl', master_password='123', master_log_file='log-bin.000013', master_log_pos=120;
注意：也能够设置relay-bin的名称。网络
-
检查状态架构
start slave; show slave status\G
成功的标志是：
Slave_IO_Running: Yes Slave_SQL_Running: Yes
1.4 监控主从复制状态
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.51
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: log-bin.000014
Read_Master_Log_Pos: 120
Relay_Log_File: web01-relay-bin.000002
Relay_Log_Pos: 281
Relay_Master_Log_File: log-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: 120
Relay_Log_Space: 454
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: 1
Master_UUID: d4519488-d005-11e7-a4ac-000c2924dc94
Master_Info_File: /application/mysql-5.6.38-linux-glibc2.12-x86_64/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0
1 row in set (0.00 sec)
1.4.1 注意事项
-
Slave_*_Running：
- Slave_IO_RunningI/O 线程正在运行、未运行仍是正在运行但还没有链接到主服务器。可能值分别为Yes、No 或Connecting。
- Slave_SQL_RunningSQL 线程当前正在运行、未运行,可能值分别为Yes、No
-
主服务器日志坐标：
- Master_Log_File和Read_Master_Log_Pos标识主服务器二进制日志中I/O 线程已经传输的最近事件的坐标。
- 若是Master_Log_File和Read_Master_Log_Pos的值远远落后于主服务器上的那些值，这表示主服务器与从属服务器之间事件的网络传输可能存在延迟。
-
中继日志坐标：
- Relay_Log_File和Relay_Log_Pos列标识从属服务器中继日志中SQL 线程已经执行的最近事件的坐标。这些坐标对应于Relay_Master_Log_File和Exec_Master_Log_Pos列标识的主服务器二进制日志中的坐标。
- 若是Relay_Master_Log_File和Exec_Master_Log_Pos列的输出远远落后于Master_Log_File和Read_Master_Log_Pos列（表示I/O 线程的坐标），这表示SQL 线程（而不是I/O 线程）中存在延迟。即，它表示复制日志事件快于执行这些事件。
-
Last_IO_Error、Last_SQL_Error：
+分别致使I/O 线程或SQL 线程中止的最新错误的错误消息。在正常复制过程当中，这些字段是空的。若是发生错误并致使消息显示在以上任一字段中，则错误值也显示在错误日志中。 -
Last_IO_Errno、Last_SQL_Errno：
- 与分别致使I/O 线程或SQL 线程中止的最新错误关联的错误编号。在正常复制过程当中，这些字段包含编号0。
- Last_IO_Error_Timestamp、Last_SQL_Error_Timestamp：
- 分别致使I/O 线程或SQL 线程中止的最新错误的时间戳，格式为YYMMDD HH:MM:SS。在正常复制过程当中，这些字段是空的。
1.4.2 错误实例
-
从库binlog落后于主库
Master_Log_File: log-bin.000014 Read_Master_Log_Pos: 120
从库的logbin比主库的logbin慢的缘由：
- 网络问题
- 主库dump线程繁忙
- 从库IO线程繁忙
【扩展】
延时节点概念：是SQL线程延时，不是IO线程延时。 - SQL线程报错
缘由：- 主库操做对象在从库中不存在
- 主库操做对象的属性和从库不一致
- 主从操做顺序颠倒
解决方法：
- 跳过错误
stop slave; set global sql_slave_skip_counter = 1; start slave;
也能够在配置文件中跳过错误号码：
[mysqld] slave-skip-errors = 1032,1062,1007
1.5 企业实例
- 背景：标准主从复制结构，在业务逻辑中有oldboy数据库，oldboy数据库下有t1表为生产表。
- 故障缘由：开发人员在从库建立了一个oldgirl库，以为不对，后又在主库中作了相同的操做。致使了从库复制失效。
- 解决方案：
主从复制故障及解决stop slave; #<==临时中止同步开关。 set global sql_slave_skip_counter= 1 ; #<==将同步指针向下移动一个，若是屡次不一样步，能够重复操做。 start slave; /etc/my.cnf slave-skip-errors = 1032,1062,1007
- 如何避免问题？
- 从库设置为只读库
在my.cnf中添加read_only=1 - 单独在从库建立一个只读用户
在主库建立写用户
优势： - 配置时不须要重启
- 故障切换时也不须要重启
- 从库设置为只读库
1.6 主从架构演变
备份
- 至关于实时备份
- 使用从库备份
问题：
若是从库只是做为备份服务器使用，那么主库的压力会增长，由于全部的业务都在主库进行读写（dump线程读取并发送给binlog）
解决方法：
- 一主一从
分出部分读业务到从库（读写分离） - 一主多从，分担压力（针对读业务多的需求）
可是这种一主多从的模式会使dump线程压力更大了 - 多级主从
使用中间库分担主库dump线程读取分发binlog的压力，因为中间库只做为分发者，不须要其余操做，为了提升中间库的性能，可使用blackhole存储引擎。 - 双主模型
- 环状复制
1.7 高级应用架构
-
性能
- 读写分离——MySQLproxy、amoeba、xx-dbproxy等。
- 分库分表——cobar、自主研发等。
比较依赖于业务 - 实施思路：
- 判断语句类型
- 根据语句类型进行分发
- 负载均衡，分发到从库
- 会话持续性（减小用户认证之类的操做）
- 判断语句是否执行过（提升性能，减小重复操做）
- 高可用
- MMM架构——mysql-mmm（google）（不在使用）
- MHA架构——mysql-master-ha（日本DeNa）
- MGR ——5.7 新特性MySQLGroup replication
- PXC、MySQLCluster架构
1.8 多级主从部署（级联主从）
相似于一主一从的部署
不一样之处在于主从之间多了一个中间服务器
[mysqld] basedir = /application/mysql/ datadir = /application/mysql/data/ socket = /application/mysql/tmp/mysql.sock character_set_server=utf8 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES server-id = 2 log-bin=/tmp/log-bin binlog-format=row autocommit=1 log-slave-updates [client] socket = /application/mysql/tmp/mysql.sock
在中间服务器的my.cnf文件中须要开启binlog并添加log-slave-updates参数，表示强制刷新binlog，不然binlog日志不会刷新。
至关于作了两套主从。
reset slave；重置slave（关闭状态）
1.9 扩展
1.9.1 复制延时
- 问题：
主服务器的错误操做会同步到从服务器，致使数据恢复比较麻烦。 - 解决方法：
采用复制延时，这样主服务器操做错误，从服务器因为延时复制能够在一段时间内避免应用错误操做，这样就能够及时恢复数据。
复制延时是在SQL线程的层面进行控制，不容许SQL线程实时的执行relay log中的操做。
- 如何设置：
stop slave;
change master to master_delay = 30; #单位是秒
start slave;
结果：
```shell
mysql> show slave status\G
SQL_Delay: 30
SQL_Remaining_Delay: NULL
生产场景中通常延时3-6小时
1.9.2 半同步复制
- 注重安全，不注重性能
- 普通异步主从中从库的同步率是不可控的，总会有延时的
- 对于安全性要求比较高的应用场景，好比金融、运营商等不会使用普通异步主从架构。
- 为了让MySQL更加可以适用于高安全性的场景才有了半同步复制。
- 半同步基于dump线程和IO线程，省略了SQL线程读取写入的部分
部署：
一、加载插件
主:
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
从:
INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
二、查看是否加载成功:
show plugins;
三、启动:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
只是临时启动，须要写入配置文件中。
四、重启从库上的IO线程
STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
五、查看是否在运行
主:
show status like 'Rpl_semi_sync_master_status';
从:
show status like 'Rpl_semi_sync_slave_status';
1.9.3 主从同步的故障转移（failover）
MHA设计理念：
主服务器宕掉了，可是多台从服务器的数据和主服务器同步不完整，这时就须要整合多台从服务器中的同步的数据到新的主服务器中，尽可能保证数据的完整性。
- 选择新主
- 数据补偿：判断新主服务器和其余从节点数据的新旧，补全本身的数据，尽可能恢复到比较新的数据，或者去旧主服务器中获取binlog日志补全本身的数据
- 启动新主，将其余从服务器指向新主
- 公布新主
1.9.4 GTID复制
中继日志（relay log）：记录了events和position号
在执行的事务中打上一个惟一标签，这样就能够保证事务之间的连续性及惟一性
为了failover出现的更好的复制，5.6出现，5.7完善
GTID(Global Transaction ID)是对于一个已提交事务的编号，而且是一个全局惟一的编号。
它的官方定义以下：
GTID = source_id ：transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29
[root@web01 ~]# cat /application/mysql/data/auto.cnf [auto] server-uuid=0b920fba-d0fa-11e7-aae4-000c292741de
注意：若是是克隆的mysql数据库，那么server-uuid相同会致使slave-IO没法启动，须要修改server-uuid
- 部署过程
环境：
须要两台mysql数据库服务器，一台为主服务器，一台为从服务器。
一、修改配置文件
主：
[mysqld] log_bin = /tmp/log-bin binlog-format = row basedir = /application/mysql/ datadir = /application/mysql/data socket = /application/mysql/tmp/mysql.sock server_id = 1 gtid-mode = on #启用gtid类型，不然就是普通的复制架构 enforce-gtid-consistency = true #强制GTID的一致性 log-slave-updates = 1 #slave更新是否记入日志 autocommit = 1 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES character_set_server=utf8 [client] socket = /application/mysql/tmp/mysql.sock
从：
[mysqld] log_bin = /tmp/log-bin binlog-format=ROW basedir = /application/mysql/ datadir = /application/mysql/data/ server_id = 2 socket = /application/mysql/tmp/mysql.sock gtid-mode = on enforce-gtid-consistency = true log_slave_updates = 1 sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES character_set_server=utf8 autocommit = 1 [client] socket = /application/mysql/tmp/mysql.sock
注意：若是是新建的数据库能够不须要从库初始化；若是不是须要从库初始化，同步主从的结构属性
二、在主服务器添加复制用户
grant replication slave on *.* to repl@'10.0.0.%' identified by '123';
三、在从服务器上设置change master
mysql> change master to master_host='10.0.0.51', master_port=3306, master_user='repl', master_password='123', master_auto_position=1;
四、开启slave
start slave;
五、查看效果
在主库中添加一个数据，查看master
mysql> show master status; +----------------+----------+--------------+------------------+------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +----------------+----------+--------------+------------------+------------------------------------------+ | log-bin.000003 | 552 | | | ff185ff4-cec5-11e7-9c86-000c2924dc94:1-2 | +----------------+----------+--------------+------------------+------------------------------------------+ 1 row in set (0.00 sec)
再从库中查看slave：
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.0.0.51
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: log-bin.000003
Read_Master_Log_Pos: 552
Relay_Log_File: db02-relay-bin.000004
Relay_Log_Pos: 442
Relay_Master_Log_File: log-bin.000003
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: 552
Relay_Log_Space: 1252
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: 1
Master_UUID: ff185ff4-cec5-11e7-9c86-000c2924dc94
Master_Info_File: /application/mysql-5.6.38/data/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: ff185ff4-cec5-11e7-9c86-000c2924dc94:1-2
Executed_Gtid_Set: ff185ff4-cec5-11e7-9c86-000c2924dc94:1-2
Auto_Position: 1
1 row in set (0.00 sec)
相关文章
- 1. MySQL 主从复制，mysql主从复制
- 2. MySQL主从复制与主主复制
- 3. 【mysql】-- 主从复制与主主复制
- 4. MySQL 主从复制 主主复制(3)
- 5. Mysql主从复制
- 6. mysql 主从复制。
- 7. mysql主从复制
- 8. MySql-主从复制
- 9. MYSQL主从复制
- 10. mysql-主从复制
- 更多相关文章...
- • Redis主从复制的配置方法和执行过程 - Redis教程
- • MySQL主键（PRIMARY KEY） - MySQL教程
- • 漫谈MySQL的锁机制
- • Docker容器实战(六) - 容器的隔离与限制
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. No provider available from registry 127.0.0.1:2181 for service com.ddbuy.ser 解决方法
- 2. Qt5.7以上调用虚拟键盘(支持中文)，以及源码修改(可拖动，水平缩放)
- 3. 软件测试面试- 购物车功能测试用例设计
- 4. ElasticSearch（概念篇）：你知道的, 为了搜索…
- 5. redux理解
- 6. gitee创建第一个项目
- 7. 支持向量机之硬间隔（一步步推导，通俗易懂）
- 8. Mysql 异步复制延迟的原因及解决方案
- 9. 如何在运行SEPM配置向导时将不可认的复杂数据库密码改为简单密码
- 10. windows系统下tftp服务器使用
欢迎关注本站公众号,获取更多信息
相关文章
- 1. MySQL 主从复制，mysql主从复制
- 2. MySQL主从复制与主主复制
- 3. 【mysql】-- 主从复制与主主复制
- 4. MySQL 主从复制 主主复制(3)
- 5. Mysql主从复制
- 6. mysql 主从复制。
- 7. mysql主从复制
- 8. MySql-主从复制
- 9. MYSQL主从复制
- 10. mysql-主从复制