1.
mysqldump
2.
mysqlhotcopy
3.mysqlsnapshot
4.ibbackup
联机备份
.VS.
脱机备份
联机备份通常使用在不能接受数据库停机的情况下,一般来说,脱机备份速度快,并且发生错误的几率少,我们不用担心数据库正在执行事务,锁表等容易发生一致性问题的发生。如果你幸运的可以停下数据库或者有一个主从方式的数据库,请使用脱机方式备份。
Data
Dump
vs
Raw
backups
Data
dump
输出一系列SQL
语句序列,可以在后来用来重新创建数据库的结构并恢复数据。mysqldump
是这个领域的首选工具,他可以用在任意类型的表上面,无论是本地的还是网络的。当然,由于要产生很多额外的SQL语句,导出结果将是一个很大的文件并且占用很多CPU资源,最重要的是,当数据恢复后需要一次完全的索引重建。
更有效率的方法是是对MySQL数据库的物理文件做一次快照(snapshot)。因为我们跳过了很多转化步骤,因此处理起来比较高效。
做一个MyISM数据表的备份只要拷贝磁盘上数据文件和索引文件。对InnoDB,需要备份对应表空间和关联的事务日志。
mysqldump
/
mysqlhotcopy
/
mysqlsnapshot
/
ibbackup
mysqldump
-
(online,
dump)
-
最一般的工具,他会通过锁表的方式从一个联机数据库中做数据导出并写到指定的文件中(磁盘或网络上)。他只适合小的数据库。
#
typical
mysql
dump
backup
and
restore
usage
mysqldump
-u
root
-pPassword
-x
–all-databases
>
db_dump.sql
mysql
-u
root
-pPassword
<
db_dump.sql
#
dump
into
‘backup’
folder
(local
machine),
into
two
text
files
<data,
table_structure>
mysqldump
-T
backup
–fields-terminated-by=’,’
database-name
-u
root
-pPassword
#
compress
the
dumped
data
on
the
fly
mysqldump
-u
root
-pPassword
–all-databases
|
bzip2
-c
>
db_dump.bz2
mysqlhotcopy
-
(online,
raw)
将对由
ISAM或MyISAM
表构成的数据库做一个完全的物理备份。他的 *** 作方式:对所有表获取一个只读锁=>做文件拷贝=>释放锁。
#
perform
an
online
backup
into
/backup/location
mysqlhotcopy
-u
root
-p
password
database_name
/backup/location
mysqlsnapshot
-
(online,
raw)
一个非常好的工具用来在联机方式下获得MySQL数据库的一个快照。可以配置它来压缩数据,并/或
为每一个数据库提供一个分离的tar文件。
不过他只适合
MyISAM
类型数据库。
#
save
a
full
database
snapshot
of
an
online
database
into
/backup/location
mysqlsnapshot
-u
root
-pPassword
-s
/backup/location
#
restore
a
snapshot
tar
-xvf
/backup/location/db.tar
ibbackup
-
(online,
raw)
可以对使用InnoDB和MyISAM表的任何数据库做联机备份。是一个很好的工具就是要收费.当然如果你是一个InnoDB的用户,还是值得花钱购买的。
#
perform
online
backup
of
MyISAM
/
InnoDB
tables
ibbackup
/etc/my.cnf
/etc/ibbackup.cnf
#
restore
recent
backup
(as
configured
in
ibbackup.cnf)
ibbackup
–restore
/etc/ibbackup.cnf
cp,
scp,
nc
-
(offline,
raw)
如果你可以停下数据库,则可以使用这几个工具直接拷贝数据库目录下的文件。是获取数据库快照的最安全方法。
首先我们做一个模拟,执行以下的sql,其中有如下图数据:
我把执行结果按照表格如下展示:
分析:
在会话1当中,只有当会话1的事务提交后,才能查到最终会话2更改的数据。
在会话2当中,开启事务后更新数据,之后查询发现数据变成了17。
针对上面的现象我们进行个原理分析:
实际上产生上述显现是因为InnoDB采用的MVCC(多版本并发控制),其中针对每条数据会有它自己的事务id,以及一个最大事务id。针对事务中数据每次修改,会产生不同的版本。
1)假设开始id = 2的数据,其事务txid = 1000;
2)当会话1开始,此时txid变成了1001,而会话2开启,txid又变成了1002,同理会话3会变成1003,此时都生成了不同版本的快照。
3)会话1在事务当中去读取时候,采用了快照读的方式,即拿到一个1001的事务id,此时只会读取小于等于自己版本的数据,所以在事务中最终只能拿到值为17的数据。
4)会话2在更新数据的时候,采用的当前读的方式,即对数据增加X锁,获取最新的事务id,读取最新的版本数据。所以在更新之前,就读取到了age的年龄是16,之后在进行+1,得到17.
总结一下:
快照读 解决了幻读的问题,即多次读取数据不一致的问题。
update、insert、delete都会执行 当前读 ,防止并发更新数据导致数据错误,此过程或添加X锁。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)