概述
文章目录
- 前言
- 一、mysql主从复制参数
- 二、冷备份与恢复
- 2.1 逻辑备份 (相当于 `Navicat 的导出`)
- 2.1.2 物理备份
- 2.1.3 使用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’实现。
二、冷备份与恢复
2.1 逻辑备份 (相当于 Navicat 的导出
)
数据库逻辑备份就是备份软件按照最初设计的逻辑关系,以数据库的逻辑结构对象为单位,将数据库中的数据按照预定义的逻辑关联格式一条一条生成相关的文本文件,以达到备份的目的。 逻辑备份可以说是最简单,也是目前中小型系统最常使用的备份方式。在MySQL中常用的:
- mysqldump
- mydumper
2.1.1 创建一个数据库 mysql_php ;
mysql> create database mysql_php;
Query OK, 1 row affected (0.01 sec)
2.1.2 在从服务上通过连接主服务器上的数据库,通过mysqldump备份数据到从数据库中
mysql> flush tables with read lock;
2.1.3 然后在从服务器上进行数据的备份,并同步导入备份数据
[root@localhost ~]# mysqldump -h 192.168.81.132 -u root -p mysql_php > /home/mysql_php.sql
Enter password:
[root@localhost ~]# mysql -f -u root -p mysql_php < /home/mysql_php.sql
Enter password:
[root@localhost ~]# mysql -u root -p
Enter password:
mysql> use mysql_php;
Database changed
mysql> show tables;
在数据备份完成之后这个时候就可以恢复主数据库的写操作执行命令如下:
mysql> unnlock tables;
2.1.2 物理备份
停止主库,然后复制主库中的data放到从库中…
2.1.3 使用mydumper
mydumper是一个针对MySQL和drizzle的高性能多线程的备份和恢复工具。此工具的开发人员分别来自MySQL、facebook、skysql公司、目前已经有一些大型产 品业务测试并使用了该工具。我们在恢复 数据库时也可使用myloader工具。 Mydumper的主要特性包括: · 采用轻量级C语言写的代码。 · 相比于mysqldump,其速度快了近10倍。 · 具有事务性和非事务性表一致的快照(适用于0.2.2+)。 · 可快速进行文件压缩(File compression on-the-fly)。 · 支持导出binlog。 · 可多线程恢复(适用于0.2.1+)。 · 可以用守护进程的工作方式,定时扫描和输出连续的二进制日志。
安装命令如下所示:
[root@localhost wwwroot]# yum install mydumper-0.9.5-2.el7.x86_64.rpm [root@localhost wwwroot]# mydumper
[root@localhost wwwroot]# mydumper -V
mydumper 0.9.5, built against MySQL 5.7.27
mydumper与mysqldump 备份数据对比
[root@localhost home]# time mydumper -u root -p root -B mysql_php -o /home/mysql_php
real 0m0.039s
user 0m0.004s
sys 0m0.035s
[root@localhost home]# time mysqldump -u root -p mysql_php > /home/mysql_php.sql
Enter password:
real 0m2.093s
user 0m0.016s
sys 0m0.047s
对比mysql与myloader数据还原
[root@localhost home]# time mysql -f -u root -p mysql_php < /home/mysql_php.sql
Enter password:
real 0m2.511s
user 0m0.017s
sys 0m0.033s
[root@localhost home]# time myloader -u root -p root -B mysql_php -d /home/mysql_php
** (myloader:9506): CRITICAL **: 06:38:43.292: the specified directory is not a mydumper backup
real 0m0.006s
user 0m0.003s
sys 0m0.003s
三、热备份与恢复
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的安装方法,安装命令如下:
[root@localhost file]$ yum localinstall percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
[root@localhost file]# rpm -qa | grep xtrabackup Xtrabackup
常用选项:
–host 指定主机
–user 指定用户名
–password 指定密码
–port 指定端口
–databases 指定数据库
–incremental 创建增量备份
–incremental-basedir 指定包含完全备份的目录
–incremental-dir 指定包含增量备份的目录
–apply-log 对备份进行预处理操作 一般情况下,在备份完成后,数据尚且不能用于恢复操作,因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。 因 此,此时数据文件仍处理不一致状态。“准备”的主要作用正是通过回滚未提交的事务及同步已经提交的事务至数据文件也使得数据文件处于一致性状态。
–redo-only 不回滚未提交事务
–copy-back 恢复备份目录
–backup
开始进行备份操作,进入 主库 中
[root@centos ~]# xtrabackup --defaults-file=/etc/my.cnf --user=root --password=root --port=3306 --backup --target-dir=/mysql_php
[root@localhost home]# ll /mysql_php
[root@localhost home]# scp -r /mysql_php root@192.168.153.127:/home/mysql_php
然后呢进入 从从库库 中
[root@localhost server]# ll /home/mysql_php
[root@localhost server]#
[root@localhost server]# /etc/init.d/mysqld stop Shutting down MySQL.. SUCCESS!
[root@localhost server]# mv /usr/local/mysql/data /usr/local/mysql/data2 [root@localhost server]# xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/mysql_php
[root@localhost server]# chown -R mysql:mysql /usr/local/mysql/data [root@localhost server]# /etc/init.d/mysqld start Starting MySQL.Logging to '/www/server/data/localhost.localdomain.err'. . SUCCESS!
[root@localhost server]# mysql -u root -p
mysql> show databases;
对于热备份实现解释
- innobackupex启动后,会先fork一个进程,用于启动xtrabackup,然后等待xtrabackup备份ibd数据文件;
- xtrabackup在备份innoDB数据是,有2种线程:redo拷贝线程和ibd数据拷贝线程。xtrabackup进程开始执行后,会启动一个redo拷贝的线程,用于从最新的 checkpoint点开始顺序拷贝 redo.log;再启动ibd数据拷贝线程,进行拷贝ibd数据。这里是先启动redo拷贝线程的。在此阶段,innobackupex进行处于等待 状态(等待文件被创建)
- xtrabackup拷贝完成ibd数据文件后,会通知innobackupex(通过创建文件),同时xtrabackup进入等待状态(redo线程依旧在拷贝redo.log)
- innobackupex收到xtrabackup通知后哦,执行FLUSH TABLES WITH READ LOCK(FTWRL),取得一致性位点,然后开始备份非InnoDB文件(如frm、 MYD、MYI、CSV、opt、par等格式 的文件),在拷贝非InnoDB文件的过程当中,数据库处于全局只读状态。
- 当innobackup拷贝完所有的非InnoDB文件后,会通知xtrabackup,通知完成后,进入等待状态;
- xtrabackup收到innobackupex备份完成的通知后,会停止redo拷贝线程,然后通知innobackupex,redo.log文件拷贝完成;
- innobackupex收到redo.log备份完成后,就进行解锁操作,执行:UNLOCK TABLES;
- 最后innbackupex和xtrabackup进程各自释放资源,写备份元数据信息等,innobackupex等xtrabackup子进程结束后退出。
总结
冷备份 在主从梳理实际项目过程:
1.开启主库binlog
2.配置主库复制账号
3.停止写操作(上锁)=》数据的备份
4.备份之后 =》启动服务 =》释放锁
5.从库配置
6.指定 ip,port,user等。。
7.启动主从
8.还原 同步主库数据
热备份 在主从梳理实际项目过程:
- 主库执行备份操作=》真的data文件
1.1 把备份的主库文件远程传输给从库 - 从库需要保持-》选择合并,选择data为空或者不存在
2.1 停止从数据库的服务
2.2 重命名data文件 - 配置从库的my.cnf – 与主库配置尽量一致
- 恢复数据
最后
以上就是畅快音响为你收集整理的mysql优化系列(十九)- mysql主从复制备份前言一、mysql主从复制参数二、冷备份与恢复三、热备份与恢复总结的全部内容,希望文章能够帮你解决mysql优化系列(十九)- mysql主从复制备份前言一、mysql主从复制参数二、冷备份与恢复三、热备份与恢复总结所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复