使用XtraBackup恢复|备份 Mysql数据库 -- 数据恢复篇

数据恢复篇

XtraBackup工具介绍:

现在我们给MySQL做备份的时候经常会考虑到数据量的增长,数据量较小的时候用mysqldump,随着数据量越来越大mysqldump也就不太合适了.第一不支持增量备份,第二恢复的时候也较慢.这里推荐使用Percona公司的XtraBackup.

简单介绍一下热备份工具XtraBackup,它是Percona公司推出的一款热备份工具,备份的时候不影响数据读写操作,是商业工具HotBackup的一个替代(现在应该叫MySQL Enterprise Backup这个工具不止可以备份InnoDB还可以备份MyISAM等等)

XtraBackup有两个工具:xtrabackup和innobackupex.

xtrabackup本身只能备份InnoDB和XtraDB,不能备份MyISAM.

innobackupex本身是Hot Backup脚本修改而来,同时可以备份MyISAM和InnoDB,但是备份MyISAM需要加读锁.

#安装percona-xtrabackup rpm软件包。

[[email protected] data]# rpm -ivh percona-xtrabackup-2.3.2-1.el6.x86_64.rpm 
warning: percona-xtrabackup-2.3.2-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
error: Failed dependencies:
libev.so.4()(64bit) is needed by percona-xtrabackup-2.3.2-1.el6.x86_64
perl(DBD::mysql) is needed by percona-xtrabackup-2.3.2-1.el6.x86_64

#安装依赖:

yum install  perl-DBD-MySQL

#安装libev包

到http://rpmfind.net/linux/rpm2html/search.php?query=libev.so.4%28%29%2864bit%29&submit=Search+...&system=&arch= 下载操作系统对应的libev包,注意系统号与版本位数

[[email protected] ~]# wget  ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm  
--2016-05-17 12:54:43--  ftp://rpmfind.net/linux/dag/redhat/el6/en/x86_64/dag/RPMS/libev-4.15-1.el6.rf.x86_64.rpm  
           => “libev-4.15-1.el6.rf.x86_64.rpm”  
Resolving rpmfind.net... 195.220.108.108  
Connecting to rpmfind.net|195.220.108.108|:21... connected.  
Logging in as anonymous ... Logged in!  
==> SYST ... done.    ==> PWD ... done.  
==> TYPE I ... done.  ==> CWD (1) /linux/dag/redhat/el6/en/x86_64/dag/RPMS ... done.  
==> SIZE libev-4.15-1.el6.rf.x86_64.rpm ... 74692  
==> PASV ... done.    ==> RETR libev-4.15-1.el6.rf.x86_64.rpm ... done.  
Length: 74692 (73K) (unauthoritative)  
  
100%[===============================================================================================================>] 74,692       187K/s   in 0.4s      
  
2016-05-17 12:54:46 (187 KB/s) - “libev-4.15-1.el6.rf.x86_64.rpm” saved [74692]

安装RHEL6对应的libev-4.15-1.el6.rf.x86_64.rpm包

[[email protected] ~]# rpm -ivh libev-4.15-1.el6.rf.x86_64.rpm  
warning: libev-4.15-1.el6.rf.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 6b8d79e6: NOKEY  
Preparing...                ########################################### [100%]  
   1:libev                  ########################################### [100%]

#安装percona-xtrabackup软件包:

[[email protected] data]# rpm -ivh percona-xtrabackup-2.3.2-1.el6.x86_64.rpm 
warning: percona-xtrabackup-2.3.2-1.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID cd2efd2a: NOKEY
Preparing...                ########################################### [100%]
percona-xtrabackup     ########################################### [100%]

操作过程如图:

#备份恢复时数据库必须停止的。

[[email protected] ~]# /etc/init.d/mysqld stop
Shutting down MySQL..                                      [  OK  ]

#上篇fpm封装好的二进制mysql,纯净。

注意:备份时候MySQL必须是运行状态,而在做数据恢复时候服务必须是处于停滞状态。

重要参数:

--defaults-file=/etc/my.cnf:备份时,指定配置文件

--socket=/tmp/mysql.sock:备份时,连接到备份的mysql服务器所使用的 套接字文件

--user=root:连接备份mysqld所使用的用户

--password=hello:连接备份mysqld所使用的用户密码

--no-timestamp:默认情况下,备份目录会使用以当前时间为名称创建一个备份目录,加上此参数则不会做这个动作

--apply-log:创建ib_logfile文件,并恢复备份期间产生的redo日志到ib_logfile和表空间中。注意:若备份期间产生了提交的事务日志,则apply-log操作会将未提交的事务回滚

--copy-back:执行恢复数据到目标mysqld,但是目标mysqld的数据目录不 能用—datadir指定,这一点不同与meb,而是需要使用—defaults-file指 定一个配置文件,在配置文件中指定恢复的datadir。与meb不同,恢复前必 须清空目录数据目录

--use-memory=1G:备份时xtrabackup可用的内存大小,取决于操作系统可用的内存量,默认为100M,使用大的内存可加速备份的速度

--incremental:表示为增量备份,增量备份只对innodb表有效,对于non-innodb表,例如myisam则无效,因为每次增量备份都会拷贝myisam相关的所有文件,不管上次备份到这次备份有没有发生更改;而对于innodb表,增量备份则只会备份上次备份到这次备份所更改的表

--incremental-basedir=/lxw/full-back/:基于上一次的备份目录做增量 备份

--incremental-dir=/lxw/incr-backup/:用于将增量备份恢复到全备时指定增量备份的目录

--redo-only:增量备份恢复到之前的备份时,除了最后一个增量备份外,其他的增量备份最好指定该参数

--databases=’dba.t1 mysql performance_schema lxw.t1’:用于部分备份,可以用空格分开,指定备份哪些库的所有表,或者哪些库的某些表

--export:在执行apply-log操作时,将应用信息保存到文件中,在恢复部分备份时有用

--compact:采用压缩备份

--rebuild-indexes:解压缩

----记录备份信息(如备份命令、备份开始和完成时间、binlog position、备份开始和完成的lsn等

注意:备份使用的innobackupex是2.3.1 恢复可以使用innobackupex2.3.x等小版本,但是不能夸大版本,否则会有问题。

#为了练习使用percona-xtrabackup全量备份了线上的mysql,scp到新机器上恢复练习。

备份完备份的时间目录下都有xtrabackup_info 文件,记录了你备份时的动作。

[[email protected] 2017-03-27_04-00-01]# cat xtrabackup_info 
uuid = c4c25074-1260-11e7-9a6a-069e3400093a
name = 
tool_name = innobackupex
tool_command = --defaults-file=/etc/my.cnf --socket=/usr/local/mysql56/data/mysqld.sock --host=localhost --user=backuser --password=... /usr/local/mysql56/mysql_data_backup/o2o/full_backup/
tool_version = 2.3.3#工具的版本
ibbackup_version = 2.3.3
server_version = 5.6.25-log
start_time = 2017-03-27 04:00:02
end_time = 2017-03-27 04:14:08
lock_time = 0
binlog_pos = filename ‘mysql-bin.000285‘, position ‘764217961‘
innodb_from_lsn = 0
innodb_to_lsn = 393358640191
partial = N
incremental = N
format = file
compact = N
compressed = N
encrypted = N

#首先恢复事务,也可以加--user=:

[[email protected] data]# innobackupex --apply-log --use-memory=10M 2017-03-27_04-00-01/
170331 01:28:54 innobackupex: Starting the apply-log operation
IMPORTANT: Please check that the apply-log run completes successfully.
           At the end of a successful apply-log run innobackupex
           prints "completed OK!".
innobackupex version 2.3.2 based on MySQL server 5.6.24 Linux (x86_64) (revision id: 306a2e0)
xtrabackup: cd to /data/2017-03-27_04-00-01/
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=26689536, start_lsn=(393334934174)
xtrabackup: using the following InnoDB configuration for recovery:
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 = 26689536
xtrabackup: using the following InnoDB configuration for recovery:
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 = 26689536
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 10485760 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 10.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 393334934174
InnoDB: Database was not shutdown normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages 
InnoDB: from the doublewrite buffer...
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Doing recovery: scanned up to log sequence number 393340176896 (22%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Doing recovery: scanned up to log sequence number 393345419776 (44%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Doing recovery: scanned up to log sequence number 393350662656 (66%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Doing recovery: scanned up to log sequence number 393355905536 (88%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: Doing recovery: scanned up to log sequence number 393358640191 (99%)
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 393358640191
xtrabackup: Last MySQL binlog file position 764217961, file name mysql-bin.000285
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 393358641472
xtrabackup: using the following InnoDB configuration for recovery:
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 = 2
xtrabackup:   innodb_log_file_size = 50331648
InnoDB: Using atomics to ref count buffer pool pages
InnoDB: The InnoDB memory heap is disabled
InnoDB: Mutexes and rw_locks use GCC atomic builtins
InnoDB: Memory barrier is not used
InnoDB: Compressed tables use zlib 1.2.3
InnoDB: Using CPU crc32 instructions
InnoDB: Initializing buffer pool, size = 10.0M
InnoDB: Completed initialization of buffer pool
InnoDB: Setting log file ./ib_logfile101 size to 48 MB
InnoDB: Setting log file ./ib_logfile1 size to 48 MB
InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
InnoDB: New log files created, LSN=393358641472
InnoDB: Highest supported file format is Barracuda.
InnoDB: 128 rollback segment(s) are active.
InnoDB: Waiting for purge to start
InnoDB: 5.6.24 started; log sequence number 393358641676
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 393358644153
170331 01:29:33 completed OK!

#恢复数据,也可以加--defaults-file=/etc/my.cnf --rsync 也可以去掉

innobackupex --copy-back --rsync 2017-03-27_04-00-01/
........
.........
170331 03:03:04 [01]        ...done
170331 03:03:04 [01] Copying ./ecos_notice/tbl_notice_file.ibd to /data/mysqldata/ecos_notice/tbl_notice_file.ibd
170331 03:03:04 [01]        ...done
170331 03:03:04 [01] Copying ./stest/tbl_test_user_info.ibd to /data/mysqldata/stest/tbl_test_user_info.ibd
170331 03:03:04 [01]        ...done
170331 03:03:04 [01] Copying ./stest/tbl_test_user_info.frm to /data/mysqldata/stest/tbl_test_user_info.frm
170331 03:03:04 [01]        ...done
170331 03:03:04 [01] Copying ./stest/db.opt to /data/mysqldata/stest/db.opt
170331 03:03:04 [01]        ...done
170331 03:03:04 completed OK!

授权恢复数据的目录为mysql用户和mysql组:

[[email protected] data]# ll
total 5624
drwx------ 14 root  root     4096 Mar 31 02:33 2017-03-27_04-00-01
-rw-r--r--  1 root  root    74692 Mar 31 01:10 libev-4.15-1.el6.rf.x86_64.rpm
drwxr-xr-x 13 mysql mysql    4096 Mar 31 02:42 mysql
drwxr-xr-x 14 root  root     4096 Mar 31 03:03 mysqldata
drwxr-xr-x  2 mysql mysql    4096 Mar 31 02:47 mysqldata20170330
-rw-r--r--  1 root  root  5664452 Mar 31 01:09 percona-xtrabackup-2.3.2-1.el6.x86_64.rpm

#授权mysql用户和mysql组

[[email protected] data]# chown mysql:mysql mysqldata -R    #授权mysql用户和mysql组

#mysql启动跳过授权用户表

[[email protected] data]# cat /etc/my.cnf 
[mysqld]
basedir=/data/mysql
datadir=/data/mysqldata
port=3306
socket=/tmp/mysql.sock
user=mysql
innodb_file_per_table=on  
skip_name_resolve=on  
symbolic-links=0
init-connect=‘SET NAMES utf8‘
character-set-server = utf8
max_connections = 5000
max_connect_errors = 100000
skip-grant-tables            #添加启动mysql跳过用户授权表
[mysqld_safe]
log-error=/data/mysql/mysqld.log
pid-file=/data/mysql/mysqld.pid、

#启动mysql服务:

[[email protected] data]# /etc/init.d/mysqld start
Starting MySQL...                                          [  OK  ]
[[email protected] data]# cd mysqldata
[[email protected] mysqldata]# ls
2017-03-31_02-33-37  ecos           ecoslog      ibdata1      localhost.localdomain.pid  stest                         xtrabackup_info
appversion           ecosantispam   ecos_notice  ib_logfile0  mysql                      test
auto.cnf             ecos_delivery  ecoswallet   ib_logfile1  performance_schema         xtrabackup_binlog_pos_innodb

#当然你也可以不加在配置文件中:

/etc/rc.d/init.d/mysqld start 
--skip-grant-tables;          #
跳过权限表启动mysql不用密码;
时间: 2024-10-07 12:00:49

使用XtraBackup恢复|备份 Mysql数据库 -- 数据恢复篇的相关文章

xtrabackup 备份mysql数据库三: innobackupex 测试一个全量和两个增量的备份恢复测试

## 查看当前库中表的数据 ([email protected]) [test]>select count(*) from t_innodb; +----------+ | count(*) | +----------+ |        0 | +----------+ 1 row in set (0.00 sec) ## 执行插入数据操作,该操作在全备之后执行完成 ([email protected]) [test]>call addTest(100000,0); ## 执行全库备份 #

使用XtraBackup 备份MySQL数据库

本次测试使用XtraBackup备份MySQL数据库 版本:XtraBackup2.4.5+MySQL5.7.16 下载地址:https://www.percona.com/downloads/XtraBackup/ 1.安装XtraBackup 本次为了方便,使用解压版本进行安装,直接解压就可以用了. 使用过程中可能会遇到缺少perl依赖包的问题,我的方法是直接操作把镜像包里的perl都安装了,yum install -y perl* 2.简介 XtraBackup主要包括两个备份工具xtra

学会用各种姿势备份MySQL数据库

学会用各种姿势备份MySQL数据库 大纲 前言 为什么需要备份数据? 数据的备份类型 MySQL备份数据的方式 备份需要考虑的问题 设计合适的备份策略 使用cp进行备份 使用mysqldump+复制BINARY LOG备份 使用lvm2快照备份数据 使用Xtrabackup备份 前言 我们试着想一想, 在生产环境中什么最重要?如果我们服务器的硬件坏了可以维修或者换新, 软件问题可以修复或重新安装, 但是如果数据没了呢?这可能是最恐怖的事情了吧, 我感觉在生产环境中应该没有什么比数据跟更为重要.

Percona Xtrabackup快速备份MySQL

Percona Xtrabackup快速备份MySQL 提交 我的评论 加载中 已评论 Percona Xtrabackup快速备份MySQL 2015-07-10 Linux中国 Linux中国 Linux中国 微信号 linux-cn 功能介绍 面向Linux爱好者,提供Linux技术文章.新闻资讯和交流平台. 每天推送一条最新精选Linux资讯和技术文章:支持Linux命令查询.Linux资讯搜索及微信群的交流. 老规矩,开场白,刚开始用mysqldump,备份100G+的数据库,再加上服

备份MySQL数据库的命令

这篇文章主要介绍了mysql数据库备份常用语句,包括数据库压缩备份.备份多个MySQL数据库.备份多个MySQL数据库.将数据库转移到新服务器等语句 代码如下: mysqldump -hhostname -uusername -ppassword databasename > backupfile.sql 备份MySQL数据库为带删除表的格式 备份MySQL数据库为带删除表的格式,能够让该备份覆盖已有数据库而不需要手动删除原有数据库. 代码如下: mysqldump -–add-drop-tab

C#使用MysqlBackup.Net 备份MySQL数据库

首先 声明这篇博文没有什么技术水平  希望各位大神口下留情 好的  咱们进入主题 开场介绍一下这个MysqlBackup.Net dll 是国外开源的作品  官方网站 https://mysqlbackupnet.codeplex.com/ 我这里提供目前官方最新版本 2.0.9.2   解压缩后里面会有两个文件夹   binaries里面是类库 里面分各个.net版本    source code里面是源代码 有兴趣的同学可自行下载研究其代码 点击下载MysqlBackup.Net 因为我项目

快照方式备份MySQL数据库及举例

快照方式备份MySQL数据库及举例 作者: 红豆殺 日期: 2011 年 03 月 17 日发表评论7条评论查看评论 一.创建逻辑卷 依照如下连接的文档创建一个逻辑卷 http://www.178-go.com/tags/lvm 要求:物理卷20G;卷组名为vg0;逻辑卷2G,逻辑卷名为mydata 创建逻辑卷挂载点,并挂载之 # mkdir /mydata # mount /dev/vgo/mydata /mydata 二.安装MySQL数据库 如果机器已装有mysql,则此步可省略 只需修改

一个自动备份mysql数据库的bat文件内容

自动备份mysql数据库,并已当前的日期时间为目录 copy过去, xcopy将近15年没有用dos命令,还是这么亲切 另 本方法是备份数据库文件,不是dump导出,然后再计划任务中使用,我用的是wamp,其他的环境类似的改改即可 ====dbback.bat============ NET STOP wampapacheNET STOP wampmysqldset /a t1=(1%time:~0,2%-100)*1if %t1% LSS 10 set t1=0%t1%set ymd_hms=

Shell脚本-----自动备份Mysql数据库

脚本的整体思路 1.定义需要的变量 2.利用for循环备份需要备份的库,并以库名-当天日期.sql命名,并记录相关日志 3.建立备份当天的日期的目录,向备份的Sql文件移动到该目录 4.压缩打包该目录,以节省空间,打包成功后删除该目录 5.备份目录只备份七天的数据库,第八天删除第一天的备份,目录只会存在连续七天的备份文件 6.查找备份目录下的.log日志文件,超过七天的删除 #!/bin/bash mysql_bin=/usr/local/tdoa/mysql/bin/mysqldump use