• msyql的备份与修复


    1.备份的原因

    运维工作的核心简单概括就两件事:
    1)第一个是保护公司的数据.
    2)第二个是让网站能7*24小时提供服务(用户体验)。

    1)备份就是为了恢复。
    2)尽量减少数据的丢失(公司的损失)

    2.备份的类型

    冷备份:
    这些备份在用户不能访问数据时进行,因此无法读取或修改数据。这些脱机备份会阻止执行任何使用数据的活动。这些类型的备份不会干扰正常运行的系统的性能。但是,对于某些应用程序,会无法接受必须在一段较长的时间里锁定或完全阻止用户访问数据。

    温备份:
    这些备份在读取数据时进行,但在多数情况下,在进行备份时不能修改数据本身。这种中途备份类型的优点是不必完全锁定最终用户。但是,其不足之处在于无法在进行备份时修改数据集,这可能使这种类型的备份不适用于某些应用程序。在备份过程中无法修改数据可能产生性能问题。

    热备份:
    这些动态备份在读取或修改数据的过程中进行,很少中断或者不中断传输或处理数据的功能。使用热备份时,系统仍可供读取和修改数据的操作访问。

    3.备份的方式

    逻辑备份

    1)binlog
    2)into outfile

    mysql> select * from world.city into outfile '/tmp/world_city.data';

    3)mysqldump
    4)replication

    物理备份:

    基于数据文件的备份

    1)Xtrabackup(percona公司)

    4.备份策略

    1)全量备份 full
    2)增量备份 increamental

    5.备份工具

    1)mysqldump(逻辑)
    mysql原生自带很好用的逻辑备份工具

    2)mysqlbinlog(逻辑)
    实现binlog备份的原生态命令

    3)xtrabackup(物理)
    precona公司开发的性能很高的物理备份工具

    备份工具使用

    mysqldump的备份

    mysqldump常用参数

    1)连接服务端参数(基本参数):-u -p -h -P -S

    2)-A, --all-databases:全库备份

    [root@db01 ~]# mysqldump -uroot -poldboy123 -A > /backup/full.sql

    3)不加参数:单库、单表多表备份

    [root@db01 ~]# mysqldump -uroot -poldboy123 db1 > /backup/db1.sql

    [root@mysql-db01 backup]# mysqldump -uroot -poldboy123 world city > /backup/city.sql

    4)-B:指定库备份

    [root@db01 ~]# mysqldump -uroot -p123 -B db1 > /backup/db1.sql

    [root@db01 ~]# mysqldump -uroot -p123 -B db1 db2 > /backup/db1_db2.sql

    5)-F:flush logs在备份时自动刷新binlog(不怎么常用)

    [root@db01 backup]# mysqldump -uroot -p123 -A -R –triggers -F > /backup/full_2.sql

    6)--master-data=2:备份时加入change master语句0没有1不注释2注释

    [root@db01 backup]# mysqldump -uroot -p123 --master-data=2 >/backup/full.sql

    7)-d:仅表结构
    8)-t:仅数据

    备份额外扩展项

    1)-R, --routines:备份存储过程和函数数据
    2)--triggers:备份触发器数据

    [root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers > /backup/full_2.sql

    mysqldump特殊参数

    1)-x:锁表备份(myisam温备份)
    2)--single-transaction:快照备份

    [root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction>/backup/full.sql

    mysqldump特殊参数

    1)-x:锁表备份(myisam温备份)
    2)--single-transaction:快照备份

    [root@db01 backup]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction>/backup/full.sql

    3)gzip:压缩备份

    [root@db01 ~]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 –single-transaction|gzip>/backup/full.sql.gz

    mysqldump的恢复

    #先不记录二进制日志

    mysql> set sql_log_bin=0;

    #库内恢复操作

    mysql> source /backup/full.sql

    #库外恢复操作

    [root@db01 ~]# mysql -uroot -p123 < /backup/full.sql

    注意:

    1)mysqldump在备份和恢复时都需要MySQL实例启动为前提
    2)一般数据量级100G以内,大约15-30分钟可以恢复(PB、EB就需要考虑别的方式)
    3)mysqldump是以覆盖的形式恢复数据的

    企业故障恢复案例

    背景:
    正在运行的网站系统,MySQL数据库,数据量25G,日业务增量10-15M。

    备份策略:
    每天23:00,计划任务调用mysqldump执行全备脚本

    故障时间点:
    上午10点开发人员误删除一个核心业务表,如何恢复?

    思路:

    1)停业务避免数据的二次伤害
    2)找一个临时的库,恢复前一天的全备
    3)截取前一天23:00到第二天10点误删除之间的binlog,恢复到临时库
    4)测试可用性和完整性
    5)开启业务前的两种方式

    a.直接使用临时库顶替原生产库,前端应用割接到新库

    b.将误删除的表单独导出,然后导入到原生产环境

    6)开启业务

    故障模拟演练:

    准备数据:

    #刷新binlog使内容更清晰

    mysql> flush logs;

    #查看当前使用的binlog

    mysql> show master status;

    #创建backup库

    mysql> create database backup;

    #进入backup库

    mysql> use backup

    #创建full表

    mysql> create table full select * from world.city;

    #创建full_1表

    mysql> create table full_1 select * from world.city;

    #查看表

    mysql> show tables;

    全备:

    [root@db01 ~]# mysqldump -uroot -p123 -A -R --triggers --master-data=2 --single-transaction|gzip > /backup/full_$(date +%F).sql.gz

    模拟数据变化:

    #进入backup库

    mysql> use backup

    #创建new表

    mysql> create table new select * from mysql.user;

    #创建new_1表

    mysql> create table new_1 select * from world.country;

    #查看表

    mysql> show tables;

    #查看full表中所有数据

    mysql> select * from full;

    #把full表中所有的countrycode都改成CHN

    mysql> update full set countrycode='CHN' where 1=1;

    #提交 mysql> commit; #删除id大于200的数据

    mysql> delete from full where id>200;

    #提交

    mysql> commit;

    模拟故障:

    #删除new表

    mysql> drop table new;

    #查看表

    mysql> show tables;

    恢复过程:

    1)准备临时数据库

    [root@db02 ~]# mysqld_safe --defaults-file=/data/3307/my.cnf &

    2)拷贝数据到新库上

    [root@db02 ~]# scp /backup/full_2018-08-16.sql.gz root@10.0.0.52:/tmp

    2)拷贝数据到新库上

    [root@db02 ~]# scp /backup/full_2018-08-16.sql.gz root@10.0.0.52:/tmp

    3)解压全备数据文件

    #进入tmp目录

    [root@db02 ~]# cd /tmp/

    #解压全备数据文件

    [root@db02 tmp]# gzip -d full_2018-08-16.sql.gz

    截取二进制

    #查看全备的位置点(起始位置点)

    [root@db02 tmp]# head -50 full_2018-08-16.sql |grep -i 'change master to'

    #找到drop语句执行的位置点(结束位置点)

    mysql> show binlog events in 'mysql-bin.000017';

    #截取二进制

    [root@db01 tmp]#mysqlbinlog -uroot -p123 --start-position=268002 --stop-position=671148 /application/mysql/data/mysql-bin.000017 > /tmp/inc.sql

    #发送增量数据到新库

    [root@db01 tmp]# scp /tmp/inc.sql root@10.0.0.52:/tmp

    在新库内恢复数据 #不记录二进制日志

    mysql> set sql_log_bin=0;

    #恢复全备数据

    mysql> source /tmp/full_2018-08-16.sql

    #进入backup库

    mysql> use backup

    # 查看表

    mysql> show tables;

    #恢复增量数据

    mysql> source /tmp/inc.sql

    #查看表

    mysql> sh

    4)将故障表导出并恢复到生产

    #导出new表

    [root@db02 ~]# mysqldump -uroot -p123 -S /data/3307/mysql.sock backup new > /tmp/new.sql

    #发送到生产库

    [root@db02 ~]# scp /tmp/new.sql root@10.0.0.51:/tmp/

    #进入backup库

    mysql> use backup

    #在生产库恢复数据

    mysql> source /tmp/new.sql

    #查看表

    mysql> show tables;

  • 相关阅读:
    安卓基础值之Intent
    输入值/表单提交参数过滤有效防止sql注入的方法
    一致性hash
    linux授权某个用户对某个目录有读写的权限
    mysql分区功能详细介绍,以及实例
    SVN分支与主干
    solr查询
    mysql-proxy做客户端连接转发【外网访问内网mysql】
    liunx 下安装 php_screw 扩展 以及报错处理
    邮件发送
  • 原文地址:https://www.cnblogs.com/fangdecheng/p/10073264.html
Copyright © 2020-2023  润新知