mysqldump添加从库或者重新同步从库

2024-01-24 19:28

本文主要是介绍mysqldump添加从库或者重新同步从库,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、GTID添加从库的方法

1.如果master所有的binlog还在,安装slave后,直接change master 到master
原理是直接获取master所有的gtid并执行
优点是简单
缺点是如果binlog太多,数据完全同步需要的时间较长,并且需要master一开始就启用了GTID
总结:适用于master也是新建不久的情况2.通过master或者其它slave的mysqldump备份搭建新的slave.
原理:备份时获取master的数据和这些数据对应的GTID,在Slave端跳过备份包含的GTID
优点是可以避免第一种方法中的不足
缺点操作相对复杂
总结:适用于拥有较大数据集的情况3、percona xtrabackup
基于xtrabackup备份文件xtrabackup_binlog_info包含了GTID信息
做从库恢复后,需要手工设置:
set@@GLOBAL.GTID_PURGED='c8d960f1-83ca-11e5-a8eb-000c29ea831c:1-745497';
恢复后,执行change master to
缺点操作相对复杂
总结:适用于拥有较大数据集的情况

二、演示从库搭建

1、演示环境
mysql> system cat /etc/redhat-release
CentOS release 6.7 (Final)
mysql> show variables like 'version';
+---------------+------------+
| Variable_name | Value      |
+---------------+------------+
| version       | 5.7.12-log |
+---------------+------------+主服务器:192.168.1.245:3306  server_id : 245
从服务器:192.168.1.247:3306  server_id : 247--在主库端创建复制用户
mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'repl'@'%' IDENTIFIED BY '123456'; 2、直接使用change master(针对本文第一部分,第1小点情形)此处省略基于gtid配置的参数描述,具体可以参考:配置MySQL GTID 主从复制
在从服务器端直接change master,如下:SLAVE> show variables like 'server_id';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| server_id     | 247   |
+---------------+-------+Slave> CHANGE MASTER TO  -> MASTER_HOST='192.168.1.245',    -> MASTER_USER='repl',    -> MASTER_PASSWORD='123456',    -> MASTER_PORT=3306,    -> MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.12 sec)Slave> start slave;
Query OK, 0 rows affected (0.01 sec)Slave> start slave;
Query OK, 0 rows affected (0.01 sec)Slave> show slave status \G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.1.245Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: node3-binlog.000001Read_Master_Log_Pos: 457Relay_Log_File: node5-relay-bin.000002Relay_Log_Pos: 676Relay_Master_Log_File: node3-binlog.000001Slave_IO_Running: YesSlave_SQL_Running: Yes...............--主服务器端操作如下
Master> create database tempdb;
Query OK, 1 row affected (0.02 sec)Master> use tempdb
Database changed
Master> create table t1(id int,ename varchar(20));
Query OK, 0 rows affected (0.09 sec)Master> insert into t1 values(1,'leshami');
Query OK, 1 row affected (0.08 sec)--从服务器端验证
Slave> select * from tempdb.t1;
+------+---------+
| id   | ename   |
+------+---------+
|    1 | leshami |
+------+---------+
1 row in set (0.01 sec)-------+

三,基于mysqldump搭建gtid从库,master未停止写入部署

3、基于mysqldump搭建gtid从库 
--准备环境,从库端执行
Slave> stop slave;          --停止重库
Query OK, 0 rows affected (0.01 sec)Slave> reset slave all;     --重置主从配置信息
Query OK, 0 rows affected (0.02 sec)   --准备环境,主库端执行  
Master> source sakila-db/sakila-schema.sql  --导入mysql自带的sakila数据库
Master> source sakila-db/sakila-data.sql    --填充数据   --使用mysqldump导出数据库  
# mysqldump --all-databases --single-transaction --triggers --routines --events \
> --host=localhost --port=3306 --user=root --password=MyP@ssw0rd  --max-allowed-packet=512M >/tmp/alldb.sql        --导出的文件中已经包含了GTID_PURGED的信息,说明备份文件是执行了gtid的位置。
# grep GTID_PURGED /tmp/alldb.sql   
SET @@GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38';--将备份文件copy到从服务器
# scp /tmp/alldb.sql 192.168.1.247:/tmp-- 执行reset master,重置从服务器上的binlog
Slave> reset master;
Query OK, 0 rows affected (0.03 sec)Slave> source /tmp/alldb.sqlSlave> show databases;    --此时tempdb已产生
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sakila             |
| sys                |
| tempdb             |
+--------------------+--执行change master
Slave> CHANGE MASTER TO  -> MASTER_HOST='192.168.1.245',    -> MASTER_USER='repl',    -> MASTER_PASSWORD='123456',    -> MASTER_PORT=3306,    -> MASTER_AUTO_POSITION = 1;
Query OK, 0 rows affected, 2 warnings (0.06 sec)重点说明:如果master一直还在写入,这里MASTER_AUTO_POSITION就不能写1,就要写GTID_PURGED这个执行过的开始,上面GLOBAL.GTID_PURGED='78336cdc-8cfb-11e6-ba9f-000c29328504:1-38',那么master一直有更新操作,这个时候MASTER_AUTO_POSITION就要写执行过的gtid的下一个位置,那就是39,由于master如果uuid是唯一的,MASTER_AUTO_POSITION = 39,如果你写1,那就会出现从库提升gtid已经执行过了。Slave> start slave;
Query OK, 0 rows affected (0.00 sec)Slave> show slave status \G
*************************** 1. row ***************************Slave_IO_State: Waiting for master to send eventMaster_Host: 192.168.1.245Master_User: replMaster_Port: 3306Connect_Retry: 60Master_Log_File: node3-binlog.000001Read_Master_Log_Pos: 25637Relay_Log_File: node5-relay-bin.000002Relay_Log_Pos: 423Relay_Master_Log_File: node3-binlog.000001Slave_IO_Running: YesSlave_SQL_Running: Yes--主库端执行一些事务
Master> alter table tempdb.t1 modify ename varchar(50);
Query OK, 0 rows affected (0.05 sec)
Records: 0  Duplicates: 0  Warnings: 0Master> insert into tempdb.t1 values(2,'http://blog.csdn.net/leshami');
Query OK, 1 row affected (0.02 sec)--从库端验证结果
Slave> desc tempdb.t1;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | YES  |     | NULL    |       |
| ename | varchar(50) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)Slave> select * from tempdb.t1;
+------+------------------------------+
| id   | ename                        |
+------+------------------------------+
|    1 | leshami                      |
|    2 | http://blog.csdn.net/leshami |
+------+-----------------------

简单的几个步骤:

1.主库备份

# mysqldump -uadmin  -p"hechunyang" -S /tmp/mysql_db01.sock -A  -R -E --triggers  --single-transaction --max-allowed-packet=512M > full.sql

2.备份文件执行的gtid位置

[root@VM-73-254-tencentos ~]# grep GTID_P full.sql 
SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '560d72ff-b057-11ee-84ba-5254005c1b84:1-5';

3.拷贝文件full.sql到从库

4.主库执行ddl操作,同时主库执行gtid的位置要比备份gtid位置要大

5.备库导入备份文件

mysql> stop slave;

mysql> reset slave all;

mysql> reset master;

mysql> source /root/full.sql

6,配置gtid主从同步,在从库执行,这里MASTER_AUTO_POSITION = 6,这里要解析一下,为什么是6,而不是1,因为备份文件我并没有过滤掉gtid,所以备份文件导入从库,会执行gtid,也就是上面的备份文件查看到2步骤:SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '560d72ff-b057-11ee-84ba-5254005c1b84:1-5'; 说明导入备份文件,gtid就执行到了5这个位置,那么下一步同步主库的gtid位置就应该是6,因此这里要写6,而不是1,因为1,已经从库执行过了,

mysql> CHANGE MASTER TO MASTER_HOST='9.134.73.254',MASTER_USER='repl',MASTER_PASSWORD='sysrepl',MASTER_PORT=3306,MASTER_AUTO_POSITION = 6;   

mysql> start slave;

mysql> show slave status\G;

查看结果,发现接收gtid是从6开始,执行了的gtid,可以对比跟主库。

Retrieved_Gtid_Set: 560d72ff-b057-11ee-84ba-5254005c1b84:6-8
Executed_Gtid_Set: 560d72ff-b057-11ee-84ba-5254005c1b84:1-8

7.测试一下。是否主从同步

主库执行

查看从库

结果可以正常同步

这篇关于mysqldump添加从库或者重新同步从库的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/640747

相关文章

MySQL的JDBC编程详解

《MySQL的JDBC编程详解》:本文主要介绍MySQL的JDBC编程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录前言一、前置知识1. 引入依赖2. 认识 url二、JDBC 操作流程1. JDBC 的写操作2. JDBC 的读操作总结前言本文介绍了mysq

java.sql.SQLTransientConnectionException连接超时异常原因及解决方案

《java.sql.SQLTransientConnectionException连接超时异常原因及解决方案》:本文主要介绍java.sql.SQLTransientConnectionExcep... 目录一、引言二、异常信息分析三、可能的原因3.1 连接池配置不合理3.2 数据库负载过高3.3 连接泄漏

Linux下MySQL数据库定时备份脚本与Crontab配置教学

《Linux下MySQL数据库定时备份脚本与Crontab配置教学》在生产环境中,数据库是核心资产之一,定期备份数据库可以有效防止意外数据丢失,本文将分享一份MySQL定时备份脚本,并讲解如何通过cr... 目录备份脚本详解脚本功能说明授权与可执行权限使用 Crontab 定时执行编辑 Crontab添加定

MySQL中On duplicate key update的实现示例

《MySQL中Onduplicatekeyupdate的实现示例》ONDUPLICATEKEYUPDATE是一种MySQL的语法,它在插入新数据时,如果遇到唯一键冲突,则会执行更新操作,而不是抛... 目录1/ ON DUPLICATE KEY UPDATE的简介2/ ON DUPLICATE KEY UP

MySQL分库分表的实践示例

《MySQL分库分表的实践示例》MySQL分库分表适用于数据量大或并发压力高的场景,核心技术包括水平/垂直分片和分库,需应对分布式事务、跨库查询等挑战,通过中间件和解决方案实现,最佳实践为合理策略、备... 目录一、分库分表的触发条件1.1 数据量阈值1.2 并发压力二、分库分表的核心技术模块2.1 水平分

Python与MySQL实现数据库实时同步的详细步骤

《Python与MySQL实现数据库实时同步的详细步骤》在日常开发中,数据同步是一项常见的需求,本篇文章将使用Python和MySQL来实现数据库实时同步,我们将围绕数据变更捕获、数据处理和数据写入这... 目录前言摘要概述:数据同步方案1. 基本思路2. mysql Binlog 简介实现步骤与代码示例1

使用shardingsphere实现mysql数据库分片方式

《使用shardingsphere实现mysql数据库分片方式》本文介绍如何使用ShardingSphere-JDBC在SpringBoot中实现MySQL水平分库,涵盖分片策略、路由算法及零侵入配置... 目录一、ShardingSphere 简介1.1 对比1.2 核心概念1.3 Sharding-Sp

MySQL 表空却 ibd 文件过大的问题及解决方法

《MySQL表空却ibd文件过大的问题及解决方法》本文给大家介绍MySQL表空却ibd文件过大的问题及解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考... 目录一、问题背景:表空却 “吃满” 磁盘的怪事二、问题复现:一步步编程还原异常场景1. 准备测试源表与数据

Mac电脑如何通过 IntelliJ IDEA 远程连接 MySQL

《Mac电脑如何通过IntelliJIDEA远程连接MySQL》本文详解Mac通过IntelliJIDEA远程连接MySQL的步骤,本文通过图文并茂的形式给大家介绍的非常详细,感兴趣的朋友跟... 目录MAC电脑通过 IntelliJ IDEA 远程连接 mysql 的详细教程一、前缀条件确认二、打开 ID

MySQL的配置文件详解及实例代码

《MySQL的配置文件详解及实例代码》MySQL的配置文件是服务器运行的重要组成部分,用于设置服务器操作的各种参数,下面:本文主要介绍MySQL配置文件的相关资料,文中通过代码介绍的非常详细,需要... 目录前言一、配置文件结构1.[mysqld]2.[client]3.[mysql]4.[mysqldum