lvm mysql 备份
我一直在阅读有关通过使用lvm进行mysql备份的内容 我了解到您创建一个lvm分区并为mysql分配特定的大小,为快照留出足够的空间。
我读到它的优点是备份非常快。
有什么需要注意的陷阱或缺点吗?
谢谢
I have been reading about mysql backup through the use of lvm
I understand that you create a lvm partition and allocate a specific size to mysql, leaving enough space for the snapshots.
I read that the advantage is that backups are very quick.
Are there any pitfalls to watch out for or disadvantages?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在启用 LVM 快照的情况下运行可能会导致 I/O 性能降低多达 6 倍。
http://www.mysqlperformanceblog.com/ 2009/02/05/disaster-lvm-performance-in-snapshot-mode/
我建议使用 Percona XtraBackup 作为一个更好的热备份工具(免责声明:我为 Percona 工作)。
Running with LVM snapshot enabled can cause I/O performance to degrade up to 6x.
http://www.mysqlperformanceblog.com/2009/02/05/disaster-lvm-performance-in-snapshot-mode/
I suggest using Percona XtraBackup as a much better hot backup tool (disclaimer: I work for Percona).
LVM快照在某些情况下对于InnoDB来说是非常可怕的。为什么?
如果您禁用了 innodb_file_per_table , ibdata1 将里面有一切和它的祖母。 ibdata1 里住着什么?四件事:
如果您如果尝试在关闭 innodb_file_per_table 的情况下在重写入数据库环境中执行 LVM 快照,您可能会搬起石头砸自己的脚。 LVM 快照需要预先很好地合并 ibdata1 文件。
我最近进行了如下实验:
我雇主的网络托管公司的客户的 MySQL 设置存在以下问题:
我想通过以下方式设置 MySQL Slave将 /var/lib/mysql 文件夹同步到另一个数据库服务器。当在 ibdata1 上完成 rsync 且不停机时,需要 42 小时。针对 ibdata1 的第二次 rsync 花费了 84 小时,仅发现 220GB 的更改,并且仅完成了 15%。我放弃了那个任务。
LVM 快照的性能可能比 rsync 好得多。尽管如此,任何涉及非常大的 ibdata1 的 LVM 快照都会遇到同样的问题。
如果您使用 LVM 快照,请使用以下选项:
使用 MySQL 复制从属设备,您可以
STOP SLAVE;
(如果您在 my.cnf 中有 --skip-slave-start)service mysql stop
service mysql start
START SLAVE;
(如果您有 --skip-slave-start my.cnf)这样,这些 LVM 快照问题就永远不会在 Production Master 上出现。
尝试一下,并享受其中的乐趣!
LVM snapshots are very scary for InnoDB under certain circumstances. Why?
If you have innodb_file_per_table disabled, ibdata1 will have everything and its grandmother in it. What lives in ibdata1? Four things:
If you are trying to perform LVM snapshots in a heavy-write DB environment with innodb_file_per_table off, you may be shooting yourself in the foot. An LVM snapshot needs the ibdata1 file to be well coaleseced beforehand.
I recently performed an experiment as follows:
A client at my employer's web hosting company has the following issues with their MySQL Setup:
I wanted to setup a MySQL Slave by rsycning the /var/lib/mysql folder to another DB Server. When the rsync was done on ibdata1 without downtime, it took 42 hours. The second rsync against ibdata1 took 84 hours, only found 220GB of changes, and was barely 15% done. I aborted that mission.
An LVM snapshot may perform much better that an rsync. Notwithstanding, any LVM snapshot involving a very large ibdata1 will be subject to the same issues.
If you go with LVM snapshot, please use these options:
With a MySQL Replication Slave, you can
STOP SLAVE;
(if you have --skip-slave-start in my.cnf)service mysql stop
service mysql start
START SLAVE;
(if you have --skip-slave-start in my.cnf)That way, these LVM snapshot issues will never see the light of day on a Production Master.
Give it a Try, and have fun with this !!!