mysql 基于时间点恢复

         MySQL基于时间点恢复(PITR)

   MySQL的PITR主要是通过mysqldump来做全备,然后通过log-bin来恢复到某个时间点,达到PITR的目的

确认log_bin是否打开
mysql> show global variables like 'log_bin';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
1 row in set (0.00 sec)

当前frank数据中有表t1
mysql> use frank;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-----------------+
| Tables_in_frank |
+-----------------+
| t1              |
+-----------------+
1 row in set (0.00 sec)
在时间点a做备份frank数据库
[root@c12 data]# mysqldump -u root -p --protocol tcp --host  127.0.0.1 --port 3306 --flush-logs --databases frank >frank.sql
Enter password: 

在时间点b 创建表frank.t2

mysql> create table t2 (a int);
Query OK, 0 rows affected (0.00 sec)
mysql> insert into t2 values(10);
Query OK, 1 row affected (0.02 sec)
mysql> commit;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from t2;
+------+
| a    |
+------+
|   10 |
+------+
1 row in set (0.00 sec)

在时间点c删除表t1

mysql> drop table t1;
Query OK, 0 rows affected (0.05 sec)
mysql> drop table t2;
Query OK, 0 rows affected (0.01 sec)

要求恢复到时间点b(存在表t1和t2)
1,先恢复全库.
[root@c12 ~]# mysql -u frank -p -h 127.0.0.1 --port 3306 </usr/local/mysql/data/frank.sql 
Enter password: 

mysql> show tables;
+-----------------+
| Tables_in_frank |
+-----------------+
| t1              |
+-----------------+
1 row in set (0.00 sec)

2,挖掘log-bin日志
[root@c12 data]# mysqlbinlog --start-datetime='2013-12-29  6:25:16' --stop-datetime='2013-12-29  6:34:01' abc.* >recovery.sql
3,重执行sql。
[root@c12 ~]# mysql -u root -p -h 127.0.0.1 --port 3306 </usr/local/mysql/data/recovery.sql 
Enter password: 
mysql> use frank;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-----------------+
| Tables_in_frank |
+-----------------+
| t1              |
| t2              |
+-----------------+
2 rows in set (0.00 sec)
mysql> select * from t2;
+------+
| a    |
+------+
|   10 |
+------+
1 row in set (0.01 sec)
检查数据已经被恢复出来了.

start-datetime='2013-12-29  6:25:16'  可以过通sql dump文件中最后一行得到备份的结束时间
stop-datetime='2013-12-29  6:34:01'  通过mysqlbinlog发掘后,产生drop之前的时间点得到
主要的不足:mysqldump本身比较慢;PITR是恢复了整个库,影响比较大,通过查找也可以恢复单个表。




mysqlbinlog --start-datetime='2015-09-14  18:00:00' --stop-datetime='2015-09-24  18:00:01' mysql-bin.* >a1.sql

#150914 18:00:00 server id 135  end_log_pos 34205812 CRC32 0x4d4361a2   Query   thread_id=235503        exec_time=0     error_code=0
SET TIMESTAMP=1442224800/*!*/;
SET @@session.pseudo_thread_id=235503/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 34205812
#150914 18:00:00 server id 135  end_log_pos 34206205 CRC32 0x79a69dd2   Query   thread_id=235503        exec_time=0     error_code=0
use `quartz`/*!*/;
SET TIMESTAMP=1442224800/*!*/;
UPDATE QRTZ_FIRED_TRIGGERS SET INSTANCE_NAME = 'auto', FIRED_TIME = 1442224800003, SCHED_TIME = 1442224800000, STATE = 'EXECUTING', JOB_NAME = 'QueryRechargeJob', JOB_GROUP = 'zjzcOrderQuery', 

IS_NONCONCURRENT = 0, REQUESTS_RECOVERY = 0 WHERE SCHED_NAME = 'ReportControlScheduler' AND ENTRY_ID = 'auto1442195950054'




/*!*/;
# at 494166947
#150924 18:00:00 server id 135  end_log_pos 494167135 CRC32 0x3ded5067  Query   thread_id=410262        exec_time=0     error_code=0
SET TIMESTAMP=1443088800/*!*/;
DELETE FROM QRTZ_FIRED_TRIGGERS WHERE SCHED_NAME = 'ReportControlScheduler' AND ENTRY_ID = 'auto1442887716722'
/*!*/;
# at 494167135
#150924 18:00:00 server id 135  end_log_pos 494167166 CRC32 0xa44d66f4  Xid = 24146772

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
MySQL数据迁移和备份恢复策略是确保数据安全和可靠性的重要措施。下面是一些常用的策略: 1. 数据迁移策略: - 导出和导入:使用`mysqldump`命令将源数据库导出为SQL文件,然后使用`mysql`命令将SQL文件导入到目标数据库。 - 复制和同步:通过MySQL复制功能,将数据从源数据库复制到目标数据库,实现实时或定期的数据同步。 - 第三方工具:使用一些数据库迁移工具(如DMS、Liquibase等),可以更方便地进行数据迁移和同步。 2. 数据备份策略: - 定期全量备份:定期对整个数据库进行全量备份,以保留完整的数据副本。 - 增量备份:基于全量备份,通过记录增量日志或使用MySQL的二进制日志(Binary Log)进行增量备份,以减少备份时间和存储空间。 - 热备份:使用MySQL的在线备份工具(如Percona XtraBackup、MySQL Enterprise Backup等),可以在数据库运行时进行备份,减少对业务的影响。 3. 数据恢复策略: - 全量恢复:将全量备份文件还原到目标数据库,恢复所有数据。 - 增量恢复:先恢复全量备份,再将增量备份文件依次应用到目标数据库,实现数据的增量恢复。 - 恢复:基于二进制日志(Binary Log)或增量备份,可以选择在特定时间进行数据恢复,以满足特定需求。 4. 测试和验证: - 定期进行备份验证:定期恢复备份数据到测试环境,验证备份的完整性和可用性。 - 模拟灾难恢复:模拟灾难事件,测试数据恢复过程,确保备份和恢复策略的可行性和有效性。 无论是数据迁移还是备份恢复,都需要注意以下几: - 定期执行:根据业务需求和数据变更频率,制定合理的执行计划,确保数据的及时备份和迁移。 - 存储安全:将备份数据存储在安全可靠的位置,以免遭受意外损坏或安全威胁。 - 监控和报警:对迁移和备份过程进行监控,并设置相应的报警机制,及时发现和解决潜在问题。 请注意,具体的迁移和备份恢复策略应根据业务需求、数据量和可用资源进行定制。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

scan724

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值