用于复制的 EBS 卷的快照
我在 EBS 卷上设置了一个带有 MySQL 的 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?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
尽管在启动快照时锁定数据库并冻结文件系统是一个好主意，但启动快照的实际 API 调用只需要几分之一秒的时间，因此您的数据库和文件系统不会长时间锁定/冻结。
也就是说，还有其他一些您没有提到的注意事项：
当您尝试在数据库上创建锁时，可能需要等待其他语句完成才能授予锁。在此期间，您的挂起锁可能会进一步执行语句等待，直到您获取并释放该锁。这可能会导致生产数据库上的语句流中断。
启动快照创建后，您的应用程序/数据库可以自由使用卷上的文件系统，但如果您有大量写入，则可能会遇到高 iowait，有时足以造成明显的速度减慢您的申请。原因是后台快照进程需要将一个块复制到 S3，然后才允许在活动卷上写入该块。
我通过请求锁定并在未快速授予锁定时超时来解决第一个问题。然后我稍等一下并继续重试，直到获得锁。对于不同的数据库负载，适当的超时和重试延迟可能会有所不同。
正如您所建议的那样，我通过在从属服务器而不是主服务器上执行频繁、一致的快照来解决第二个问题。我仍然建议偶尔对主服务器执行快照，只是为了提高其内在持久性（深层 EBS 属性），但这些快照不需要通过锁定或冻结来执行，因为您不打算将它们用于备份。
我还建议使用支持刷新和冻结（XFS）的文件系统。否则，您正在对 MySQL 中的锁定表进行快照，这些表可能尚未将所有块都存储在 EBS 卷上，或者文件系统的其他部分可能会被修改并且在快照中不一致。
如果您有兴趣，我已经发布了开源软件，该软件执行我收集的与使用 MySQL 和 XFS（均为可选）创建一致的 EBS 快照相关的最佳实践。
回答您的上一个问题，锁定主服务器中的表不会破坏复制。在我的快照软件中，我还使用读锁刷新表，以确保所有内容都在正在快照的磁盘上，并且我添加关键字“LOCAL”，以便刷新不会复制到任何潜在的从属设备。
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.
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.
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.
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.
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).
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.
你绝对可以给奴隶拍一张快照。
从您的描述来看，从属设备似乎并未投入使用。
如果是这种情况，那么获取可靠卷快照的最安全方法是：
You can definitely take a snapshot of the slave.
From your description, it does not seem like the slave is being used operationally.
If this is the case, then the safest method of obtaining a reliable volume snapshot would be to: