MySQL备份与恢复

212dqw

一：备份的类型
    1.1按数据库服务器的状态
    1.2按备份文件的类型
    1.3备份数据库的内容





二：备份策略
    2.1备份应该备份什么？
    2.2物理备份还是逻辑备份？
    2.3备份策略




三：MySQL备份工具
    3.1 mysqldump
    3.2 mysqlhotcopy
    3.3 ibackup
    3.4 xtrabackup


1.1按数据库服务器的状态
    热备份：在线备份，读写操作不受影响
    温备份：能读不能写，仅能执行读操作
    冷备份：离线备份，读写操作都不能进行


1.2按备份文件的类型
    物理备份：直接备份数据文件
    逻辑备份：将数据导出到文本文件中

1.3备份数据库的内容
    完全备份：备份全部数据，可能是某个库的全部数据，也可能是所有库的全部数据
    增量备份：仅备份上次完全备份或增量备份以后变化的数据
    差异备份：仅备份上次完全备份以后变化的数据





2.1备份应该备份什么？
    数据、配置文件、二进制日志、事务日志



2.2物理备份还是逻辑备份？
    物理备份：速度快
    逻辑备份：速度慢、丢失浮点数精度、可以方便使用文本处理工具直接对其处理、可移植能力好、跨MySQL服务器版本



2.3备份策略
    根据数据量的大小，可以做不同的选择，例如：一周一次完全，一天一次增量或差异或者一个月一次完全备份，一天一次增量或者差异备份
    完全+增量      
    完全+差异


3.1mysqldump逻辑备份工具、MyISAM(温备份)、InnoDB(热备份)
3.1.1备份单个数据库或库中的特定表
    db_name[tb1][tb2]：备份指定数据库，不包括创建数据库的命令，所以恢复的时候必须手动的创建数据库

1	mysqldump -uroot -p mydb > /root/mydb.sql

注意：以上的方式是在MySQL服务器运行期间执行的备份，如果在备份的过程中有数据插入，会导致数据的不一致。所以在备份的时候一定要锁表










注意：最后一条数据没有在备份文件中，所以如要要拿刚才的备份文件去恢复，是不能够恢复到服务器出事故之前的状态的，但是可以去二进制日志文件中查找读出来，但是到二进制日志文件中查找的时候，怎么知道刚才插入数据的时间点呢？还原的时候应该是完全备份+完全备份以后的事件进行恢复，但是怎么知道二进制日志文件当中刚才从哪个事件开始的？或者说哪个位置？哪个时间点？而且每次还得手动记录存放于哪个二进制日志文件中。



3.1.2 --master-date={0|1|2}
    0表示不记录二进制日志文件及其事件位置
    1表示以CHANGE MASTER TO 的方式记录二进制日志文件位置，可用于恢复后直接启动服务器
    2表示以CHANGE MASTER TO的方式记录二进制日志文件位置，但是默认被注释掉了











3.1.3--lock-all-tables：锁定所有表

3.1.4--flush-logs：执行日志滚动      

3.1.5如果指定库中的表类型都为InnoDB，可使用--single-transaction启动热备，使用它的时候就不需要在使用--lock-all-tables选项了，它会自动释加锁

3.1.6备份多个库
    --all-databases：备份所有库
    --databases DB_NAME1,DB_NAME2...：备份指定库
注：这两个选项都会自动创建CREATEDATABASE命令，所以还原的时候就不用在手动指定库了



3.1.7其它选项
    --event：备份数据库的事件调度器
    --routines：备份存储过程和存储函数
    --triggers：备份触发器

3.1.8执行备份与还原
    备份策略：周完全+日增量
完全备份：mysql>mysqldump
增量备份：备份二进制日志文件（flush logs）


模拟完全备份，然后每天备份增量
1.假如现在是第一次执行mydb数据库的完全备份






2.执行完完全备份以后，进入数据库做一些操作，模拟这些操作是在第二天用户做的



3.然后模拟执行第二天的增量备份


4.mysql-bin.000019是第一天的增量




5.模拟到了第二天了，增加了一些信息


6.假如一不小心把整个数据库给删了，假如二进制日志文件和数据没放到同一目录下



7.关闭mysql服务，初始化数据库，启动mysql服务





8.开始使用备份文件进行数据库恢复







注意：此时还没有恢复到数据库出事故前一刻的状态，需要执行数据库出事故前一刻的二进制日志文件进行最终的恢复