• 关于

    Xtra

    的搜索结果

问题

求助!官网提供的解压缩工具不可用报错!

root@84a47a1b67e1:/root/backup >>> ls ...
德本 2019-12-01 19:44:35 1445 浏览量 回答数 1

问题

RDS的备份文件是tar.gz格式,怎么查看时只有一个文件

[root@ct-test1 test]# tar tvf hins104343_xtra_20140313103105.tar.gz -rw-r--r-- root/root       264 2014-03-13 10:31...
migu 2019-12-01 21:43:40 6815 浏览量 回答数 2

问题

RDS Mysql数据恢复失败,无法解压啊

已阅读过《 RDS 备份文件恢复到 自 建 数据库 》。 但实施过程中出现如下 问题 : 执行命令: sh /database/tools/rds_backup_extract.sh -f /database/d...
konsoar 2019-12-01 21:42:16 1529 浏览量 回答数 1

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

建个炫酷的简历网页,制作一个浪漫的表白网页,打造个人专属网盘,多种动手场景应用免费学!!!

回答

(1)备份计划 视库的大小来定,一般来说 100G 内的库,可以考虑使用 mysqldump 来做,因为 mysqldump更加轻巧灵活,备份时间选在业务低峰期,可以每天进行都进行全量备份(mysqldump 备份出来的文件比较小,压缩之后更小)。 100G 以上的库,可以考虑用 xtranbackup 来做,备份速度明显要比 mysqldump 要快。一般是选择一周一个全备,其余每天进行增量备份,备份时间为业务低峰期。 (2)备份恢复时间 物理备份恢复快,逻辑备份恢复慢 这里跟机器,尤其是硬盘的速率有关系,以下列举几个仅供参考 20G的2分钟(mysqldump) 80G的30分钟(mysqldump) 111G的30分钟(mysqldump) 288G的3小时(xtra) 3T的4小时(xtra) 逻辑导入时间一般是备份时间的5倍以上 (3)备份恢复失败如何处理 首先在恢复之前就应该做足准备工作,避免恢复的时候出错。比如说备份之后的有效性检查、权限检查、空间检查等。如果万一报错,再根据报错的提示来进行相应的调整。 (4)mysqldump和xtrabackup实现原理 mysqldump mysqldump 属于逻辑备份。加入–single-transaction 选项可以进行一致性备份。后台进程会先设置 session 的事务隔离级别为 RR(SET SESSION TRANSACTION ISOLATION LEVELREPEATABLE READ),之后显式开启一个事务(START TRANSACTION /*!40100 WITH CONSISTENTSNAPSHOT */),这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上–master-data=1 的话,在刚开始的时候还会加一个数据库的读锁(FLUSH TABLES WITH READ LOCK),等开启事务后,再记录下数据库此时 binlog 的位置(showmaster status),马上解锁,再读取表的数据。等所有的数据都已经导完,就可以结束事务 Xtrabackup: xtrabackup 属于物理备份,直接拷贝表空间文件,同时不断扫描产生的 redo 日志并保存下来。最后完成 innodb 的备份后,会做一个 flush engine logs 的操作(老版本在有 bug,在5.6 上不做此操作会丢数据),确保所有的 redo log 都已经落盘(涉及到事务的两阶段提交 概念,因为 xtrabackup 并不拷贝 binlog,所以必须保证所有的 redo log 都落盘,否则可能会丢最后一组提交事务的数据)。这个时间点就是 innodb 完成备份的时间点,数据文件虽然不是一致性的,但是有这段时间的 redo 就可以让数据文件达到一致性(恢复的时候做的事 情)。然后还需要 flush tables with read lock,把 myisam 等其他引擎的表给备份出来,备份完后解锁。这样就做到了完美的热备。
剑曼红尘 2020-03-31 11:38:33 0 浏览量 回答数 0

问题

AliOS开发者FAQ

Common 1. Q: AliOS Lite有自己的SeLinux做法,能否提供详细guideline?Ali是否会提供相关转换脚本?    A: 待补充 2. Q: AliOS...
hanfeng10 2019-12-01 21:00:29 2308 浏览量 回答数 0

回答

直接恢复是使用备份文件做全量恢复,这是最常见的场景 2.1.mysqldump备份全量恢复 使用 mysqldump 文件恢复数据非常简单,直接解压了执行 gzip -d backup.sql.gz | mysql -u -h -P -p 2.2.xtrabackup备份全量恢复 恢复过程 步骤一:解压(如果没有压缩可以忽略这一步) innobackupex --decompress <备份文件所在目录> 步骤二:应用日志 innobackupex --apply-log <备份文件所在目录> 步骤三:复制备份文件到数据目录 innobackupex --datadir=<MySQL数据目录> --copy-back <备份文件所在目录> 2.3.基于时间点恢复 基于时间点的恢复依赖的是binlog日志,需要从 binlog 中找过从备份点到恢复点的所有日志,然后应用,我们测试一下 新建测试表 chengqm-3306>>show create table mytest.mytest \G; *************************** 1. row *************************** Table: mytest Create Table: CREATE TABLE mytest ( id int(11) NOT NULL AUTO_INCREMENT, ctime datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 每秒插入一条数据 [mysql@mysql-test ~]$ while true; do mysql -S /tmp/mysql.sock -e 'insert into mytest.mytest(ctime)values(now())';date;sleep 1;done 备份 [mysql@mysql-test ~]$ mysqldump --opt --single-transaction --master-data=2 --default-character-set=utf8 -S /tmp/mysql.sock -A > backup.sql 找出备份时的日志位置 [mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000032', MASTER_LOG_POS=39654; 假设要恢复到 2019-08-09 11:01:54 这个时间点,我们从 binlog 中查找从 39654 到 019-08-09 11:01:54 的日志 [mysql@mysql-test ~]$ mysqlbinlog --start-position=39654 --stop-datetime='2019-08-09 11:01:54' /data/mysql_log/mysql_test/mysql-bin.000032 > backup_inc.sql [mysql@mysql-test-83 ~]$ tail -n 20 backup_inc.sql ...... INSERT INTO mytest.mytest SET @1=161 /* INT meta=0 nullable=0 is_null=0 */ @2='2019-08-09 11:01:53' /* DATETIME(0) meta=0 nullable=1 is_null=0 */ ...... 当前数据条数 -- 2019-08-09 11:01:54之前的数据条数 chengqm-3306>>select count() from mytest.mytest where ctime < '2019-08-09 11:01:54'; +----------+ | count() | +----------+ | 161 | +----------+ 1 row in set (0.00 sec) -- 所有数据条数 chengqm-3306>>select count() from mytest.mytest; +----------+ | count() | +----------+ | 180 | +----------+ 1 row in set (0.00 sec) 然后执行恢复 全量恢复 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql 应用增量日志 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc.sql 检查数据 chengqm-3306>>select count() from mytest.mytest; +----------+ | count() | +----------+ | 161 | +----------+ 1 row in set (0.00 sec) chengqm-3306>>select * from mytest.mytest order by id desc limit 5; +-----+---------------------+ | id | ctime | +-----+---------------------+ | 161 | 2019-08-09 11:01:53 | | 160 | 2019-08-09 11:01:52 | | 159 | 2019-08-09 11:01:51 | | 158 | 2019-08-09 11:01:50 | | 157 | 2019-08-09 11:01:49 | +-----+---------------------+ 5 rows in set (0.00 sec) 已经恢复到 2019-08-09 11:01:54 这个时间点 3.恢复一个表 3.1.从mysqldump备份恢复一个表 假设要恢复的表是 mytest.mytest 提取某个库的所有数据 sed -n '/^-- Current Database: mytest/,/^-- Current Database:/p' backup.sql > backup_mytest.sql 从库备份文件中提取建表语句 sed -e'/./{H;$!d;}' -e 'x;/CREATE TABLE mytest/!d;q' backup_mytest.sql > mytest_table_create.sql 从库备份文件中提取插入数据语句 grep -i 'INSERT INTO mytest' backup_mytest.sql > mytest_table_insert.sql 恢复表结构到 mytest 库 mysql -u -p mytest < mytest_table_create.sql 恢复表数据到 mytest.mytest 表 mysql -u -p mytest < mytest_table_insert.sql 3.2.从xtrabackup备份恢复一个表 假设 ./backup_xtra_full 目录为解压后应用过日志的备份文件 3.2.1 MyISAM 表 假设从备份文件中恢复表 mytest.t_myisam,从备份文件中找到 t_myisam.frm t_myisam.MYD t_myisam.MYI 这 3 个文件,复制到对应的数据目录中,并授权。 进入 MySQL,检查表情况 chengqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | mytest | | t_myisam | +------------------+ 2 rows in set (0.00 sec) chengqm-3306>>check table t_myisam; +-----------------+-------+----------+----------+ | Table | Op | Msg_type | Msg_text | +-----------------+-------+----------+----------+ | mytest.t_myisam | check | status | OK | +-----------------+-------+----------+----------+ 1 row in set (0.00 sec) 3.2.2.Innodb 表 假设从备份文件中恢复表 mytest.t_innodb,恢复前提是设置了 innodb_file_per_table = on 起一个新实例 在实例上建一个和原来一模一样的表 执行 alter table t_innodb discard tablespace;,删除表空间,这个操作会把 t_innodb.ibd 删除 从备份文件中找到 t_innodb.ibd 这个文件,复制到对应的数据目录,并授权 执行 alter table t_innodb IMPORT tablespace; 加载表空间 执行 flush table t_innodb;check table t_innodb; 检查表 使用 mysqldump 导出数据,然后再导入到要恢复的数据库 注意: 在新实例上恢复再dump出来是为了避免风险,如果是测试,可以直接在原库上操作步骤 2-6 只在 8.0 以前的版本有效 4.跳过误操作SQL 跳过误操作 SQL 一般用于执行了无法闪回的操作比如 drop table\database 4.1.使用备份文件恢复跳过 4.1.1.不开启 GTID 使用备份文件恢复的步骤和基于时间点恢复的操作差不多,区别在于多一个查找 binlog 操作 举个例子,我这里建立了两个表 a 和 b,每分钟插入一条数据,然后做全量备份,再删除表 b,现在要跳过这条 SQL。 删除表 b 后的数据库状态 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | +------------------+ 1 row in set (0.00 sec) 1 找出备份时的日志位置 [mysql@mysql-test ~]$ head -n 25 backup.sql | grep 'CHANGE MASTER TO MASTER_LOG_FILE' -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000034', MASTER_LOG_POS=38414; 2 找出执行了 drop table 语句的 pos 位置 [mysql@mysql-test mysql_test]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000034 | grep -i -B 3 'drop table b'; at 120629 #190818 19:48:30 server id 83 end_log_pos 120747 CRC32 0x6dd6ab2a Query thread_id=29488 exec_time=0 error_code=0 SET TIMESTAMP=1566128910/!/; DROP TABLE b /* generated by server */ 从结果中我们可以看到 drop 所在语句的开始位置是 120629,结束位置是 120747 3 从 binglog 中提取跳过这条语句的其他记录 第一条的 start-position 为备份文件的 pos 位置,stop-position 为 drop 语句的开始位置 mysqlbinlog -vv --start-position=38414 --stop-position=120629 /data/mysql_log/mysql_test/mysql-bin.000034 > backup_inc_1.sql 第二条的 start-position 为 drop 语句的结束位置 mysqlbinlog -vv --start-position=120747 /data/mysql_log/mysql_test/mysql-bin.000034 > backup_inc_2.sql 4 恢复备份文件 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup.sql 全量恢复后状态 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) chgnqm-3306>>select count() from a; +----------+ | count() | +----------+ | 71 | +----------+ 1 row in set (0.00 sec) 5 恢复增量数据 [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_1.sql [mysql@mysql-test ~]$ mysql -S /tmp/mysql.sock < backup_inc_2.sql 恢复后状态,可以看到已经跳过了 drop 语句 chgnqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) chgnqm-3306>>select count() from a; +----------+ | count() | +----------+ | 274 | +----------+ 1 row in set (0.00 sec) 4.1.2 开启 GTID 使用 GTID 可以直接跳过错误的 SQL 1.找出备份时的日志位置 2.找出执行了 drop table 语句的 GTID 值 3.导出备份时日志位置到最新的 binglog 日志 4.恢复备份文件 5.跳过这个 GTID SET SESSION GTID_NEXT='对应的 GTID 值'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; 6.应用步骤 3 得到的增量 binlog 日志 4.2 使用延迟库跳过 4.2.1 不开启 GTID 使用延迟库恢复的关键操作在于 start slave until 我在测试环境搭建了两个 MySQL 节点,节点二延迟600秒,新建 a,b 两个表,每秒插入一条数据模拟业务数据插入。 localhost:3306 -> localhost:3307(delay 600) 当前节点二状态 chengqm-3307>>show slave status \G; ... Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000039 Read_Master_Log_Pos: 15524 Relay_Log_File: mysql-relay-bin.000002 Relay_Log_Pos: 22845 Relay_Master_Log_File: mysql-bin.000038 Slave_IO_Running: Yes Slave_SQL_Running: Yes ... Seconds_Behind_Master: 600 ... 当前节点二表 chengqm-3307>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 在节点一删除表 b chengqm-3306>>drop table b; Query OK, 0 rows affected (0.00 sec) chengqm-3306>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | +------------------+ 1 row in set (0.00 sec) 接下来就是跳过这条 SQL 的操作步骤 1 延迟库停止同步 stop slave; 2 找出执行了 drop table 语句的前一句的 pos 位置 [mysql@mysql-test ~]$ mysqlbinlog -vv /data/mysql_log/mysql_test/mysql-bin.000039 | grep -i -B 10 'drop table b'; ... at 35134 #190819 11:40:25 server id 83 end_log_pos 35199 CRC32 0x02771167 Anonymous_GTID last_committed=132 sequence_number=133 rbr_only=no SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/!/; at 35199 #190819 11:40:25 server id 83 end_log_pos 35317 CRC32 0x50a018aa Query thread_id=37155 exec_time=0 error_code=0 use mytest/!/; SET TIMESTAMP=1566186025/!/; DROP TABLE b /* generated by server */ 从结果中我们可以看到 drop 所在语句的前一句开始位置是 35134,所以我们同步到 35134 (这个可别选错了) 3 延迟库同步到要跳过的 SQL 前一条 change master to master_delay=0; start slave until master_log_file='mysql-bin.000039',master_log_pos=35134; 查看状态看到已经同步到对应节点 chengqm-3307>>show slave status \G; ... Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000039 Read_Master_Log_Pos: 65792 ... Slave_IO_Running: Yes Slave_SQL_Running: No Exec_Master_Log_Pos: 35134 ... Until_Log_File: mysql-bin.000039 Until_Log_Pos: 35134 4 跳过一条 SQL 后开始同步 set global sql_slave_skip_counter=1; start slave; 查看同步状态,删除表 b 的语句已经被跳过 chengqm-3307>>show slave status \G; ... Slave_IO_Running: Yes Slave_SQL_Running: Yes ... 1 row in set (0.00 sec) chengqm-3307>>show tables; +------------------+ | Tables_in_mytest | +------------------+ | a | | b | +------------------+ 2 rows in set (0.00 sec) 4.2.2 开启 GTID 使用 GTID 跳过的步骤会简单很多,只要执行一条和要跳过的 SQL 的 GTID 相同的事务就可以跳过了 1.停止同步 2.找出执行了 drop table 语句的 GTID 3.执行这个 GTID 的事务 SET SESSION GTID_NEXT='对应的 GTID 值'; BEGIN; COMMIT; SET SESSION GTID_NEXT = AUTOMATIC; 4.继续同步 5.闪回 闪回操作就是反向操作,比如执行了 delete from a where id=1,闪回就会执行对应的插入操作 insert into a (id,…) values(1,…),用于误操作数据,只对 DML 语句有效,且要求 binlog 格式设为 ROW。本章介绍两个比较好用的开源工具 5.1.binlog2sql binlog2sql 是大众点评开源的一款用于解析 binlog 的工具,可以用于生成闪回语句,项目地址 binlog2sql 5.1.1.安装 wget https://github.com/danfengcao/binlog2sql/archive/master.zip -O binlog2sql.zip unzip binlog2sql.zip cd binlog2sql-master/ 安装依赖 pip install -r requirements.txt 5.1.2 生成回滚SQL python binlog2sql/binlog2sql.py --flashback -h -P -u -p' ' -d -t<table_name> --start-file='<binlog_file>' --start-datetime='<start_time>' --stop-datetime='<stop_time>' > ./flashback.sql python binlog2sql/binlog2sql.py --flashback -h -P -u -p' ' -d -t<table_name> --start-file='<binlog_file>' --start-position=<start_pos> --stop-position=<stop_pos> > ./flashback.sql 5.2 MyFlash MyFlash 是由美团点评公司技术工程部开发维护的一个回滚 DML 操作的工具,项目链接 MyFlash 限制: binlog格式必须为row,且 binlog_row_image=full 仅支持5.6与5.7 只能回滚DML(增、删、改) 5.2.1 安装 依赖(centos) yum install gcc* pkg-config glib2 libgnomeui-devel -y 下载文件 wget https://github.com/Meituan-Dianping/MyFlash/archive/master.zip -O MyFlash.zip unzip MyFlash.zip cd MyFlash-master 编译安装 gcc -w pkg-config --cflags --libs glib-2.0 source/binlogParseGlib.c -o binary/flashback mv binary /usr/local/MyFlash ln -s /usr/local/MyFlash/flashback /usr/bin/flashback 5.2.2 使用 生成回滚语句 flashback --databaseNames= --binlogFileNames=<binlog_file> --start-position=<start_pos> --stop-position=<stop_pos> 执行后会生成 binlog_output_base.flashback 文件,需要用 mysqlbinlog 解析出来再使用
游客2q7uranxketok 2021-02-24 11:16:00 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT