基于docker容器的mysql主从复制

目录

一. mysql主从复制参数

二. 冷备份与恢复

一）、逻辑备份：

mysqldump在docker容器中的使用

mydumper在容器中的使用

​​​

三. 热备份与恢复 

---

一. mysql主从复制参数

log-bin:搭建主从复制，必须开启二进制日志。

server-id: MySQL在同一组主从结构中的唯-标识(主从服务器上该参数不能一致)。

server-uuid:从MySQL 5.6 开始有了这个参数，在数据库启动过程中自动生成，每台机器的server-uuid是不一样的。

uuid存放在数据目录的auto.cnf文件下。

read-only:设置从库为只读状态，避免在从库.上进行写操作。 注:对超管权限(super)账号没有效果。但MySQL5.7之后新增了一个super_ read_ _only 参数，开启该参数，连超管都没有权限进行写入操作。

binlog_ format: 二进制日志的格式，必须使用row模式。

log_slave_updates:作用是将从master服务器上获取数据变更的信息记录到从服务器的二进制日志文件中。

binlog_ error_ action: 该参数用来控制当不能写binlog文件时, MySQL server将会怎样。该参数是MySQL 5.7之后新增的，有ABORT_SERVER和IGNORE_ERROR两个值。

ABORT_ SERVER代表会使MySQL Server在写binlog遇到磁盘满或者文件系统不可写入时退出;而IGNORE ERROR则代表如果遇到binlog无法写入的情况，MySQL Server会在错误日志中记录错 误，并且还会强制关闭binlog 功能。这样就会影响从库获取主库上binlog的过程，从而导致主从数据不一致。MySQL 5.7.7 之后默认使用binlog_error_ action=ABORT_ SERVER。

binlog-do-db:使用该参数可选择性复制数据库(在主库上使用)，如binlog-do-db= zs,意味着除了zs库，其他库都不复制。但建议大家不要使用该参数，尽量保证复制的过滤规则不在主库上面 添加。

binlog-ignore-db:该参数就是忽略某个库的复制。如binlog-ignore-db=zs,意味着除了zs库，其他库都复制。

gtid_mode:决定gtid模式是否开启。使用gtid模式，设置gtid_ mode=on。

enforce-gtid-consistency:使用GTID复制模式时，要开启该参数，用来保证GTID的一致性。 设置enforce- gtid- consistency =on。

gtid_next: 该参数是session级别的变量，下一个 gtid。默认是AUTOMATIC。

gtid_purged:丢弃掉的GTID。

relay-log:记录从库的I/O thread从主库读取而来的binlog内容。

replicate_ do_table: 只复制指定的表，在从库上使用。

replicate-ignore-table: 不复制指定的表，在从库上使用。

replicate-do-db: 只复制指定的库，在从库上使用。

replicate-ignore-db: 不复制指定的库，在从库上使用。

replicate-wild-do-table:使用通配符复制指定的表，如复制zs表下tt开头的表， replicate_wild_ignore_table:使用通配符不复制指定的表。

master_info_repository: 把master.info (主从状态，配置信息)记录下来，默认记录到file里，建议使用表记录。

relay_log_info_repository sql thread: 应用二进制日志中的内容，并将binlog应用到的位置记录到relay.info，默认记录到file 里，建议使用表记录。

relay_log_recovery: 为了让从库是crash safe的，必须要设置relay_log_recovery=1。 该参数的含义是:当从库发生崩溃或者重启时，它会把那些未执行完的中继日志删除，并会向主库重新获取binlog，再次生成relaylog来完成中继日志的恢复。建议在从库上开启relay_ log_ _recovery参数，默认情况下是关闭的。

relay_log_purge:清除已经执行过的relay log。建议在从库开启该参数。

slave_net_timeout:该参数是设置在多少秒没收到主库传来的binlog之后，从库认为是网络超时，从库的I/O thread 会重新连接主库。该值从MySQL 5.7.7 开始的默认值为60s。

slave_ parallel_type:该参数是从MySQL5.7.2引入的，有两个值,一个是DATABASE,另一个是LOGICAL CLOCK。在MySQL 5.7中引入了基于组提交的并行复制。通过设置参数 slave_parallel_workers>0并且slave_parallel_type='LOGICAL_CLOCK'实现。

二. 冷备份与恢复

一）、逻辑备份：

数据库逻辑备份就是备份软件按照最初设计的逻辑关系，以数据库的逻辑结构对象为单位，将数据库中的数据按照预定义的逻辑关联格式一条一条生成相关的文本文件，以达到备份的目的。

在MySQL中常用的：

• mysqldump
• mydumper

mysqldump在docker容器中的使用

1、在主库中创建一个用户并授予全部权限，然后锁表操作。

create user 'admin'@'%' identified by '123456';
grant all on *.* to 'admin'@'%' with grant option;
flush tables with read lock;

2、然后在从服务器上进行数据的备份，通过mysqldump做主库的数据库备份备份数据

#1、使用以下命令备份导出数据库中的所有表结构和数据
docker exec -it  master mysqldump -uadmin -p123456 mysql_php > /mysql_php.sql

#2、只导数据不导结构
 mysqldump　-t　数据库名　-uroot　-p　>　xxx.sql　
docker exec -it master mysqldump -t -uadmin  -p123456 mysql_php > /mysql_php.sql

#3、只导结构不导数据
mysqldump　--opt　-d　数据库名　-u　root　-p　>　xxx.sql　
docker exec -it master mysqldump  --opt -d   -uadmin -p123456 mysql_php > /mysql_php.sql

#4、导出特定表的结构
mysqldump　-uroot　-p　-B　数据库名　--table　表名　>　xxx.sql

docker exec -it master mysqldump -uadmin -p -B mysql_php --table user > user.sql

3、 执行unlock tables 释放表锁

4、从数据的还原

mydumper在容器中的使用

mydumper是一个针对MySQL和drizzle的高性能多线程的备份和恢复工具。此工具的开发人员分别来自MySQL、facebook、skysql公司、目前已经有一些大型产 品业务测试并使用了该工具。我们在恢复 数据库时也可使用myloader工具。 Mydumper的主要特性包括：

· 采用轻量级C语言写的代码。 · 相比于mysqldump，其速度快了近10倍。

· 具有事务性和非事务性表一致的快照（适用于0.2.2+）。

· 可快速进行文件压缩（File compression on-the-fly）。

· 支持导出binlog。

· 可多线程恢复（适用于0.2.1+）。 · 可以用守护进程的工作方式，定时扫描和输出连续的二进制日志。

安装命令如下所示：

yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
rpm -qa | grep xtrabackup Xtrabackup

docker容器中命令
apt-get update
apt-get install mydumper
mydumper -V

备份命令：
mydumper -u root -p 123456 -B mysql_php -o /home/mysql_php

恢复命令：
myloader -u root -p 123456 -B mysql_php -d /home/mysql_php

Mydumper中的主要参数如下：
 

· -host，-h：连接的MySQL服务器。

· -user，-u：用户备份的连接用户。

· -password，-p：用户的密码。

· -port，-P：连接端口。

· -socket，-S：连接socket文 件。 

· -database，-B：需要备份的数据库。

· -table-list，-T：需要备份的表，用逗号（，）分隔。

· -outputdir，-o：输出的目录。 

· -build-empty-files，-e：默 认无数据则只有表结构文件。 

· -regex，-x：支持正则表达式，如mydumper-regex'（2l（mysqltest）'。

· -ignore-engines，-i：忽略的存储引擎。

· -no- schemas，-m：不导出表结构。

· -long-query-guard：长查询，默认60s。

· -kill-long-queries，-k：可以设置kill长查询。 

· -verbose，-v：0=silent，1=errors， 2=warmings，3=info，默认是2。

· -binlogs，-b：导出binlog。 

· -daemon，-D：启用守护进程模式。

· -snapshot-interval，-I:dump快照间隔时间，默认60s。 

· -logfile，-L:mysaqldumper的目志输出，一般在Daemon模式下使用。

三. 热备份与恢复 

xtrabackup手册：https://www.percona.com/doc/percona-xtrabackup/2.4/installation/yum_repo.html

热备份的方式也是直接复制数据物理文件，和冷备份一样，但热备份可以不停机直接复制，一般用于7×24小时不间断的重要核心业务。MySQL社区版的热备份 工具ImnoDB Hot Backup是付费的，只能 试用30天，只有购买企业版才可以得到永久使用权。Percona公司发布了一个xtrabackup热备份工具，和官方付费版的 功能一样，支持在线热备份（备份时不影响数据读写），是商业备份工具 InnoDBHot Backup的一个很好的替代品。下面具体介绍一下这个软件的使用方法。 xtrabackup是Percona公司的开源项目，用以实现类似ImnoDB官方的热备份工具ImmoDB Hot Backup的功能，它能 非常快速地备份与恢复MySQL数据库。

下面来看看xtrabackup的安装方法，安装命令如下：

yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm

rpm -qa | grep xtrabackup Xtrabackup

docker容器中操作命令
apt-get update
apt-get install percona-xtrabackup-24
innobackupex --user=root --password=123456 /data/backup/full


docker pull perconalab/percona-xtrabackup

docker run --rm -it -v /var/lib/mysql:/var/lib/mysql -v /tmp/backup:/xtrabackup_backupfiles perconalab/percona-xtrabackup --backup --host=172.18.0.2 --user=root --password=123456

常用选项:

--host 指定主机

--user 指定用户名

--password 指定密码

--port 指定端口

--databases 指定数据库

--incremental 创建增量备份

--incremental-basedir 指定包含完全备份的目录

--incremental-dir 指定包含增量备份的目录

--apply-log 对备份进行预处理操作 一般情况下，在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。

因 此，此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。

开始进行备份操作,进入 主库中

--redo-only 不回滚未提交事务

--copy-back 恢复备份目录

--backup

xtrabackup --defaults-file=/etc/my.cnf --user=root --password=root --port=3306 --backup --target-dir=/mysql_php

对于热备份实现解释

1. innobackupex启动后，会先fork一个进程，用于启动xtrabackup，然后等待xtrabackup备份ibd数据文件；

2. xtrabackup在备份innoDB数据是，有2种线程：redo拷贝线程和ibd数据拷贝线程。xtrabackup进程开始执行后，会启动一个redo拷贝的线程，用于从最新的 checkpoint点开始顺序拷贝 redo.log；再启动ibd数据拷贝线程，进行拷贝ibd数据。这里是先启动redo拷贝线程的。在此阶段，innobackupex进行处于等待 状态（等待文件被创建）

3. xtrabackup拷贝完成ibd数据文件后，会通知innobackupex（通过创建文件），同时xtrabackup进入等待状态（redo线程依旧在拷贝redo.log）

4. innobackupex收到xtrabackup通知后哦，执行FLUSH TABLES WITH READ LOCK（FTWRL），取得一致性位点，然后开始备份非InnoDB文件（如frm、 MYD、MYI、CSV、opt、par等格式 的文件），在拷贝非InnoDB文件的过程当中，数据库处于全局只读状态。

5. 当innobackup拷贝完所有的非InnoDB文件后，会通知xtrabackup，通知完成后，进入等待状态；

6. xtrabackup收到innobackupex备份完成的通知后，会停止redo拷贝线程，然后通知innobackupex，redo.log文件拷贝完成； 

7. innobackupex收到redo.log备份完成后，就进行解锁操作，执行：UNLOCK TABLES；

8. 最后innbackupex和xtrabackup进程各自释放资源，写备份元数据信息等，innobackupex等xtrabackup子进程结束后退出。