mysql数据库备份，主从复制及半同步复制

1、使用mysqldump备份数据库并通过备份及二进制日志还原数据(备份完后再写入数据,然后再删库)

mysqldump -A --single-transaction -F --master-data=2 > /data/backup/mysql.sql

-A备份所有数据库，--single-stransaction开启事务备份 -F 刷新日志 --master-data=2记录二进制日志位置

备份前数据库

在表里插入新记录，不在完全备份当中

删库

mysql -e ‘drop database hellodb‘

还原前临时禁用二进制日志。避免记录还原过程

source /data/backup/mysql.sql

还原成功

在完全备份之后的记录还没还原。

查看/backup/mysql.sql文件的二进制日志的记录点

发现从日志编号06，位置245为。之后的是没有备份的，

用mysqlbinlog导出二进制日志

mysqlbinlog /var/lib/mysql/centos7-bin.000006 -v > /data/backup/log.sql

把日志文件中的drop database hellodb 删除

然后在数据库中导入生成的二进制日志。

还原成功


2、使用xtrabackup备份数据并还原

yum install percona-xtrabackup (epel)源

mkdir /data/backups 创建一个临时目录存放xtrabackup的备份文件

xtrabackup --backup --target-dir=/data/backups/ 在要备份的机器上执行备份命令。将预准备文件存放在一个临时目录

临时生成的文件

(1)xtrabackup_info：innobackupex工具执行时的相关信息，包括版本，备份选项，备份时长，备份LSN(log sequence number日志序列号)，BINLOG的位置?(2)xtrabackup_checkpoints：备份类型（如完全或增量）、备份状态（如是否已经为prepared状态）和LSN范围信息,每个InnoDB页(通常为16k大小)都会包含一个日志序列号LSN。LSN是整个数据库系统的系统版本号，每个页面相关的LSN能够表明此页面最近是如何发生改变的?(3)xtrabackup_binlog_info：MySQL服务器当前正在使用的二进制日志文件及至备份这一刻为止二进制日志事件的位置，可利用实现基于binlog的恢复?(4)backup-my.cnf：备份命令用到的配置选项信息?(5)xtrabackup_logfile：备份生成的日志文件

scp -r /data/backups/ 192.168.242.129:/data/ 将备份文件拷贝到目标机器

还原注意事项：

1.datadir 目录必须为空。除非指定innobackupex --force-non-empty-directorires选项指定，否则--copy-backup选项不会覆盖

2.在restore之前,必须shutdown MySQL实例，不能将一个运行中的实例restore到datadir目录中

3.由于文件属性会被保留，大部分情况下需要在启动实例之前将文件的属主改为mysql，这些文件将属于创建备份的用户

chown -R mysql:mysql /data/mysql

以上需要在用户调用innobackupex之前完成

在目标主机执行xtrabackup --prpare --target-dir=/data/backups （预准备工作)

生成了数据库文件

xtrabackup --copy-back --target-dir=/backups/ 将目录中的文件拷贝到数据库/var/lib/mysql中

修改文件属性为mysql

开始将目录中的所有的数控文件拷贝到系统的数据目录中

因为是从另一台机器拷贝过来的数据，需要修改文件属性

还原成功

3、MySQL数据备份企业实战(shell或python脚本实现)

使用xtrabackup以每周为一个备份周期做备份(数据库+二进制日志,备份至本地/data/backup)

提示: 周一某个时间点做一次完全备份,周二、三、四、五、六、日增量

备份存储目录"/data/backup/2018/52/1/备份数据" 目录解释"/data/backup/年/本年度的第几周/本周的第几天/数据" 一年52周一周7天

(Andy老师提供python备份脚本参考)

#!/bin/bash

for i in `seq 0 6`;do #循环6次

a=/data/backup/`date +%Y`/`date +%U`/ #存储目录变量

mkdir -p $a$i # #创建目录

t=`date +%w` #定义星期

if [ "$t" == "1" ];then #匹配星期 周一为完全备份

xtrabackup --backup --target-dir=/data/backup &> /dev/null &&  echo backup ok

else

if [ "$t" == "2" ];then  #匹配星期 周二为增量备份

xtrabackup --backup --target-dir="$a"1 --incremental-basedir=/data/backup &> /dev/null &&  echo backup ok

elif [ "$t" == "3" ];then

xtrabackup --backup --target-dir="$a"2 --incremental-basedir="$a"1 &> /dev/null &&  echo backup ok

elif [ "$t" == "4" ];then

xtrabackup --backup --target-dir="$a"3 --incremental-basedir="$a"2 &> /dev/null &&  echo backup ok

elif [ "$t" == "5" ];then

xtrabackup --backup --target-dir="$a"4 --incremental-basedir="$a"3 &> /dev/null &&  echo backup ok

elif [ "$t" == "6" ];then

xtrabackup --backup --target-dir="$a"5 --incremental-basedir="$a"4 &> /dev/null &&  echo backup ok

elif [ "$t" == "0" ];then

xtrabackup --backup --target-dir="$a"6 --incremental-basedir="$a"5 &> /dev/null &&  echo backup ok

fi

fi

done

[[email protected] ~]# crontab -l

0 2 * * * root /root/b.sh

写入计划任务。每晚执行一遍备份。周一则完全备份

4、描述MySQL复制工作原理并实现主从,主主,主从级联及半同步复制

一台mysql数据库的并发连接数是有限的，当访问量大的时候，可能一台服务器压力太大。如果数据库压力过大宕机了。则会有数据丢失的风险和用户体验过差，所以，我们可以利用mysql的复制。一台主机，多台备用机，当一台主数据库写入数据，则将二进制日志复制到其他从服务器上，实现同步过程，如果主服务器宕机，则自动从多台从服务器挑选一台充当主服务器，避免宕机时间过长

复制原理

当主服务器收到数据更新请求，会写入二进制日志中。在本机中，有一个专门的dump的主服务器线程将二进制日志出来往从服务器线程发。然后发给从服务器。从服务器有一个io thread线程然后写到relay log （类似二进制日志）日志中 。在交给sql thread 在从服务器中更改数据


主从

在主服务器配置文件

log-bin=/data/logbin/mysql-bin #启用二进制日志

server-id=1 #指定服务器编号

在从服务器配置

server-id=2 #区别于主服务器编号

read_only=on #为了安全从服务器设置为只读，防止修改

在主服务器创建并授权复制账号

grant replication slave on *.* to [email protected]‘192.168.64.%‘ identified by ‘centos‘;

主服务器数据库

从服务器数据库

在从服务器执行主服务器修改master 信息

CHANGE MASTER TO

MASTER_HOST=‘192.168.64.128‘,#主服务ip

MASTER_USER=‘test‘,#用那个账号复制

MASTER_PASSWORD=‘centos‘,#账户口令

MASTER_PORT=3306,#端口

MASTER_LOG_FILE=‘mysql-bin.000003‘,#从那个二进制日志开始复制

MASTER_LOG_POS=245;#从二进制日志的开始内容复制

查看从节点信息

start slave;从服务器执行复制之后就不需要在执行

复制成功


级联复制：主复制复制给 从服务器。在从从服务器复制给其他从服务器

主服务器配置文件不变

创建并授权复制账号

grant replication slave on *.* to [email protected]‘192.168.64.%‘ identified by ‘centos‘;

在中间节点上修改配置文件

加入log_slave_updates将主节点二进制日志记录到自己的日志中

并开启二进制日志，需要将日志复制给下一个节点

修改master to 信息

CHANGE MASTER TO

MASTER_HOST=‘192.168.64.128‘,

MASTER_USER=‘test‘,

MASTER_PASSWORD=‘centos‘,

MASTER_PORT=3306,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=245;

start slave； 开启复制

主服务器导入表

中间节点开始导入数据

在最后一个节点修改配置文件，关闭二进制日志，从中间节点复制过来二进制日志

启动数据库，修改master信息为中间节点

CHANGE MASTER TO

MASTER_HOST=‘192.168.64.130‘,

MASTER_USER=‘test‘,

MASTER_PASSWORD=‘centos‘,

MASTER_PORT=3306,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=245;

同步成功


主主复制：互为主从

容易产生的问题：数据不一致；因此慎用

考虑要点：自动增长id

配置一个节点使用奇数id

auto_increment_offset=1 开始点

auto_increment_increment=2 增长幅度

另一个节点使用偶数id

auto_increment_offset=2

auto_increment_increment=2

修改主配置文件

修改另一台主配置文件

创建账号

grant replication slave on *.* to [email protected]‘192.168.64.%‘ identified by ‘centos‘;

在第二台主机修改master 信息

CHANGE MASTER TO

MASTER_HOST=‘192.168.64.128‘,

MASTER_USER=‘test‘,

MASTER_PASSWORD=‘centos‘,

MASTER_PORT=3306,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=245;

在第一台主机配置

CHANGE MASTER TO

MASTER_HOST=‘192.168.64.130‘,

MASTER_USER=‘test‘,

MASTER_PASSWORD=‘centos‘,

MASTER_PORT=3306,

MASTER_LOG_FILE=‘mysql-bin.000001‘,

MASTER_LOG_POS=245;

启动复制 start slave;


半同步复制

默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能，主

库把binlog日志发送给从库即结束，并不验证从库是否接收完毕。这意味着当

主服务器或从服务器端发生故障时，有可能从服务器没有接收到主服务器发送

过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢

复时造成数据的丢失

在主服务器安装一个半同步插件模块semisync_master.so‘;

先实现标准的主从复制

在主服务器安装插件/usr/lib64/mysql/plugin/semisync_master.so

INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;

在配置文件加入配置

在从节点安装插件semisync_slave.so

INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;

并写入配置文件

查看插件状态是否启动

SHOW GLOBAL VARIABLES LIKE ‘%semi%‘;

SHOW GLOBAL STATUS LIKE ‘%semi%‘;

重新启动线程 stop slave； start slave；实现半同步复制


5、描述MySQL Proxy原理并实现读写分离

MySQL Proxy处于客户端应用程序和MySQL服务器之间，通过截断、改变并转发客户端和后端数据库之间的通信来实现其功能，这和WinGate 之类的网络代理服务器的基本思想是一样的。代理服务器是和TCP/IP协议打交道，而要理解MySQL Proxy的工作机制，同样要清楚MySQL客户端和服务器之间的通信协议，MySQL Protocol 包括认证和查询两个基本过程：

认证过程包括：

客户端向服务器发起连接请求

服务器向客户端发送握手信息

客户端向服务器发送认证请求

服务器向客户端发送认证结果

如果认证通过，则进入查询过程：

客户端向服务器发起查询请求

服务器向客户端返回查询结果

当然，这只是一个粗略的描述，每个过程中发送的包都是有固定格式的，想详细了解MySQL Protocol的同学，可以去这里 看看。MySQL Proxy要做的，就是介入协议的各个过程。首先MySQL Proxy以服务器的身份接受客户端请求，根据配置对这些请求进行分析处理，然后以客户端的身份转发给相应的后端数据库服务器，再接受服务器的信息，返回给客户端。所以MySQL Proxy需要同时实现客户端和服务器的协议。由于要对客户端发送过来的SQL语句进行分析，还需要包含一个SQL解析器。可以说MySQL Proxy相当于一个轻量级的MySQL了，实际上，MySQL Proxy的admin server是可以接受SQL来查询状态信息的

在调度器安装proxysql 调度器

配置一下yum源

cat <<EOF | tee /etc/yum.repos.d/proxysql.repo

[proxysql_repo]

name= ProxySQL YUM repository

baseurl=http://repo.proxysql.com/ProxySQL/proxysql-1.4.x/centos/\$releasever

gpgcheck=1

gpgkey=http://repo.proxysql.com/ProxySQL/repo_pub_key

EOF

yum install proxysql 安装调度器

调度器配置为数据库方式，所以要启动数据库

启动服务

准备：实现读写分离前，先实现主从复制

注意：slave节点需要设置read_only=1

?启动ProxySQL：service proxysql start

启动后会监听两个默认端口

6032：ProxySQL的管理端口

6033：ProxySQL对外提供服务的端口

?使用mysql客户端连接到ProxySQL的管理接口6032，默认管理员用户和密码都

是admin：

mysql -uadmin -padmin -P6032 -h127.0.0.1

在数据库中插入数据库服务器的地址和编号，这里编号统一为10，后面会自己识别主从服务器

根据数据库的配置文件read-only这项来区分

MySQL > load mysql servers to runtim

MySQL > save mysql servers to disk;

加载配置并存盘

在主数据库创建账号让proxysql 监控并自动调整读组和写组

grant replication client on *.* to [email protected]‘192.168.64.%‘ identified by ‘centos‘;

在proxysql调度器加入监控账号和密码。并且加载生效

将都组和写组写入表中。test为描述可有可无

insert into mysql_replication_hostgroups values(10,20,"test");

分组成功，如果不成功，可手写如记录改变编号

创建测试账号在主服务器

grant all on *.* to [email protected]‘192.168.64.%‘ identified by ‘centos‘;

在proxysql服务器加入到mysq_user中

在ProxySQL配置，将用户sqluser添加到mysql_users表中， default_hostgroup默认

组设置为写组10，当读写分离的路由规则不符合时，会访问默认组的数据库

insert into mysql_users(username,password,default_hostgroup)values(‘sqluser‘,‘centos‘,10);

保存并生效

load mysql users to runtim；

save mysql users to disk;

在proxysql调度器上用sqluser账户连接，利用6033端口。

默认sqluser在10这个主机组。也就是mysql的主数据库 默认所有操作都在主数据库上操作。

配置路由规则。实现读写分离

与规则有关的表：mysql_query_rules和mysql_query_rules_fast_routing，

插入路由规则：将select语句分离到20的读组，select语句中有一个特殊语句

SELECT...FOR UPDATE它会申请写锁，应路由到10的写组

insert into mysql_query_rules

(rule_id,active,match_digest,destination_hostgroup,apply)VALUES

(1,1,‘^SELECT.*FOR UPDATE$‘,10,1),(2,1,‘^SELECT‘,20,1);

##除了读操作发往从节点，其他操作都发往主节点

到此，读写分离配置完成

验证。读为从服务器

mysql -usqluser -pcentos -P6033 -h127.0.0.1 -e ‘select @@server_id‘

利用事物查看，为主服务器

6、使用MHA及galera实现MySQL的高可用性

MHA工作原理

?1 从宕机崩溃的master保存二进制日志事件（binlog events）

?2 识别含有最新更新的slave

?3 应用差异的中继日志（relay log）到其他的slave

?4 应用从master保存的二进制日志事件（binlog events）

?5 提升一个slave为新的master

?6 使其他的slave连接新的master进行复制

mha实验前

skip-name-resolv建议在所有主从节点加上这项，跳过名字解析，避免mha实验出现解析问题

MHA软件由两部分组成，Manager（管理节点）工具包和Node（被管理节点）工具包

https://code.google.com/archive/p/mysql-master-ha/ 可在官网下载

搭建步骤：

在主数据库节点创建一个管理账号

grant all on *.* to [email protected]‘192.168.64.%’identified by‘centos‘;

在从节点数据库中加入

vim /etc/my.cnf

[mysqld]

server_id=2 #不同节点此值各不相同

log-bin #启用二进制，实现高可用

read_only #因为上面建立的账号可自动关闭这个选项，也可以不加入配置文件

relay_log_purge=0 #中继日志，如果主服务宕机数据没拷贝过去从的话需要启用中继

skip_name_resolve=1 #跳过名字解析

然后在所有机器实现sshkey验证，如果主节点出现问题，可用ssh协议将主服务器的配置文件拷出来

生成密钥

ssh-copy-id 192.168.64.133 到自己的机器上，在将生成的文件拷贝到其他机器上实现key验证

在管理节点上安装两个包：

mha4mysql-manager

mha4mysql-node

在被管理节点安装：

mha4mysql-node

在管理节点建立配置文件写入被管理节点的信息

vim /etc/mastermha/app1.cnf

[server default]

user=mhauser #主节点授权的账号

password=centos #密码

manager_workdir=/data/mastermha/app1/ #管理目录

manager_log=/data/mastermha/app1/manager.log#日志

remote_workdir=/data/mastermha/app1/ #在远程节点创建的目录

ssh_user=root #利用ssh账号远处管理节点

repl_user=repluser

repl_password=centos

ping_interval=1

[server1] #需要监控的节点信息

hostname=192.168.64.130

candidate_master=1 #表示这两台服务器有能力当主节点

[server2]

hostname=192.168.64.131

candidate_master=1

[server3]

hostname=192.168.64.132

Mha验证和启动

masterha_check_ssh --conf=/etc/mastermha/app1.cnf #测试ssh协议是否联通

调用我们上面写的配置文件

masterha_check_repl --conf=/etc/mastermha/app1.cnf

masterha_manager --conf=/etc/mastermha/app1.cnf

配置完成


galera cluster实现高可用性

Galera Cluster：集成了Galera插件的MySQL集群，是一种新型的，数据

不共享的，高度冗余的高可用方案，目前Galera Cluster有两个版本，分

别是Percona Xtradb Cluster及MariaDB Cluster，Galera本身是具有多

主特性的，即采用multi-master的集群架构，是一个既稳健，又在数据一

致性、完整性及高性能方面有出色表现的高可用解决方案

Galera Cluster特点

多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的

?同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据

不会丢失

?并发复制：从节点APPLY数据时，支持并行执行，更好的性能

?故障切换：在出现数据库故障时，因支持多点写入，切换容易

?热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务

时间就会非常少。在节点故障期间，节点本身对集群的影响非常小

?自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要

人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为

一致

?对应用透明：集群的维护，对应用程序是透明的

gelare需要安装专门的数据库 且不能装mariadb数据库

配置yum源，下载MariaDB-Galera-server

vim /etc/yum.repos.d/base.repo

[base]

baseurl=https://mirrors.tuna.tsinghua.edu.cn/mariadb/mariadb-5.5.64/yum/centos7-amd64/

gpgcheck=0

复制到其他主机上。最少三台

修改配置文件

vim /etc/my.cnf.d/server.cnf

[galera]

wsrep_provider = /usr/lib64/galera/libgalera_smm.so #提供的库文件路劲

wsrep_cluster_address="gcomm://192.168.64.128,192.168.64.130.,192.168.64.131"#集群服务器的节点分别是谁

binlog_format=row #二进制日志为行显示

default_storage_engine=InnoDB #默认存储引擎

innodb_autoinc_lock_mode=2 #加锁的模式

bind-address=0.0.0.0

首次启动时，需要初始化集群，在其中一个节点上执行命令

/etc/init.d/mysql start --wsrep-new-cluster

而后正常启动其它节点

service mysql start

配置完成。

原文地址：https://www.cnblogs.com/woaiyitiaochai/p/11757949.html

时间： 2024-10-08 05:42:20

mysql数据库备份，主从复制及半同步复制的相关文章

第四阶段 （七）MySQL REPLICATION（主从复制、半同步复制、复制过滤）

Linux运维 第四阶段 (七)MySQL REPLICATION(主从复制.半同步复制.复制过滤) 一.MySQL Replication相关概念: 1.复制的作用:辅助实现备份:高可用HA:异地容灾:分摊负载(scaleout):rw-spliting(mysql proxy工作在应用层). 2.master有多个CPU允许事务并行执行,但往二进制日志文件只能一条条写:slave比master要慢:master-slave默认异步方式传送. 3.半同步:仅负责最近一台slave同步成功,其它

MySQL数据的主从复制、半同步复制和主主复制详解

一.MySQL复制概述 ⑴.MySQL数据的复制的基本介绍 目前MySQL数据库已经占去数据库市场上很大的份额,其一是由于MySQL数据的开源性和高性能,当然还有重要的一条就是免费~不过不知道还能免费多久,不容乐观的未来,但是我们还是要能熟练掌握MySQL数据的架构和安全备份等功能,毕竟现在它还算是开源界的老大吧! MySQL数据库支持同步复制.单向.异步复制,在复制的过程中一个服务器充当主服务,而一个或多个服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环

Mariadb主从复制，半同步复制，主主复制

文章内容概览 主从复制介绍 主从复制的作用 复制工作流程 复制时应该注意的问题 主从复制配置 半同步复制配置 复制过滤器方法说明和配置 双主(主主复制)配置 文章环境说明 操作系统: [[email protected] ~]# cat/etc/redhat-release CentOS release 6.6 (Final) [[email protected] ~]# uname -r 2.6.32-504.el6.x86_64 [[email protected] ~]# uname -m

mysql主从复制、半同步复制、主主复制、及从库升级为主库讲解

一.主从复制结构 binlog dump --- io thread  ---  relay log ---- sql thread 1.总体讲解 主从复制时是异步的 半同步是在主从架构下安装插件来达到半同步的 半同步的优点:保证至少一个节点的数据和主节点的数据一致,缺点影响性能 导致主从不同步的原因是 现在的服务器都是单核多线程或者多核多线程,导致主节点可以同时执行多条读写操作,而记录二进制日志则必须按顺序有先后的记录,从节点在一条一条复制过去,生成中继日志,再执行语句. 多个库复制的话,可以

MySQL基于SSL的主从复制、半同步复制

(一)主从复制的架构图 1.在主数据库上,每执行一个有可能引起数据库发生改变的的语句,都会记录到二进制日志文件中,并把它们保存为事件. 2.每保存一个事件,我们就通过mysql的服务器3306端口发送给另外一台服务器 3.另外一台服务器把这个事件接收下来,接收的时候先保存到本地的中继日志里面 4.然后,mysql从中继日志文件里读一个事件,然后保存到数据文件 (二)一主多从 半同步架构图 1.Master和Slave-1在同一个机房 2.Slave-2和Slave-3在其它机房 3.半同步指的是

Mysql 主从复制之半同步复制(基于gtid)

Mysql主从复制mysql主从复制原理:从库有两个线程IO线程和SQL线程1.从库的IO线程向主库的主进程发送请求,主库验证从库,交给主库IO线程负责数据传输;2.主库IO线程对比从库发送过来的master.info里的信息,将binlog文件信息,偏移量和binlog文件名等发送给从库3.从库接收到信息后,将binlog信息保存到relay-bin中,同时更新master.info的偏移量和binlog文件名4.从库的SQL线程不断的读取relay-bin的信息,同时将读到的偏移量和文件名写

MySQL主从复制、半同步复制和主主复制

同步,异步,半同步复制的比较: 同步复制:Master提交事务,直到事务在所有的Slave都已提交,此时才会返回客户端,事务执行完毕.缺点:完成一个事务可能会有很大的延迟. 异步复制:当Slave准备好才会向Master请求binlog.缺点:不能保证一些事件都能够被所有的Slave所接收. 半同步复制:半同步复制工作的机制处于同步和异步之间,Master的事务提交阻塞,只要一个Slave已收到该事务的事件且已记录.它不会等待所有的Slave都告知已收到,且它只是接收,并不用等其完全执行且提交.

【可靠性】Mysql 5.7 降低了半同步复制-数据丢失的风险

如果你的生产线开启了半同步复制,那么对数据的一致性会要求较高,但在MySQL5.5/5.6里,会存在数据不一致的风险.有这么一个场景,客户端提交了一个事务,master把binlog发送给slave,在发送的期间,网络出现波动,此时Binlog Dump线程发送就会卡住,要等待slave把binlog写到本地的relay-log里,然后给master一个反馈,等待的时间以rpl_semi_sync_master_timeout参数为准,默认为10秒.在这等待的10秒钟里,在其他会话里,查看刚才的

MySQL压测--异步与半同步复制

最近在看MySQL5.7 Manual,有关Semisynchronous Replication这一块的内容,我们知道,MySQL默认的Replication是异步的,何为异步?何为半同步?废话不多说,直接看官方解释吧: 1.背景知识 Asynchronous replication the master writes events to its binary log and slaves request them when they are ready. There is no guaran