MySQL备份与恢复之保证数据一致性(5)

在上一篇文章中我们提到热拷贝(MySQL备份与恢复之热拷贝),热拷贝也就是在MySQL或者其他数据库服务在运行的情况下使用mysqlhotcopy命令进行备份。这篇文章我们讲解怎样保证数据一致性。现在假设有这样一种情况,我们总是在凌晨对数据库进行备份,假设在凌晨之后发生数据库异常,并且导致数据丢失。这样凌晨之前的数据我们已经做了备份,但是凌晨到发生异常这段时间的数据就会丢失(没有binlog的情况下)。好在InnoDB存储引擎支持事务,也支持Binlog,凌晨到发生异常这段时间的数据就可以通过日志文件进行备份。所以,日志文件是非常重要,非常关键的。我们备份不仅要对数据进行备份,如果条件允许还需要对二进制文件进行备份。当然备份好数据之后,可以清空二进制文件,但如果为了长远考虑,比如恢复出来的数据并不是我们想要的,我们就需要备份二进制文件了。还有一点切记,恢复数据需要转到测试数据库中做,不要在生产环境中做。待测试库中测试没有问题,再在生产环境中做。
示意图

保证数据一致性模拟
第一步,验证数据

[root@serv01 databackup]# rm -rf *
[root@serv01 databackup]# ls

mysql> use larrydb;
Database changed
mysql> show tables;
+-------------------+
| Tables_in_larrydb |
+-------------------+
| class  |
| stu  |
+-------------------+
2 rows in set (0.00 sec)

mysql> select * from class;
+------+--------+
| cid | cname |
+------+--------+
| 1 | linux |
| 2 | oracle |
+------+--------+
2 rows in set (0.00 sec)

mysql> select * from stu;
+------+---------+------+
| sid | sname | cid |
+------+---------+------+
| 1 | larry01 | 1 |
| 2 | larry02 | 2 |
+------+---------+------+
2 rows in set (0.00 sec)

第二步,备份数据

[root@serv01 databackup]# mysqldump -uroot -p123456 --database larrydb > larrydb.sql
[root@serv01 databackup]# ll larrydb.sql
-rw-r--r--. 1 root root 2613 Sep 10 19:34 larrydb.sql

第三步,清空日志,因为已经做了备份,所以不需要以前的日志

mysql> show binary logs;
+------------------+-----------+
| Log_name  | File_size |
+------------------+-----------+
| mysql-bin.000001 | 27320 |
| mysql-bin.000002 | 1035309 |
| mysql-bin.000003 | 1010 |
| mysql-bin.000004 | 22809 |
| mysql-bin.000005 | 9860 |
| mysql-bin.000006 | 5659 |
| mysql-bin.000007 | 126 |
| mysql-bin.000008 | 10087 |
| mysql-bin.000009 | 8293 |
| mysql-bin.000010 | 476 |
| mysql-bin.000011 | 218 |
| mysql-bin.000012 | 126 |
| mysql-bin.000013 | 1113 |
| mysql-bin.000014 | 1171 |
| mysql-bin.000015 | 126 |
| mysql-bin.000016 | 107 |
| mysql-bin.000017 | 107 |
| mysql-bin.000018 | 13085 |
+------------------+-----------+
18 rows in set (0.00 sec)

mysql> reset master;
Query OK, 0 rows affected (0.01 sec)

mysql> show binary logs;
+------------------+-----------+
| Log_name  | File_size |
+------------------+-----------+
| mysql-bin.000001 | 107 |
+------------------+-----------+
1 row in set (0.00 sec)

第四步,更新数据

mysql> insert into class values(3,'Devel');
Query OK, 1 row affected (0.01 sec)

mysql> update class set cname="dab" where cid=2;
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from class;
+------+-------+
| cid | cname |
+------+-------+
| 1 | linux |
| 2 | dab |
| 3 | Devel |
+------+-------+
3 rows in set (0.00 sec)

mysql> select * from stu;
+------+---------+------+
| sid | sname | cid |
+------+---------+------+
| 1 | larry01 | 1 |
| 2 | larry02 | 2 |
+------+---------+------+
2 rows in set (0.00 sec)

mysql> delete from stu where cid=2;
Query OK, 1 row affected (0.00 sec)

mysql> update stu set sname="larry007" where sid=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from stu;
+------+----------+------+
| sid | sname | cid |
+------+----------+------+
| 1 | larry007 | 1 |
+------+----------+------+
1 row in set (0.00 sec)

[root@serv01 data]# date
Tue Sep 10 19:38:24 CST 2013

第五步,模拟数据丢失,删除库

[root@serv01 data]# rm -rf /usr/local/mysql/data/larrydb/

mysql> show databases;
+--------------------+
| Database  |
+--------------------+
| information_schema |
| game  |
| hello  |
| mnt  |
| mysql  |
| performance_schema |
| test  |
+--------------------+
7 rows in set (0.00 sec)

[root@serv01 data]# cd /usr/local/mysql/data/
[root@serv01 data]# ll
total 28736
drwx------. 2 mysql mysql 4096 Sep 10 19:14 game
drwx------. 2 mysql mysql 4096 Sep 7 00:43 hello
-rw-rw----. 1 mysql mysql 18874368 Sep 10 19:36 ibdata1
-rw-rw----. 1 mysql mysql 5242880 Sep 10 19:36 ib_logfile0
-rw-rw----. 1 mysql mysql 5242880 Sep 4 23:39 ib_logfile1
drwxr-xr-x. 2 mysql mysql 4096 Sep 10 18:35 mnt
drwxr-xr-x. 2 mysql mysql 4096 Sep 4 23:39 mysql
-rw-rw----. 1 mysql mysql 998 Sep 10 19:37 mysql-bin.000001
-rw-rw----. 1 mysql mysql 19 Sep 10 19:34 mysql-bin.index
drwx------. 2 mysql mysql 4096 Sep 4 23:39 performance_schema
-rw-r-----. 1 mysql root 26371 Sep 10 19:30 serv01.host.com.err
-rw-rw----. 1 mysql mysql 5 Sep 10 18:36 serv01.host.com.pid
drwx------. 2 mysql mysql 4096 Sep 7 00:13 test

#可以使用mysqlbinlog命令查看日志文件
[root@serv01 data]# mysqlbinlog mysql-bin.000001

mysql> show databases;
+--------------------+
| Database  |
+--------------------+
| information_schema |
| game  |
| hello  |
| mnt  |
| mysql  |
| performance_schema |
| test  |
+--------------------+
7 rows in set (0.00 sec)

mysql> drop database larrydb;
Query OK, 0 rows affected (0.01 sec)

第六步,导入更新之前的数据

[root@serv01 databackup]# mysql -uroot -p123456 < larrydb.sql
ERROR 1050 (42S01) at line 33: Table '`larrydb`.`class`' already exists
[root@serv01 databackup]# mysql -uroot -p123456 < larrydb.sql 

mysql> use larrydb;
Database changed
mysql> select * from stu;
+------+---------+------+
| sid | sname | cid |
+------+---------+------+
| 1 | larry01 | 1 |
| 2 | larry02 | 2 |
+------+---------+------+
2 rows in set (0.00 sec)

mysql> select * from class;
+------+--------+
| cid | cname |
+------+--------+
| 1 | linux |
| 2 | oracle |
+------+--------+
2 rows in set (0.00 sec)

第七步,根据日志恢复数据

[root@serv01 data]# mysqlbinlog --stop-datetime "2013-09-10 19:37:45" mysql-bin.000001 | mysql -uroot -p123456

mysql> select * from stu;
+------+---------+------+
| sid | sname | cid |
+------+---------+------+
| 1 | larry01 | 1 |
+------+---------+------+
1 row in set (0.00 sec)

mysql> select * from class;
+------+-------+
| cid | cname |
+------+-------+
| 1 | linux |
| 2 | dab |
| 3 | Devel |
+------+-------+
3 rows in set (0.00 sec)

#规律:恢复的时间点(或者是Commit之后的那个时间点)是发生事故的那个点再加上一秒。
[root@serv01 data]# mysqlbinlog --stop-datetime "2013-09-10 19:37:46" mysql-bin.000001 | mysql -uroot -p123456

mysql> select * from stu;
+------+----------+------+
| sid | sname | cid |
+------+----------+------+
| 1 | larry007 | 1 |
+------+----------+------+
1 row in set (0.00 sec)

mysql> select * from class;
+------+-------+
| cid | cname |
+------+-------+
| 1 | linux |
| 2 | dab |
| 3 | Devel |
| 3 | Devel |
+------+-------+
4 rows in set (0.00 sec)

[root@serv01 data]# mysqlbinlog mysql-bin.000001
# at 7131
#130910 19:37:45 server id 1 end_log_pos 7240 Query thread_id=20 exec_time=996 error_code=0
SET TIMESTAMP=1378813065/*!*/;
update stu set sname="larry007" where sid=1
/*!*/;
# at 7240
#130910 19:37:45 server id 1 end_log_pos 7312 Query thread_id=20 exec_time=996 error_code=0
SET TIMESTAMP=1378813065/*!*/;
COMMIT
/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

以上就是本文的全部内容,不知道大家是否有所收获,联系前几篇的内容进行理解,学习效果会更好哦

(0)

相关推荐

  • Mysql 主从数据库同步(centos篇)

    环境: 主服务器:centos 5.2 mysql 5.1.35 源码 IP:192.168.1.22 从服务器:centos 5.2 mysql 5.1.35 源码  IP:192.168.1.33 配置: 一.主服务器 1.1.创建一个复制用户,具有replication slave 权限. mysql>grant replication slave on *.* to 'repl'@'192.168.1.22' identified by 'repl'; 1.2.编辑my.cnf文件 vi

  • 减少mysql主从数据同步延迟问题的详解

    基于局域网的master/slave机制在通常情况下已经可以满足'实时'备份的要求了.如果延迟比较大,就先确认以下几个因素: 1. 网络延迟2. master负载3. slave负载一般的做法是,使用多台slave来分摊读请求,再从这些slave中取一台专用的服务器,只作为备份用,不进行其他任何操作,就能相对最大限度地达到'实时'的要求了 另外,再介绍2个可以减少延迟的参数 –slave-net-timeout=seconds  参数含义:当slave从主数据库读取log数据失败后,等待多久重新

  • 如何恢复MySQL主从数据一致性

    最近被告知,MySQL主从数据库的数据不一致,猜测备库在同步过程中出现了问题,于是,登上备库,使用 mysql> show slave status\G查看,果然,备库在insert语句中因违反主键约束,导致备库停止了同步.现在的问题很明确,就是如何恢复主从库数据的一致性. 可选方案如下: 一.查看Master最新的Position,将其作为Slave复制的起点. 这种思路体现的是过去的不一致既往不咎,现在保持同步即可.看起来,这个思路和恢复主从库数据的一致性的初衷有所违背,但这种方法,简单,高

  • mysql主从数据库不同步的2种解决方法

    今天发现Mysql的主从数据库没有同步 先上Master库: mysql>show processlist; 查看下进程是否Sleep太多.发现很正常. show master status; 也正常. mysql> show master status; +-------------------+----------+--------------+-------------------------------+ | File | Position | Binlog_Do_DB | Binlo

  • Ubuntu配置Mysql主从数据库

    本次环境:虚拟机下 服务器:Ubuntu 14.04 LTS 数据库: 5.5.37 端口:3306 主IP:192.168.63.133 从IP:192.168.63.134 授权账号: user:suxh password:111111 好了交代完环境:我们直接配置: 第一步:主从两台服务器要有同样的数据库(需要同步的)这里用的是backup 数据库(不多说了,在同步开始前,把主库的复制一份到从库就行了) 第二步配置主(master)数据库 编辑/etc/my.cnf 主要是开启二进制日志

  • MHA实现mysql主从数据库手动切换的方法

    本文实例讲述了MHA实现mysql主从数据库手动切换的方法,分享给大家供大家参考.具体方法如下: 一.准备工作 1.分别在Master和Slave执行如下,方便mha检查复制: 复制代码 代码如下: grant all privileges on *.* to 'root'@'10.1.1.231' identified by 'rootpass'; grant all privileges on *.* to 'root'@'10.1.1.234' identified by 'rootpas

  • MYSQL主从数据库同步备份配置的方法

    下文分步骤给大家介绍的非常详细,具体详情请看下文吧. 一.准备 用两台服务器做测试: Master Server: 192.0.0.1/Linux/MYSQL 4.1.12 Slave Server: 192.0.0.2/Linux/MYSQL 4.1.18 做主从服务器的原则是,MYSQL版本要相同,如果不能满足,最起码从服务器的MYSQL的版本必须高于主服务器的MYSQL版本 二.配置master服务器 1. 登录Master服务器,编辑my.cnf #vim /etc/my.cnf 在[m

  • MySQL备份与恢复之保证数据一致性(5)

    在上一篇文章中我们提到热拷贝(MySQL备份与恢复之热拷贝),热拷贝也就是在MySQL或者其他数据库服务在运行的情况下使用mysqlhotcopy命令进行备份.这篇文章我们讲解怎样保证数据一致性.现在假设有这样一种情况,我们总是在凌晨对数据库进行备份,假设在凌晨之后发生数据库异常,并且导致数据丢失.这样凌晨之前的数据我们已经做了备份,但是凌晨到发生异常这段时间的数据就会丢失(没有binlog的情况下).好在InnoDB存储引擎支持事务,也支持Binlog,凌晨到发生异常这段时间的数据就可以通过日

  • MySQL与Redis如何保证数据一致性详解

    前言 由于缓存的高并发和高性能已经在各种项目中被广泛使用,在读取缓存这方面基本都是一致的,大概都是按照下图的流程进行操作: 但是在更新缓存方面,是更新完数据库再更新缓存还是直接删除缓存呢?又或者是先删除缓存再更新数据库?在这一点上就值得探讨了. 一致性方案 在实际项目开发中需要保证数据库和缓存中的数据一致,否则人家充值了100块,不断刷新却还是显示0.01元,岂不是尴尬?从理论上来说,为缓存设置过期时间是最终保证数据一致性的解决方案,采用这种方案的话,所有的写操作都是以数据库为准,如果数据库写入

  • 浅析MySQL 备份与恢复

    1.简介 数据无价,MySQL作为一个数据库系统,其备份自然也是非常重要且有必要去做.备份的理由千千万,预防故障,安全需求,回滚,审计,删了又改的需求等等,备份的重要性不言而喻.除了备份本身, 如何使用备份来恢复 服务也是一项重点内容,不能用来恢复的备份没有意义.本文主要会针对备份和恢复这两方面做一些简单的介绍. 本文为<高性能MySQL>备份相关章节的读书笔记. 2.备份和恢复的简单定义 正如简介所说,备份人尽皆知,也很容易引起人的重视.根据需求写定期脚本,或者使用其他方式都是比较常见的.但

  • MySQL备份与恢复之真实环境使用冷备(2)

    在上一篇文章(MySQL备份与恢复之冷备)中,我们提到了冷备.但是有个问题,我们存储的数据文件是保存在当前本地磁盘的,如果这个磁盘挂掉,那我们存储的数据不就丢失了,这样备份数据不就功亏一篑,劳而无功.所以真实环境中我们多准备几块磁盘,然后再在这些磁盘上搭建LVM,把MySQL的数据目录挂载到LVM上,这样数据就不是存储在当前磁盘上,就可以保证数据的安全性. 示意图 真实环境使用冷备模拟 第一步,需要提前规划好磁盘,这里做模拟,添加两磁盘   第二步,对磁盘进行分区 [root@serv01 ~]

  • MySQL备份与恢复之热备(3)

    在上两篇文章(MySQL备份与恢复之冷备,MySQL备份与恢复之真实环境使用冷备)中,我们提到了冷备和真实环境中使用冷备.那从这篇文章开始我们看下热备.显然热备和冷备是两个相对的概念,冷备是把数据库服务,比如MySQL,Oracle停下来,然后使用拷贝.打包或者压缩命令对数据目录进行备份:那么我们很容易想到热备就是在MySQL或者其他数据库服务在运行的情况下进行备份.但是,这里存在一个问题,因为生产库在运行的情况下,有对该库的读写,读写频率有可能高,也可能低,不管频率高低,总会就会造成备份出来的

  • MySQL和Redis的数据一致性问题

    目录 一.一致性问题 二.方案选择 1.是删除缓存还是更新缓存? 2.先更新数据库,再删除缓存 3.失败重试 4.异步更新缓存 5..先删除缓存,再更新数据库 前言: 在数据读多写少的情况下作为缓存来使用,恐怕是Redis使用最普遍的场景了.当使用Redis作为缓存的时候,一般流程是这样的. 如果缓存在Redis中存在,即缓存命中,则直接返回数据 如果Redis中没有对应缓存,则需要直接查询数据库,然后存入Redis,最后把数据返回 通常情况下,我们会为某个缓存设置一个key值,并针对key值设

  • 连续调用多个外部系统写接口保证数据一致性的思路

    概述 某些场景下,我们将业务数据落地之前,是需要先调用外部系统的多个写接口,当这些写接口都操作成功了,我们才将业务数据落地到自己本地的数据库里面.比如说: public void updateProductInfo(Product product) { //1.将商品价格更新到价格系统 priceService.updatePrice(product); //2.将库存信息更新库存系统 stockService.updateStock(product); //3.将商品更新到本地数据库 prod

  • MySQL是怎么保证主备一致的

    目录 MySQL 主备的基本原理 binlog 的三种格式对比 为什么会有 mixed 格式的 binlog? 循环复制问题 总结: 抛出问题:大家知道 binlog 可以用来归档,也可以用来做主备同步,但它的内容是什么样的呢?为什么备库执行了 binlog 就可以跟主库保持一致了呢? MySQL 主备的基本原理 图 1 MySQL 主备切换流程 在状态 1 中,客户端的读写都直接访问节点 A,而节点 B 是 A 的备库,只是将 A 的更新都同步过来,到本地执行.这样可以保持节点 B 和 A 的

  • Redis如何使用乐观锁(CAS)保证数据一致性

    目录 场景 问题模拟 CAS 来保证数据一致性 场景 在 Redis 中经常会存在这么一种情况,读取某一个 key 的值,做一些业务逻辑处理,然后根据读取到的值来计算出一个新的值,重新 set 进去. 如果客户端 A 刚读取到 key 值,紧接着客户端 B 就修改这个 key 的值,那么就会存在并发安全的问题. 问题模拟 假设 Redis Server 有个键名为 test 的key,里面存放的是一个 json 数组 [1, 2, 3]. 下面让我们模拟一下,客户端 A 与 客户端 B 同时访问

  • mysql备份与恢复详解

    MYSQL的备份有多少种,请简要的描述:数据库分逻辑备份\物理备份物理备份又分冷备和热备 A.直接拷贝数据文件到安全地方进行保存B.使用MYSQLHOSTCOPY备分数据C.使用MYSQLDUMP备份数据D.使用MYSQL的同步复制,实现数据实时数据同步备份 常用的逻辑备份主要就是两种:一种是将数据生成为可以完全重现当前数据库中的数据的insert语句,另一种是将数据通过逻辑备份软件,将数据库表的数据以特定分隔符进行分割后记录在文本中. 对于第一种生成insert语句来说我们可以直接使用mysq

随机推荐