linux mysql备份和恢复

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了linux mysql备份和恢复相关的知识,希望对你有一定的参考价值。

参考技术A 备份所有数据库# mysqldump -u root -p --opt --all-databases > /root/all-databases
修复# myisamchk -r /var/lib/mysql/allusers/names.MYI
或# myisamchk -o /var/lib/mysql/allusers/names.MYI

参考资料:《Fedora 6和Red Hat Enterprise Linux宝典》

参考技术B 备份mysqldump -uroot -p --opt 数据库名 > /usr/datebasename.sql
恢复mysqldump -uroot -p --opt 数据库名 < /usr/datebasename.sql
参考技术C

前言

MySQL 5.6引入了GTID,每个事务都会产生一个GTID,我们可以通过验证主从GTID来验证主从数据的一致性。

为了叙述简便,定义一个量ALL_GTID: 表示某个数据库实例上 所有存在过的 或 将要存在的事务 的GTID(包括已经被purge掉的事务)。

在讨论数据库可用性的场景中, 当发生主备切换时, 需要进行数据补偿。通过比较主备的ALL_GTID,可以确定需要补偿多少数据:

    在实例存活的情况,可以在实例状态中查询ALL_GTID。

    在实例崩溃的情况,无法在实例状态中查询ALL_GTID。可以通过查询BINLOG中的Previous-GTIDs计算来获得ALL_GTID。

    下面列举与ALL_GTID相关的变量。

    与ALL_GTID相关的变量

    Previous-GTIDs

    Previous-GTIDs格式如下(环境为MySQL5.7,日志手动flush binary logs获得):

    查看新轮转出的BINLOG:


    下面为mysql-bin.00001中包含的GTID:

    请点击输入图片描述


    然后再次flush binary logs:

    请点击输入图片描述


    mysql-bin.00002中是没有任何GTID的。

    请点击输入图片描述


    综上Previous-GTIDs是本身这个BINLOG文件前面的所有BINLOG的集合。

    请点击输入图片描述

    全局变量中的GTID相关的变量

    请点击输入图片描述

    变量解释:

    gtid_executed 代表着server上所有事务执行产生的GTID(包含已经被purge的BINLOG中的GTID或者是手动set gtid_purged的GTID)。

    gtid_purged 代表着已经被purge到的GTID。gtid_purged是gtid_executed的子集。

    gtid_retrieved 是从机上relay_log中的GTID。

    ALL_GTID 的计算

    了解了GTID相关的变量之后,可以得到获得实例的All_GTID的集合的方法:

    对象

    方法

    存活的Master实例    gtid_executed    

    存活的Slave实例    gtid_executed和gtid_retrieved的并集    

    非存活Master实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

    非存活Slave实例    最后一个BINLOG文件的Previous-GTIDs + 最后一个BINLOG文件中所有的GTID    

    在获得非存活实例中的ALL_GTID时,最后一个BINLOG文件中的GTID可能不连续(比如事务同时来自于本实例客户端和复制回放),所以需要扫描最后一个BINLOG文件。

    生产中我们使用Xtrabackup来产生一个 从实例 的流程如下:

    拉取备份,进行还原

    change master to

    set @@global.gtid_purged='xxx';

    set @@global.gtid_purged='xxx'; 的影响:

    将 从实例 的ALL_GTID手工置为xxx, 在通过GTID方式建立复制时不会出错.

    将更新Binlog中记录的Previous-GTIDs (由于Binlog不可改变, 将产生新的Binlog, 记录新的Previous-GTIDs).

    MySQL 5.7中set gtid_purged的行为变更

    问题描述

    回顾一下备份恢复的流程:

    拉取备份,进行还原

    change master to

    set @@global.gtid_purged='xxx';

    现象: 发现有一台MySQL 5.7的Slave服务器恢复后没有产生 正确的Previous-GTIDs。

    分析

    分析整个过程,解决问题应该分阶段进行手动模拟发现问题。以下为详细步骤:

    手工还原备份

    环境

    BINLOG数量,Previous-GTIDs状态

    Xtrabackup 2.4.2 & MySQL 5.6    1,空    

    Xtrabackup 2.4.2 & MySQL 5.7    1,空    

    Xtrabackup 2.2.9 & MySQL 5.6    1,空    

    Xtrabackup 2.2.9 & MySQL 5.7    1,空    

    可见: 恢复过程不会轮转BINLOG。

    验证change master和set gtid_purged在不同的MySQL版本中执行的差异

    环境

    BINLOG数量,Previous-GTIDs状态

    change master & MySQL 5.6    1,空    

    change master & MySQL 5.7    1,空    

    set gtid_purged & MySQL 5.6    2,正常    

    set gtid_purged & MySQL 5.7    1,空    

    可见: 执行set gtid_purged时不同版本的MySQL产生了差异

    验证

    对不同版本MySQL单独执行set @@global.gtid_purged='';语句。检查结果

    环境

    进行的操作

    BINLOG数量,Previous-GTIDs状态

    MySQL 5.7    reset master; set @@global.gtid_purged=”;    1,空    

    MySQL 5.6    reset master; set @@global.gtid_purged=”;    2,正常    

    结论

    参考: http://bugs.mysql.com/bug.php?id=75767

    官方解释: 在5.7版本中,执行SET GTID_PURGED语句后binlog_simple_gtid_recovery会给GTID_PURGED计算出一个错误的值。

    由于5.7中新增了存储GTID的表。所以5.7版本中set @@global.gtid_purged='';语句被改成只修改存放GTID的表。

    而5.6版本中会进行BINLOG轮转和向Previous_gtids_log_event中添加GTID。如果5.7需要产生和5.6相同结果的话,可以在SET GTID_PURGED语句后手动执行flush binary logs语句。

Linux 数据备份和恢复

1、Linux系统需要备份的数据

    /root/目录:

    /home/目录:
    /var/spool/mail/目录:

    /etc/目录: 其他目录:

2、安装服务的数据

    apache需要备份的数据

    配置文件 、 网页主目录 、 日志文件

    mysql需要备份的数据  =>   源码包安装的mysql:/usr/local/mysql/data/

    RPM包安装的mysql:/var/lib/mysql/

3、完全备份、增量备份、差异备份

  (01)、备份命令  =>  dump [选项] 备份之后的文件名  原文件或目录

      选项:

        -level:就是我们说的0-9是个备份级别

        -f文件名:指定备份之后的文件名

        -u(常用):备份成功之后,把备份时间记录在/etc/dumpdates文件中

        -v:显示更多过程

        -j(常用):调用bzlib库压缩备份文件,其实就是把备份文件压缩为.bz2格式

        -w:显示允许dump的分区的备份等级及备份时间

        例子:备份分区

            dump -0uj -f /root/boot.bak.bz2 /boot/   

            #备份命令。先执行一次完全备份,并压缩和更新备份时间

            cat /etc/dumpdates

            #查看备份时间文件

            cp install.log /boot/

            #复制日志文件到/boot分区

            dump -1uj -f /root/boot.bak1.bz2 /boot/

            #增量备份/boot分区,并压缩 dump –W #查询分区的备份时间及备份级别的

        例子:备份文件或目录   =>  dump -0j -f  [文件名] /root/etc.dump.bz2 /etc/

             #完全备份/etc/目录,只能使用0级别进行完全备份 ,而不再支持增量备份

  (02)、恢复命令   =>  restore [模式选项][选项]

      模式选项:restore命令常用的模式有一下四种,这四种模式不能混用

        -C:比较备份数据和实际数据的变化

        -i:进入交互模式,手工选择需要恢复的文件

        -t:查看模式,用于查看备份文件中拥有哪些数据

        -r:还原模式,用于数据还原、

      选项:

        -f:指定备份文件的文件名

以上是关于linux mysql备份和恢复的主要内容,如果未能解决你的问题,请参考以下文章

Linux 数据备份和恢复

linux mysql备份和恢复

Linux数据库备份和恢复

linux中mysql如何备份与恢复

Linux--MySQL 日志管理备份与恢复

Linux下mysql备份 恢复