用于复制EBS卷的快照 [英] Snapshot of EBS volume used for replication
问题描述
我的设置与MySQL在EBS卷，并设置另一个实例充当奴隶的复制一个EC2实例。复制设置的罚款。我的问题是关于采取这些卷的快照。我注意到，表需要被锁定快照的过程，可能会造成不便的用户。所以，我的想法是独自离开主实例，并采取实例充当奴隶的快照。这是一个好主意？有没有人在用类似的设置，并能指导我在正确的方式？
I setup an EC2 instance with MySQL on EBS volume and setup another instance which acts as Slave for Replication. The replication set up was fine. My question is about taking snapshots of these volumes. I noticed that the tables need to be locked for the snapshot process which may cause inconvenience for the users. So, my idea is to leave the Master instance alone and take a snapshot of instance acting as slave. Is this a good idea? Is there anyone out with a similar setup and could guide me in a right way?
此外，以从实例的快照需要表锁。请问这意味着复制将打破？
Also, taking snapshot of slave instance would require locking of tables. Would that mean replication will break?
在此先感谢。
推荐答案
尽管这是一个好主意，锁定数据库，并冻结了文件系统，当您启动快照，实际的API调用来启动快照花费的一小部分第二，让你的数据库和文件系统不会锁定/冷冻太久。
Though it's a good idea to lock the database and freeze the file system when you initiate the snapshot, the actual API call to initiate the snapshot takes a fraction of a second, so your database and file system aren't locked/frozen for long.
这是说，有一对夫妇其他考虑你没有提到：
That said, there are a couple other considerations you did not mention:
-
当您尝试创建数据库上的锁，这可能需要等待其他语句锁被批准之前完成。在此期间，您的待处理的锁可能会进一步声明，等到你和解除锁定。这可能会导致在生产数据库语句的流中断。
When you attempt to create the lock on the database, it might need to wait for other statements to finish before the lock is granted. During this time, your pending lock might further statements to wait until you get and release the lock. This can cause interruptions in the flow of statements on your production database.
在启动创建快照，你的应用/数据库是免费使用的文件系统卷上，但如果你有很多写的，你可能会遇到高IOWAIT，有时足以创造您的应用程序的显着放缓。这样做的原因是，背景快照过程需要一个块拷贝到S3之前它将允许写入活动卷上的块
After you initiate the creation of the snapshot, your application/database is free to use the file system on the volume, but if you have a lot of writes, you could experience high iowait, sometimes enough to create a noticeable slowdown of your application. The reason for this is that the background snapshot process needs to copy a block to S3 before it will allow a write to that block on the active volume.
我通过请求锁和超时如果不批迅速解决的第一个问题。然后我等了一下，继续重试，直到我得到了锁。适当的超时和重试延迟可能会因不同的数据库负载。
I solve the first issue by requesting a lock and timing out if it is not granted quickly. I then wait a bit and keep retrying until I get the lock. Appropriate timeouts and retry delay may vary for different database loads.
我解决了通过进行频繁的，一致的快照上的奴隶，而不是主人，就像你提出的第二个问题。我还是建议进行不定期的快照对主人根本，以提高其内在的耐久性（深EBS财产），但这些快照不需要被锁定或冻结，你不打算使用它们进行备份完成。
I solve the second problem by performing the frequent, consistent snapshots on the slave instead of the master, just as you proposed. I still recommend performing occasional snapshots against the master simply to improve its intrinsic durability (a deep EBS property) but those snapshots do not need to be performed with locking or freezing as you aren't going to use them for backups.
我还建议使用支持潮红和冻结一个文件系统（XFS）的。否则，你的快照在MySQL中锁定表，可能没有甚至有EBS卷上的所有的块又或文件系统的其它部分的快照可能会进行修改和不一致的。
I also recommend the use of a file system that supports flushing and freezing (XFS). Otherwise, you are snapshotting locked tables in MySQL that might not yet even have all their blocks on the EBS volume yet or other parts of the file system might be modified and inconsistent in the snapshot.
如果你有兴趣，我已经发布执行我收集相关的最佳实践，以创建与MySQL和XFS（选购件）一致EBS快照开源软件。
If you're interested, I've published open source software that performs the best practices I've collected related to creating consistent EBS snapshots with MySQL and XFS (both optional).
http://alestic.com/2009/09/ec2-consistent-snapshot
要回答你的最后一个问题，锁定表中的主不会打破复制。在我的快照软件，我也刷新表的读锁，以确保一切都在磁盘上被快照和我添加关键字本地，这样刷新不被复制到任何潜在的奴隶。
To answer your last question, locking tables in the master will not break replication. In my snapshot software I also flush the tables with read lock to make sure that everything is on the disk being snapshotted and I add the keyword "LOCAL" so that the flush is not replicated to any potential slaves.
这篇关于用于复制EBS卷的快照的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
