我们的主要分析数据库拥有大量用户，他们不仅希望读取数据，还希望创建大型派生数据表。在成本方面，这开始变得令人望而却步，当有太多人同时写入大型表时，数据库的速度会降低，这是不可接受的。
我想要的解决方案是创建一些读/写副本，这样我们的核心数据就会从主服务器复制到一些启用了写入功能的副本，并且每个用户都可以在其中一个副本上工作。 / p>
然而，我担心这似乎不是启用复制副本的预期用例。我担心的是用户会在他们的副本上建立大量有价值的数据。如果副本崩溃，我该怎么办？
使用只读副本，当然你可以重新创建副本，一切都很好。
但是如果你的副本有你关心的数据，与主人分开，事情就更难了。您无法启动副本的还原并将其重新附加到主副本，因为您无法附加现有副本，您只能启动新副本。
AWS上是否有针对此的架构解决方案？或许有一种方法可以附加现有的副本吗？
答案 0 :(得分：2)
您无法将只读副本重新附加回原始主副本。
您无法使用Amazon RDS设置读写副本。
注意： 亚马逊有一篇关于启用写入MySQL只读副本的文章。我从未测试过这个，所以我不知道其含义。
How do I configure my Amazon RDS DB instance read replica to be modifiable?
当您从主服务器中断读取副本时，只读副本将成为主服务器。为了保护您的数据，请像在原始主数据上一样设置预定备份。
由于您的问题是写性能，因此您有两种选择。扩展实例大小或增加预配置IOPS。使用CloudWatch创建指标以确定问题的性能区域（CPU，内存，磁盘I / O）。另一种可能的选择可能是切换到Aurora。
答案 1 :(得分：2)
如果副本崩溃，我该怎么办？
RDS副本现在支持多可用区。
多AZ为您提供两个实例，每个实例都有自己的EBS卷，在两个AZ中，其中只有一个可以在任何时间访问，另一个在空闲时作为热备用。发生故障时，备份实例将接管并且实例的DNS主机名从一个切换到另一个。
多可用区的实际实施没有公开记录，但据说复制是同步的。唯一可行的方法是复制是存储级复制而不是逻辑（binlog）复制，并且可以通过各种观察来解决这个问题。似乎活动实例实际写入两个卷，并且备份实例上的MySQL守护程序未运行。发生故障转移事件时，备份上的服务器守护程序将启动并通过标准的MySQL崩溃恢复。
启用多可用区应解决发生崩溃时会发生什么的问题......取决于您对“崩溃”的定义。
副本可以拥有每日备份和快照，并且可以像独立或主实例一样通过时间点恢复进行恢复... RDS中数据库实例的时间点恢复永远不会修改正在“恢复”的实例“ - 它从快照创建一个新的，然后使用binlog向前滚动。
...但在这种情况下，当然，“已恢复”的实例将是一个不同的实例，并且将不再是RDS副本。
在这种情况下，您需要做的是将失败的实例恢复到某个时间点，然后创建新的副本，然后将已恢复的实例中的数据转储并加载到其替换中 - 但仅限于那些不在主服务器上的表 - 可写副本唯一的表。
作为澄清的一点，MySQL本机复制对副本上存在但不存在于主服务器上的表没有问题。 MySQL复制确实存在主表和副本上都存在但表中存在不同数据的表的问题 - 这是一种不受支持的配置，因此任何使副本可写的计划都必须要求表来自主服务器不能更改（有一些例外 - 特别是，可以安全地将其他非唯一索引添加到副本上的表中以进行查询优化） - 否则，复制将被破坏，并且不会在其上执行其他复制事件复制品。
如果由于滥用副本而导致复制失败（例如，删除或更改主服务器随后修改的表），就RDS而言，它仍然是副本，只是一个损坏的副本，并且可以恢复到正常操作，包括RDS复制......但这是一个微妙的操作，需要对MySQL本机复制的低级理解。这种修复的要点是必须修改副本数据集中的相关数据，使其与执行失败复制事件后立即存在于主服务器上的数据相同。一旦副本的数据处于此状态，复制就可以启动并从中断处继续复制，最终再次回到实时状态。
可写副本的注意事项是，如果由于这种情况导致复制失败，您需要修复它或将其销毁或促使副本成为其自己的独立主副本，从而永久地将其与原始主副本分离 - 无法撤消的操作。必须合理及时处理损坏副本的原因是RDS具有防止主机清除其binlog的保护，直到没有托管副本进一步需要它们，这可能导致它们备份到主服务器上，消耗存储空间，或者在破碎的复制品上堆积已保存但未执行的物品，在那里消耗空间。后一种情况更有可能，但前者并非不可能遇到。
作为最后的手段，并且完全未经批准，可以配置不是RDS副本的RDS实例（例如，在它被提升为主副本之后）以连接到另一个RDS实例并从中复制，使用相同的旨在使用mysql.rds_set_external_master从内部部署服务器迁移到RDS的步骤。这为您提供RDS实际上未实现的RDS到RDS复制。
答案 2 :(得分：1)
我们的主要分析数据库拥有大量用户，他们不仅希望读取数据，还希望创建大型派生数据表。在成本方面，这开始变得令人望而却步，当有太多人同时写入大型表时，数据库的速度会降低，这是不可接受的。
要解决此问题，您需要创建主数据库的只读副本（可能会创建一个用于分析，以便他们可以对其进行所有密集的工作）。让分析团队在该只读副本上执行他们需要做的事情，他们可以将结果放在专门为结果创建的另一个数据库中，或者在非高峰时间写入主数据库（应该是单独的imo）
我想要的解决方案是创建一些读/写副本，这样我们的核心数据就会从主服务器复制到一些启用了写入功能的副本，并且每个用户都可以在其中一个副本上工作。 / p>
说实话，我不认为这是解决问题的最佳方法。保持主数据库仅用于写入，保留读取副本以便它们帮助主数据库上的负载，并让分析团队使用自己的只读副本并将结果输出到另一个数据库中。设置多个z的多个读/写复制副本将对数据库上的写操作延迟产生重大影响。
然而，我担心这似乎不是启用复制副本的预期用例。我担心的是用户会在他们的副本上建立大量有价值的数据。如果副本崩溃，我该怎么办？
启用multi-az将确保aws管理数据库的备用数据库，以便在发生错误时准备好转发，但是，请记住，如果您正在执行对延迟敏感的工作，则延迟会显着增加你可能不得不重新考虑你的架构。
但是如果您的副本上有您关心的数据，请将其与 掌握，事情比较困难。你无法启动恢复 副本并重新附加主人，因为你无法附加 现有的复制品，你只能启动新的复制品。
为什么只读副本与主服务器不同步？我的意思是，肯定会发生问题，但是如果它们确实存在，那么您需要担心一个完全不同的问题......请记住，您无法将已升级到主数据库的只读副本附加回现有主数据库。您将不得不再次重新创建只读副本。