- 浏览: 154705 次
- 性别:
- 来自: 南京
文章分类
最新评论
-
di1984HIT:
不错啊,哈哈。
Memcached最大连接数 -
di1984HIT:
写的不错啊。
vsftp的时区问题 -
langren:
能分享一下这个问题是怎么解决的吗?
MySQL Innodb存储引擎因为缓存配置出现的错误 -
wangzheguilai:
哥们,您太强大了,百度了好久之后才看到你的这个,终于我把问题给 ...
迁移数据库时因Innodb的日志文件大小配置不同导致的问题 -
dailingang:
我的遇到的情况是 在firefox下测试正常,在ie6下怎么都 ...
Nginx的perl模块开发
引用
tar ixvf database_sns_201110290358.tar.gz -C database_sns_201110290358
引用
[root@test3 byread]# PATH=$PATH:/byread/bin/mysql/bin
引用
[root@test3 byread]# /byread/bin/mysql/bin/innobackupex-1.5.1 --defaults-file=/byread/bin/mysql/etc/my.cnf --apply-log --user=root --password=password /byread/backup/database_sns_201110290358
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackupex-1.5.1
prints "completed OK!".
111129 13:02:23 innobackupex-1.5.1: Starting ibbackup with command: xtrabackup --defaults-file="/byread/bin/mysql/etc/my.cnf" --prepare --target-dir=/byread/backup/database_sns_201110290358
xtrabackup Ver 1.2 Rev undefined for 5.1.45 unknown-linux-gnu (x86_64)
xtrabackup: cd to /byread/backup/database_sns_201110290358
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=15679488, start_lsn=(439451291573)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 15679488
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
111129 13:02:23 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 439451291573
111129 13:02:23 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 439456534016 (37 %)
InnoDB: Doing recovery: scanned up to log sequence number 439461776896 (75 %)
InnoDB: Doing recovery: scanned up to log sequence number 439465227876 (100 %)
111129 13:02:30 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 842538513, file name ./mysql-bin.000145
111129 13:02:50 InnoDB Plugin 1.0.6-unknown started; log sequence number 439465227876
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 842538513, file name ./mysql-bin.000145
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
111129 13:03:05 InnoDB: Starting shutdown...
111129 13:03:06 InnoDB: Shutdown completed; log sequence number 439465237786
111129 13:03:06 innobackupex-1.5.1: Restarting xtrabackup with command: xtrabackup --defaults-file="/byread/bin/mysql/etc/my.cnf" --prepare --target-dir=/byread/backup/database_sns_201110290358
for creating ib_logfile*
xtrabackup Ver 1.2 Rev undefined for 5.1.45 unknown-linux-gnu (x86_64)
xtrabackup: cd to /byread/backup/database_sns_201110290358
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 3
xtrabackup: innodb_log_file_size = 268435456
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Warning: innodb_file_io_threads is deprecated. Please use innodb_read_io_threads and innodb_write_io_threads instead
111129 13:03:06 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 256 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
111129 13:03:09 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 256 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
111129 13:03:12 InnoDB: Log file ./ib_logfile2 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile2 size to 256 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100 200
111129 13:03:16 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
111129 13:03:16 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Last MySQL binlog file position 0 842538513, file name ./mysql-bin.000145
111129 13:03:16 InnoDB Plugin 1.0.6-unknown started; log sequence number 439465238028
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 842538513, file name ./mysql-bin.000145
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
111129 13:03:20 InnoDB: Starting shutdown...
111129 13:03:21 InnoDB: Shutdown completed; log sequence number 439465238038
111129 13:03:21 innobackupex-1.5.1: completed OK!
引用
[root@test3 byread]# /byread/bin/mysql/bin/innobackupex-1.5.1 --defaults-file=/byread/bin/mysql/etc/my.cnf --copy-back --user=root --password=password /byread/backup/database_sns_201110290358
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackupex-1.5.1
prints "completed OK!".
innobackupex-1.5.1: Starting to copy MyISAM tables, indexes,
innobackupex-1.5.1: .MRG, .TRG, .TRN, .ARM, .ARZ, .opt, and .frm files
innobackupex-1.5.1: in '/byread/backup/database_sns_201110290358'
innobackupex-1.5.1: back to original data directory '/byread/data'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/blog'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/sns'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/xtrabackup_slave_info'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/photo'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/xtrabackup_checkpoints'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/mysql'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/template'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/xtrabackup_binlog_info'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/forum'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/quan'
innobackupex-1.5.1: Copying directory '/byread/backup/database_sns_201110290358/message'
innobackupex-1.5.1: Starting to copy InnoDB tables and indexes
innobackupex-1.5.1: in '/byread/backup/database_sns_201110290358'
innobackupex-1.5.1: back to original InnoDB data directory '/byread/data'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/ibdata1'
innobackupex-1.5.1: Starting to copy InnoDB log files
innobackupex-1.5.1: in '/byread/backup/database_sns_201110290358'
innobackupex-1.5.1: back to original InnoDB log directory '/byread/data'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/ib_logfile0'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/ib_logfile1'
innobackupex-1.5.1: Copying file '/byread/backup/database_sns_201110290358/ib_logfile2'
innobackupex-1.5.1: Finished copying back files.
111129 13:34:54 innobackupex-1.5.1: completed OK!
引用
[root@test3 byread]# chown -R mysql /byread/data
[root@test3 quan]# /bin/sh /byread/bin/mysql/bin/mysqld_safe 2>&1 > /byread/logs/mysql/mysql.log &
发表评论
-
数据库备份故障总结
2011-11-29 11:44 854讲述一下此次故障的整个过程: 硬件出现故障,文件系统出错,修复 ... -
MySQL status查看工具mysqlreport
2011-10-20 09:58 1050引用mysqlreport makes a friendly ... -
MySQL从库无法读取主库position
2011-10-19 15:40 1154因为主库文件系统出错,恢复后导致从库无法同步,出现以下信息 s ... -
MySQL移动、电信机房实现Master-Master同步
2011-06-15 13:21 1... -
MySQL主从同步状态
2010-10-19 14:22 15051因为mysql的slave报错,导致slave落后master ... -
MySQL Innodb存储引擎因为缓存配置出现的错误
2010-09-20 10:51 6171引用 100920 10:50:21 mysqld_safe ... -
MySQL Innodb的死锁问题
2010-05-28 14:30 3984今天遇到了数据库的死锁问题,导致应用无法提供服务。当时只好重启 ... -
MySQL清除二进制日志
2010-05-21 10:03 1460MySQL的二进制日志文件很大,运行时间长了会占用很大的磁盘空 ... -
MySQL从库同步出现键冲突的错误
2010-05-20 20:54 871今天做主从读写分离时,发现MySQL从库出现键冲突,同步停止工 ... -
迁移数据库时因Innodb的日志文件大小配置不同导致的问题
2010-05-19 15:32 1800今天迁移了一个数据库,出现以下报错: 引用 InnoDB: E ... -
记录一次用innobackupex恢复Slave的过程
2010-05-18 10:01 2087上次说MySQL出现问题后,slave也不能同步了,具体报错信 ... -
新版本Mysql恢复老版本mysql数据权限表的问题
2010-05-17 13:38 2517新版本对权限控制有一些变动,当我使用innobackupex恢 ... -
记录一次MySQL故障处理
2010-05-13 14:16 1931因为开发之初数据库没有进行好的设计,有很多表的查询字段没有创建 ... -
MySQL Master Slave因字符集不同导致的报错
2010-05-13 13:49 2315今天做主从同步里,执行slave start报了以下错误。 引 ... -
新版本mysql的慢查询日志配置项将更改
2010-05-04 14:32 1262在进行mysql数据库初始化时会一些警告信息,大概意思是:My ... -
innobackupex-1.5.1备份数据库时MySQL server has gone away的解决办法
2010-05-01 11:24 1567在用innobackupex备份数据库是出现以下报错信息时,主 ... -
XtraDB内部原理
2010-04-27 10:09 918XtraDB的内部原理,原文链接:http://www.per ... -
mysql慢查询日志分析
2010-04-14 18:09 1620我喜欢做一些系统性能优化事情,觉得这样有种成就感,实现了自己的 ...
相关推荐
《MySQL数据库备份:innobackupex与xtrabackup详解及实战脚本》 在MySQL数据库管理中,数据安全至关重要,而备份是保障数据安全的重要手段。本文将详细介绍两个用于MySQL数据库物理备份的工具——innobackupex和...
在本案例中,我们将使用innobackupex命令来备份所有数据,并将备份文件恢复到新的数据库服务器中。 步骤一:安装XtraBackup软件包 首先,我们需要安装XtraBackup软件包,使用以下命令: rpm -ivh libev-4.15-1.el...
本文档将介绍如何将阿里云 RDS for MySQL 的备份文件恢复至自建数据库中,以供测试平台使用。我们将讨论物理备份和逻辑备份的差异,并探讨如何下载和解压备份文件,恢复数据,并修改配置文件参数。 阿里云 RDS for ...
全备是指备份数据库中的所有数据和结构。这种备份方式非常直接,恢复时也较为便捷,但缺点是占用的存储空间较大,且在数据量大时备份时间会比较长。 ```shell mysqldump -u root -p your_database > your_...
MySQL 数据备份与恢复是数据库管理中的重要环节,它关乎到数据的安全性和业务的连续性。在本篇中,我们将深入探讨 MySQL 的三种主要备份恢复模式,以及如何利用工具如 `innobackupex` 实现高效的数据保护。 一、...
3. **InnoDB表空间备份**:如果数据库主要使用InnoDB存储引擎,可以考虑使用`innobackupex`(XtraBackup的一部分)进行热备份,这允许在不关闭数据库的情况下进行完整备份。 4. **复制技术**:如果你有多台MySQL...
在生产环境中选择合适的数据库备份与恢复工具至关重要,因为这直接影响到业务的稳定性和恢复速度。在MySQL领域,有两个常用的工具:mysqldump和xtrabackup。本文主要讨论这两种工具的优缺点以及如何根据实际需求选择...
- 验证备份:使用`innobackupex --extract-to`或`xtrabackup --prepare`来验证备份的完整性。 5. **Shell脚本实现**: - 使用`#!/bin/bash`声明脚本使用bash解释器。 - 定义变量如`MYSQL_USER`、`MYSQL_PASSWORD...
虽然使用innobackupex备份MyISAM表时需要对表进行读锁,但这个工具提供了一些有用选项,如`slave-info`,它能够记录备份恢复后作为从服务器(slave)所需的配置信息,简化了主从复制的恢复过程。 在Linux环境下安装...
4. 应用日志文件:使用 Innobackupex 工具将日志文件应用到备份数据中,以便将备份数据还原到数据库中。 5. 复制备份数据:使用 Innobackupex 工具将备份数据复制到数据目录中。 6. 赋予权限:赋予 MySQL 服务所需的...
MySQL作为全球广泛使用的开源关系型数据库管理系统之一,在数据备份方面提供了多种灵活的方法和技术手段。本文旨在为MySQL数据库用户介绍常见的备份策略及具体实施步骤,帮助大家更好地理解和掌握MySQL数据库备份...
5. **恢复数据**:接下来,使用`innobackupex --copy-back`将备份的数据库文件复制回MySQL的数据目录。确保目标目录已清空,否则可能会覆盖现有数据。 6. **启动MySQL**:完成上述步骤后,你可以启动MySQL服务器,`...
- 使用InnoDB的备份工具`innobackupex`进行全量备份:`innobackupex --user=root --password=123456 --defaults-file=XXX (备份目录)` - 执行备份脚本:`./insert_db.sh` 2. **验证数据**: - 连接到数据库,验证...
恢复备份则通过`mysql`客户端进行,如: ```bash /usr/local/mysql-5.6.16/bin/mysql -uroot -p ``` `Xtrabackup`是Percona公司提供的一个高级备份工具,特别适用于InnoDB和XtraDB表。它可以在不锁定数据库的情况...
恢复备份时,使用`--copy-back`选项将备份数据复制回原始数据目录。如果你有多个增量备份,恢复过程会涉及到多个步骤,包括对每个增量备份应用redo日志,最后对整个备份进行`Prepare`。 增量备份允许只备份自上次...
使用innobackupex备份时,它会调用xtrabackup备份所有的InnoDB表,复制所有关于表结构定义的相关文件(.frm)、以及MyISAM、MERGE、CSV和ARCHIVE表的相关文件,同时还会备份触发器和数据库配置信息相关的文件,这些...
使用物理备份方式,例如InnoDB的备份工具InnoBackupEx,可以实现全库恢复。物理备份工具在新建slave实例或者进行全库恢复时显得尤为有效。恢复步骤包括准备备份、应用日志、备份当前的ibd文件以及舍弃当前的ibd文件...
在准备阶段后,如果需要用备份数据来恢复数据库,则需要指定 `--copy-back` 选项和备份数据所在的目录。例如: ``` innobackupex --copy-back /download/bak/xtrbak/2020-03-17_05-30-14 ``` 这将恢复数据库到备份...
逻辑备份是指通过SQL语句的形式来备份数据库的数据和结构。mysqldump是MySQL自带的一个逻辑备份工具,它可以导出整个数据库或指定的表的SQL脚本。下面详细介绍如何使用mysqldump进行逻辑备份: 1. **备份MySQL...