主页 / server / 问题 / 1162978
Accepted
Patrick Teng
Asked: 2024-07-24 16:03:32 +0800 CST

通过从 AMI 启动的实例生成 MySQL 转储

  • 772

我有一个实时的 ec2 服务器实例，其中 MySQL 安装在本地（不使用 RDS），还有另一个备份服务器，作为实时服务器的从属运行 MySQL 复制。

我现在正在尝试生成每日自动 SQL 转储，到目前为止，我一直在研究 AWS CLI，以便通过以下方式自动化整个过程：

  1. 使用实时服务器的 AMI 快照启动实例（每天备份）
  2. 运行 mysql dump 命令
  3. 终止实例并删除卷。

我让它完全运行起来（命令等等），但我注意到一个问题是，通过 AMI 启动的实例中的 MySQL 非常慢，生成完整备份需要 2-3 倍的时间（与在实时服务器中执行相比）。

我尝试不在备份/从属服务器中执行此操作，因为我们希望备份服务器的数据始终处于准备状态，但生成 mysqldump 将暂时需要暂停从属服务器并稍后恢复（也就是说，将会有 xx 段时间的滞后，其中 xx 是生成 mysql dump 所需的时间）。

有没有更好的解决方案？我们不使用 RDS 主要是因为成本问题，因此我们全部手动完成。

我的目标是按表创建多个 sql 备份文件，从某种意义上说，1 个表 1 个文件，但每个文件在数据方面必须具有相同的截止日期。

amazon-web-services

2 个回答

  1. 很容易看出为什么备份需要更长时间。

    尽管快照在 AWS 告诉您它存在时就存在，但此时它只是一组指向原始数据的指针。在后台，AWS 正在运行复制作业来填充数据。如果您尝试从快照中读取尚未填充的内容，您的读取调用将被阻止，AWS 会将请求放在复制列表的顶部，您需要等到该数据填充完毕。此数据填充称为“水合”。

    解决此问题的唯一方法是让另一个副本始终运行。

    使用实时服务器的 AMI 快照启动实例

    因此，除非您停止实时服务器来创建快照，否则这也意味着在启动新实例时会有长时间的暂停，以便 MySQL 运行崩溃恢复。您可以考虑使用您已有的临时停止副本的快照来避免这种情况。

    一旦您拥有一个具有完全填充数据的副本，它只用于运行 mysqlbackup（即非常低的并发性），然后您可以通过增加预读（最多为默认值的 8 倍）来加快备份速度。

    或者（或经过测试，组合）您可以考虑使用 Percona Xtrabackup - 这将使用多个线程进行备份。

    即其缓慢的原因（按影响估计的顺序）是：

      1=) snapshot hydration
  1=) Crash recovery
  3) IO latency
  4) CPU

    另一种方法是在主机上创建文件系统快照，而不是块设备 AWS 快照（无需复制）。然后，您可以将其挂载到主机上并使用原始数据文件进行备份，或者在同一主机上启动第二个 mysql 实例以访问快照并运行 mysqlbackup。

    或者只是将 AWS 快照视为备份。

    • 2
  2. Best Answer

    很难说为什么在新实例上执行备份要花 2-3 倍的时间，但这里有一些事情需要检查/考虑：

    • 实例类与生产实例相同吗？备份实例上的 CPU/内存较少肯定会增加执行完整备份所需的时间。
    • 如果它是 EBS 支持的实例，那么附加的卷是否与生产实例具有相同的存储类和大小，即配置的 IOPS 数量？
    • 如果在 MySQL 正在运行的情况下在运行实例期间拍摄 AMI 快照，则某些数据可能不会刷新到磁盘，并且某些 MySQL 文件可能仍处于脏状态。启动新实例时，可能需要额外的时间来运行一些恢复检查和程序以使服务器处于干净状态。

    有没有更好的解决方案？我们不使用 RDS 主要是因为成本，因此我们全部手动完成。但生成 mysqldump 将暂时需要暂停从属服务器并稍后恢复

    您可以从副本（或主副本）创建数据库转储，而无需锁定表或以任何方式暂停它。看看--single-transaction您是否正在使用 InnoDB，这里有一些关于它的解释。

    更新：如果您希望在单个事务中为单独的表创建单独的文件，而不必锁定单个表，则可以--tab使用一个参数mysqldump：https://dev.mysql.com/doc/refman/8.4/en/mysqldump-delimited-text.html

    • 1

相关问题