数据库8

第七章节 备份恢复

  1. 运维在数据库备份恢复方面的职责
    1.1 设计备份策略
    (1) 备份什么数据?
    数据部分
    二进制日志
    配置文件
    (2) 什么时间备份
    低估期
    (3) 备份周期
    每周,每天...
    (4) 备份的方式
    逻辑备份: mysqldump,binlog
    物理备份: xtrabackup
    全备
    增量
    热备
    冷备
    (5) 备份脚本设计

    1.2 备份的检查
    (1) 日志
    (2) 备份集的大小和完整性

1.3 备份的恢复演练

1.5 故障恢复

1.6 迁移
同版本
异构平台

简介
优势
技能
工作经历
项目
个人评价
==========================

  1. 备份类型
    2.1 热备 : 在线备份. 不停业务进行备份,对业务影响小. Innodb支持
    2.2 温备 : 锁表备份. 备份过程只能查询,不能修改. MyISAM
    2.3 冷备 : 业务停止备份.

  2. 备份方式
    逻辑备份 : SQL语句的备份.
    物理备份 : 基于数据文件的备份.

  3. 备份工具:
    5.1
    mysqldump : MDP
    逻辑备份工具,备份的就是SQL语句(Create database create table insert)
    文本形式,可读性好,便于管理和备份处理,压缩比更高.
    适用于数据量小的库备份.
    建议:
    <100G

TB: 分布式备份
100PB 怎么备份?

xtrabackup : XBK , PBK
物理备份工具.备份快.原生态支持增量备份.

100 <1T
=============

  1. mysqldump 应用
    6.1 连接参数
    mysqldump -uroot -p123 -S /tmp/mysql.sock
    mysqldump -uroot -p123 -h10.0.0.51 -P3306

6.2 备份基础参数
-- -A 全备参数
mkdir -p /data/backup
[root@db01 ~]# mysqldump -uroot -p123 -S /tmp/mysql.sock -A >/data/backup/full.sql 2>/dev/null
-- -B 单库或多库备份
[root@db01 ~]# mysqldump -uroot -p123 -B huoche school world >/data/backup/db.sql
-- 单表或多表
[root@db01 ~]# mysqldump -uroot -p123 world city country >/data/backup/tab.sql
说明: 单表或多表备份,在恢复时,需要先创建库,use 库中,再source
[root@db01 ~]# mysqldump -uroot -p123 world >/data/backup/tab1.sql

6.3 备份高级参数
6.3.1 --master-data=2
(1) 以注释方式,在备份文件中,自动记录二进制日志名+位置点
(2) 会自动进行锁表操作.(innodb除外).

mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 >/data/backup/full.sql 2>/dev/null

6.3.2 --single-transaction
开启备份时,对InnoDB引擎的表,生成一致性快照备份.不会阻塞这些表的正常业务操作.
mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 --single-transaction >/data/backup/full.sql 2>/dev/null

6.3.3 -R -E --triggers
-R 备份存储过程,函数
-E 备份事件
--triggers 备份触发器

mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers >/data/backup/full.sql 2>/dev/null

6.3.5 --max_allowed_packet=128M
备份大数据量表时候需要添加.

  • Got a packet bigger than 'max_allowed_packet' bytes

mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=128M >/data/backup/full.sql 2>/dev/null

6.3.6 终极备份语句

mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=128M | gzip > /backup/full_$(date +%F).sql.gz

  1. 年终故障演练
    7.1 方案
    数据量: 200G
    备份策略: 每周日23:00 mysqldump全备,周一到周六binlog备份
    故障模拟: 模拟周三上午10点,数据损坏(DROP DATABASE)
    演练过程:
    1,将生产数据提前1周导入测试库.
    2,周日全备模拟
    3,周一到周二binlog备份模拟
    4,周三模拟故障
    5,数据恢复
    6,数据校验
    7,模拟上线
    演练结果:
    1, 在发生数据故障时,需要大约1:00-1:30小时左右可以恢复所有业务.
    2, 此恢复方案,数据恢复较慢,可以考虑更快恢复方案.

7.2 模拟过程:
7.2.1. 模拟原始数据
mysql> create database mdp charset=utf8mb4;
mysql> create table t1 (id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
7.2.2. 模拟周日全备
mysqldump -uroot -p123 -S /tmp/mysql.sock -A --master-data=2 --single-transaction -R -E --triggers --max_allowed_packet=128M | gzip > /data/backup/full_$(date +%F).sql.gz

检查备份
[root@db01 /data/backup]# gunzip full_2019-11-20.sql.gz

7.2.3. 模拟周1的数据
mysql> create table t2 (id int);
mysql> insert into t2 values(1),(2),(3);
mysql> commit;

7.2.5. 周1晚上备份binlog
[root@db01 /data/binlog]# mysqladmin -uroot -p123 flush-logs
[root@db01 /data/binlog]# cp /data/binlog/mysql-bin.000002 /data/backup

7.2.6. 模拟周2的数据
mysql> create table t3 (id int);
mysql> insert into t3 values(1),(2),(3);
mysql> commit;

7.2.7. 周2晚上备份binlog
[root@db01 /data/binlog]# mysqladmin -uroot -p123 flush-logs
[root@db01 /data/binlog]# cp /data/binlog/mysql-bin.000003 /data/backup

7.2.8. 周三数据损坏模拟
mysql> drop database mdp;

7.2.9. 恢复数据:
(1) 备份检查
全备
binlog
(2) binlog位置点确认
起点: -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000002', MASTER_LOG_POS=748;
'79f1839c-0439-11ea-83bb-000c29d354c0:1-3'

终点:'79f1839c-0439-11ea-83bb-000c29d354c0:8' 

'79f1839c-0439-11ea-83bb-000c29d354c0:4-7' 
mysql-bin.000002 mysql-bin.000003    mysql-bin.000004  mysql-bin.000005

(3) 截取日志

[root@db01 /data/binlog]# mysqlbinlog --include-gtids='79f1839c-0439-11ea-83bb-000c29d354c0:4-7' --skip-gtids mysql-bin.000002 mysql-bin.000003 mysql-bin.000004 mysql-bin.000005 >/data/backup/bin.sql

(5) 恢复数据
set sql_log_bin=0;
source /data/backup/full_2019-11-20.sql
source /data/backup/bin.sql
set sql_log_bin=1;

  1. XBK应用

8.1 介绍
percona公司研发的MySQL物理备份的工具.使用perl语言开发的.
https://www.percona.com/downloads/Percona-XtraBackup-LATEST/

8.2 安装
wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
yum -y install perl perl-devel libaio libaio-devel perl-Time-HiRes perl-DBD-MySQL libev

wget https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.12/binary/redhat/7/x86_64/percona-xtrabackup-24-2.4.12-1.el7.x86_64.rpm

https://www.percona.com/downloads/XtraBackup/Percona-XtraBackup-2.4.4/binary/redhat/6/x86_64/percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

yum -y install percona-xtrabackup-24-2.4.4-1.el7.x86_64.rpm
[root@db01 ~]# yum install -y percona-xtrabackup-24-2.4.4-1.el6.x86_64.rpm

[root@db01 ~]# innobackupex --version
innobackupex version 2.4.4 Linux (x86_64) (revision id: df58cf2)
[root@db01 ~]#

8.3 xbk备份原理

  1. 自动判断引擎类型
    InnoDB
    Non-InnoDB

  2. InnoDB表 实现热备功能备份
    开始备份innoDB时,自动进程ckpt,将当前已经提交的事务数据,刷写到磁盘,会生成一个CKPT的LSN号.
    cp 数据文件,ibdata ,ibd frm ,ibtmp ,redo(只会拷贝备份期间产生的新的redo),拷贝完成后会产生一个LAST_LSN

  3. 非InnoDB 表
    自动开启 FTWRL (flush tables with read lock) 全局锁
    拷贝数据文件.
    自动解锁.

  4. 增量备份
    基于上一次备份的last_lSN,检查数据页的变化,然后备份走.

8.5 innobackupex 备份工具应用
vim /etc/my.cnf
[clinet]
socket=/tmp/mysql.sock

(1) 全备
[root@db01 ~]# innobackupex --user=root --password=123 /data/backup

-rw-r----- 1 root root 62 11月 20 12:12 xtrabackup_binlog_info
-rw-r----- 1 root root 117 11月 20 12:12 xtrabackup_checkpoints
-rw-r----- 1 root root 538 11月 20 12:12 xtrabackup_info
-rw-r----- 1 root root 2560 11月 20 12:12 xtrabackup_logfile

[root@db01 /data/backup/2019-11-20_12-12-21]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 206912588 ----ckpt
last_lsn = 206912597 ----last-9
compact = 0
recover_binlog_info = 0

生产备份:
innobackupex --user=root --password=123 --no-timestamp /data/backup/full_date +%F

(2) 增量备份应用

-- 1. 模拟周日全备
\rm -rf /data/backup/*
innobackupex --user=root --password=123 --no-timestamp /data/backup/full_date +%F
-- 2. 模拟周一数据变化
mysql> create database xbk charset=utf8mb4;
mysql> use xbk
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;

-- 3. 模拟周一晚上增量
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/full_2019-11-20 /data/backup/inc1

-- 5 . 模拟周二数据变化
use xbk
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;

-- 6. 模拟周二晚上增量
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/inc1 /data/backup/inc2

-- 7. 模拟周三数据变化
use xbk
create table t3(id int);
insert into t3 values(1),(2),(3);
commit;

-- 8. 搞破坏
[root@db01 /data/mysql/data]# \rm -rf /data/mysql/data/*
[root@db01 /data/mysql/data]# pkill mysqld
[root@db01 /data/mysql/data]# \rm -rf /data/mysql/data/*

-- 9. 恢复
备份准备? prepare
模仿了CSR的过程: redo前滚,undo回滚过程.
--apply-log

--apply-log Prepare a backup in BACKUP-DIR by applying the
transaction log file named "xtrabackup_logfile" located
in the same directory. Also, create new transaction logs.
The InnoDB configuration is read from the file
"backup-my.cnf".

--redo-only This option should be used when preparing the base full
backup and when merging all incrementals except the last
one. This forces xtrabackup to skip the "rollback" phase
and do a "redo" only. This is necessary if the backup
will have incremental changes applied to it later. See
the xtrabackup documentation for details.

(1) 原始全备的处理
innobackupex --apply-log --redo-only /data/backup/full_2019-11-20

(2)合并inc1增量到full,prepare所有备份.
innobackupex --apply-log --redo-only --incremental-dir=/data/backup/inc1 /data/backup/full_2019-11-20

(3) 合并inc2增量到full,prepare所有备份.
innobackupex --apply-log --incremental-dir=/data/backup/inc2 /data/backup/full_2019-11-20

(5) 最后一次原始全备的处理
innobackupex --apply-log /data/backup/full_2019-11-20

(6)截取二进制日志
cd /data/backup/inc2
[root@db01 /data/backup/inc2]# cat xtrabackup_binlog_info
mysql-bin.000005 1362 79f1839c-0439-11ea-83bb-000c29d354c0:1-13

mysqlbinlog --start-position=1362 --skip-gtids /data/binlog/mysql-bin.000005 >/data/backup/bin.sql

(7) 恢复备份
[root@db01 /data/backup/full_2019-11-20]# cp -a /data/backup/full_2019-11-20/* /data/mysql/data/
[root@db01 /data/backup/full_2019-11-20]# chown -R mysql.mysql /data/mysql/data/*
[root@db01 ~]# /etc/init.d/mysqld start
mysql> set sql_log_bin=0;
mysql> source /data/backup/bin.sql
mysql> set sql_log_bin=1;

练习:
-- 1. 模拟周日全备
\rm -rf /data/backup/*
innobackupex --user=root --password=123 --no-timestamp /data/backup/full_date +%F
-- 2. 模拟周一数据变化
mysql> create database chp charset=utf8mb4;
mysql> use chp
mysql> create table t1(id int);
mysql> insert into t1 values(1),(2),(3);
mysql> commit;
-- 3. 模拟周一晚上增量
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/full_2019-11-20 /data/backup/inc1

-- 5 . 模拟周二数据变化
use chp
create table t2(id int);
insert into t2 values(1),(2),(3);
commit;

-- 6. 模拟周二晚上增量
innobackupex --user=root --password=123 --no-timestamp --incremental --incremental-basedir=/data/backup/inc1 /data/backup/inc2

-- 7. 模拟周三数据变化
use chp
create table t3(id int);
insert into t3 values(1),(2),(3);
commit;

-- 8. 搞破坏
drop database chp;

-- 9. 恢复

思路1:
(1) 表空间迁移 (恢复周二晚上)
create table t1(id int);
alter table t1 discard tablespace;
cp ibd ...
alter table t1 import tablespace;

(2) binlog日志截取及恢复
mysqlbinlog -d xxxxxx

思路2:
找测试库全备恢复+binlog , 误删除数据dump出来,再导入生产.

====================================
数据库损坏:
1. 物理损坏
2. 逻辑损坏
drop
delete
truncate

思考作业:
假设生产mysqldump全备200G,误删除了一个100M表.怎么快速恢复?

================================================

  1. 数据库迁移
    停机时间 : 停止业务的时间
    回退方案 : 业务快速恢复原状

9.1 同版本,同平台
小 : mysqldump
(1) 备份原库(1:00-2:30)
(2) 备份拷贝到目标库,恢复2:30-3:30
(3) 不断追加binlog到目标库,几乎接近
(5) 停掉原库,4:00,继续追加binlog到目标库,直到追平(5分钟)
(6) 业务的IP地址切换为目标库地址(5分钟),测试应用(业务割接)
大 : XBK

主从复制: 业务停机时间最短

同版本,异构平台
windows -----> linux
mysqldump 逻辑工具迁移

同平台,不同版本
迁移+升级 ,使用mysqldump备份工具进行备份恢复+升级(mysql_upgrade),不要跨太多版本迁移升级

异构数据库
mysql ----CSV---> mongodb
mysql ----json---> mongodb
mysql ---ali cannel--> redis

数据库上云 docker + k8s

体验很重要.

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,744评论 6 502
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,505评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,105评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,242评论 1 292
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,269评论 6 389
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,215评论 1 299
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,096评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,939评论 0 274
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,354评论 1 311
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,573评论 2 333
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,745评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,448评论 5 344
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,048评论 3 327
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,683评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,838评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,776评论 2 369
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,652评论 2 354

推荐阅读更多精彩内容