基于innobakcupex跨实例不完全恢复步骤

   MySQL在基于热备的基础上,可以实现对原有实例的完全或不完全恢复。而很多时候,原有实例部署了DRBD或者MHA等,在这种情况下,基于原有实例进行恢复会影响原有的故障现场及架构,可以通过跨实例恢复来恢复丢失或异常数据。同时跨实例恢复也可以实现基于整个实例进行实例级别数据库迁移。下文演示了基于跨实例的不完全恢复。

 

1、主要步骤
a、准备新实例
b、基于热备做prepare及recover
c、复制完整的备份到新实例(如果跨主机应复制到新主机)
d、启动新实例
e、根据需要恢复binlog到故障点
f、验证结果

 

2、演示跨实例不完全恢复

-- 说明:以下演示在同一主机上完成
-- 源实例端口及数据文件路径:3306 /data/mysqldata
-- 新实例端口及数据文件路径:3307 /data/recoverdata
a、准备新实例
-- 创建新实例数据路径
SHELL# mkdir -p /data/recoverdata     

-- 初始化新实例
SHELL# cp /etc/my.cnf /etc/my3307.cnf
SHELL# vi /etc/my3307.cnf             --修改相关配置选项,路径,端口号,servier_id等等
SHELL# /app/soft/mysql/scripts/mysql_install_db --user=mysql --ldata=/data/recoverdata --basedir=/app/soft/mysql \
> --defaults-file=/etc/my3307.cnf

SHELL# /app/soft/mysql/bin/mysqld_safe --defaults-file=/etc/my3307.cnf &
SHELL# /app/soft/mysql/bin/mysqladmin -u root password '***' -P3307 -S /tmp/mysql3307.sock
SHELL# /app/soft/mysql/bin/mysqladmin -uroot -p*** -P3307 -S /tmp/mysql3307.sock shutdown

b、基于热备做prepare及recover
--当前的备份情况为:
--20150128 全备,20150129 增备,20150130 增备,20150131 增备,备份时间为每天3点
--需要恢复到2015-01-31 23:53:54
--备份路径如下:
SHELL# pwd
/backup/hotbak/physical/20150128
SHELL# ls
base_20150128  inc_20150129  inc_20150130  inc_20150131

--prepare 全备
SHELL# innobackupex --apply-log --redo-only --user=root --password=*** --port=3307 \
--socket=/tmp/mysql3307.sock --defaults-file=/etc/my3307.cnf /backup/hotbak/physical/20150128/base_20150128

--prepare 增备
SHELL# innobackupex --apply-log --redo-only --user=root --password=*** --port=3307 \
--socket=/tmp/mysql3307.sock --defaults-file=/etc/my3307.cnf /backup/hotbak/physical/20150128/base_20150128 \
--incremental-dir=/backup/hotbak/physical/20150128/inc_20150129

--prepare 增备
SHELL# innobackupex --apply-log --redo-only --user=root --password=*** --port=3307 \
--socket=/tmp/mysql3307.sock --defaults-file=/etc/my3307.cnf /backup/hotbak/physical/20150128/base_20150128 \
--incremental-dir=/backup/hotbak/physical/20150128/inc_20150130

--prepare 增备,注意,最后一次不需要使用--redo-only选项,未提交的事务将回滚
SHELL# innobackupex --apply-log --user=root --password=*** --port=3307 --socket=/tmp/mysql3307.sock \
--defaults-file=/etc/my3307.cnf /backup/hotbak/physical/20150128/base_20150128 \
--incremental-dir=/backup/hotbak/physical/20150128/inc_20150131

c、复制完整的备份到新实例
SHELL# cp -R /backup/hotbak/physical/20150128/base_20150128/* /data/recoverdata
SHELL# chown mysql:mysql -R /data/recoverdata

# Author : Leshami
# Blog   : http://blog.csdn.net/leshami

d、启动新实例
-- 启动新实例并验证完整性
SHELL# /app/soft/mysql/bin/mysqld_safe --defaults-file=/etc/my3307.cnf &

e、根据需要恢复binlog到故障点
--假定我们需要恢复到2015-01-31 23:53:54,则需要提取binlog来进行不完全恢复。
--获取热备最后的binlog日志及位置
SHELL# more /backup/hotbak/physical/20150128/inc_20150131/xtrabackup_binlog_info
mysql-bin.000036        100130712
SHELL# mysqlbinlog /data/mysqldata/mysql-bin.000036 --start-position=100130712 --stop-datetime="2015-01-31 23:53:54" \
> |mysql -uroot -p*** -P3307 -S /tmp/mysql3307.sock

f、验证结果
mysql> select * from test.heartbeat;
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+
| ts                         | server_id | file             | position  | relay_master_log_file | exec_master_log_pos |
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+
| 2015-01-31T23:53:53.001690 |        11 | mysql-bin.000459 | 703735593 | NULL                  |                NULL |
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+
时间: 2024-10-29 17:08:17

基于innobakcupex跨实例不完全恢复步骤的相关文章

Oracle 基于用户管理的不完全恢复

    Oracle 数据恢复从恢复类型来说,抛开具体的文件,总共可分为两大类型的恢复,一是完全恢复,一个是不完全恢复.其实,熟悉了Oracle体系结构之后,对于Oracle恢复就会有一个总体的概念.因为Oracle组成的外围部分,主要由不同的文件来组成,每种不同类型的文件有不同的作用,因此只要了解了其作用,更利于了解与掌握Oralce数据库的备份与恢复.言归正传,完全恢复即是把数据库恢复到最新的SCN,出故障前的那一刻,是无损恢复.而不完全恢复即是有损恢复,多用于恢复用户误操作,归档日志丢失等

Oracle基于用户管理的不完全恢复(一)不完全恢复的特性

Oracle 数据恢复从恢复类型来说,抛开具体的文件,总共可分为两大类型的恢复,一是完全恢复,一个是不完全恢复.其实,熟悉了Oracle体系结构之后,对于 Oracle恢复就会有一个总体的概念.因为Oracle组成的外围部分,主要由不同的文件来组成,每种不同类型的文件有不同的作用,因此只要了解了其作 用,更利于了解与掌握Oralce数据库的备份与恢复.言归正传,完全恢复即是把数据库恢复到最新的SCN,出故障前的那一刻,是无损恢复.而不完全恢复即是有损恢复,多用于恢复用户误操作,归档日志丢失等情形

Oracle基于用户管理的不完全恢复

Oracle 数据恢复从恢复类型来说,抛开具体的文件,总共可分为两大类型的恢复,一是完全恢复,一个是不完全恢复.其实,熟悉了Oracle体系结构之后,对于Oracle恢复就会有一个总体的概念.因为Oracle组成的外围部分,主要由不同的文件来组成,每种不同类型的文件有不同的作用,因此只要了解了其作用,更利于了解与掌握Oralce数据库的备份与恢复.言归正传,完全恢复即是把数据库恢复到最新的SCN,出故障前的那一刻,是无损恢复.而不完全恢复即是有损恢复,多用于恢复用户误操作,归档日志丢失等情形.本

使用FREDATED引擎实现跨实例访问

    跨数据库服务器,跨实例访问是比较常见的一种访问方式,在Oracle中可以通过DB LINK的方式来实现.对于MySQL而言,有一个FEDERATED存储引擎与之相对应.同样也是通过创建一个链接方式的形式来访问远程服务器上的数据.本文简要描述了FEDERATED存储引擎,以及演示了基于FEDERATED存储引擎跨实例访问的示例.   1.FEDERATED存储引擎的描述  FEDERATED存储引擎允许在不使用复制或集群技术的情况下实现远程访问数据库  创建基于FEDERATED存储引擎表

MySQL中使用FREDATED引擎实现跨数据库服务器、跨实例访问_Mysql

跨数据库服务器,跨实例访问是比较常见的一种访问方式,在Oracle中可以通过DB LINK的方式来实现.对于MySQL而言,有一个FEDERATED存储引擎与之相对应.同样也是通过创建一个链接方式的形式来访问远程服务器上的数据.本文简要描述了FEDERATED存储引擎,以及演示了基于FEDERATED存储引擎跨实例访问的示例. 1.FEDERATED存储引擎的描述   FEDERATED存储引擎允许在不使用复制或集群技术的情况下实现远程访问数据库   创建基于FEDERATED存储引擎表的时候,

浅析用FREDATED引擎实现MySQL跨实例跨数据库服务器查询教程

1.FEDERATED存储引擎的描述 FEDERATED存储引擎允许在不使用复制或集群技术的情况下实现远程访问数据库 创建基于FEDERATED存储引擎表的时候,服务器在数据库目录仅创建一个表定义文件,即以表名开头的.frm文件. FEDERATED存储引擎表无任何数据存储到本地,即没有.myd文件 对于远程服务器上表的操作与本地表操作一样,仅仅是数据位于远程服务器 基本流程如下: 2.安装与启用FEDERATED存储引擎 源码安装MySQL时使用DWITH_FEDERATED_STORAGE_

Oracle基于用户管理的不完全恢复(五)误删除表空间

案例4--误删除表空间(有备份) 通过备份的控制文件找到与表空间有关的信息进行恢复,因为新的控制文件里面已经没有该表空间的信息了.实际上在整个恢复过程中还是利用归档日志进行恢复,如果删除表空间之前的操作有及时写入到归档信息,就会全部恢复出来.下面的案例分切换日志和不切换日志两种. 1.基于backup control 的不完全恢复 SQL> select file_id,file_name,tablespace_name from dba_data_files; FILE_ID FILE_NAM

oracle基于时间点的不完全恢复

下面我们做一个实验,演示如何对oracle进行基于时间点的不完全恢复(在实验之前请确保数据库具有有效备份): 获取此时的时间并记录下来: SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual; TO_CHAR(SYSDATE,'YY -------------------2014-08-23 00:47:49 把hh用户下的h2删除: SQL> drop table h2; Table dropped. 使用rman将数据

基于时间点的不完全恢复的例子

说到不完全恢复,一般有三种场景,基于时间点的不完全恢复,基于scn的不完全恢复,基于cancel的不完全恢复. 三种情况都是不完全恢复采用的方式,而不完全恢复都是在完全恢复的过程中出现了这样那样的错误,数不胜数,基本就是归档,redo损坏丢失,控制文件丢失,备份的问题,手工失误等等. 我们可以举一个不完全恢复的案例,其实在实际操作的过程中还是有一些值得总结和学习的地方. 第一步准备基本的数据.目前我们可以看到在表空间data上只有一个表new_recover SQL> select owner,