我们聘请了一名实习生，并希望让他利用我们的数据来生成有用的报告。目前我们只是创建了一个数据库快照并创建了一个我们授予他访问权限的新RDS实例。但由于生产数据库的变化，这几乎立即过时了。
我们想要的是我们实际数据库的实时（或接近实时）镜像，我们可以让他访问，而不必担心他修改任何真实数据或意外地关闭我们的生产数据库（例如通过运行一个愚蠢的查询，如SELECT (*) FROM ourbigtable或一个非常慢的连接。）
只读复制品是否适用于此目的？看起来它至少会保持最新状态，但我不清楚如果读取副本发生故障或数据意外更改或任何其他潜在的责任会发生什么。
我唯一能找到与此was this SO question有关的东西，这让我有点担心（强调我的）：
如果您正在尝试预先计算大量数据并进行其他修改 什么是阅读副本你需要非常小心，你不是 更改数据 - 如果读取不再一致，则表示您已进入 麻烦：）
TL; DR除非你真的知道你在做什么，否则不要这样做 了解所有后果。
直言不讳地说，根据我的经验，MySQL复制可能很奇怪 知道应该发生什么以及发生了什么如果有的话 主人试图将更新的数据写入奴隶 更新....谁知道。
如果我们让实习生在未引用的只读副本上有生产数据库，是否有任何风险？
答案 0 :(得分：11)
我们已经运行了几年的生产数据库的只读副本，现在没有任何重大问题。我们所有需要运行查询能力的销售，营销等人员都可以访问副本。它工作得很好，而且大部分都很稳定。生产数据库被锁定，以便只有我们的应用程序可以连接到它，并且只能通过我们办公室的SSL访问只读副本。设置安全性非常重要，因为您将在master数据库上创建所有用户帐户，然后将它们复制到只读副本。
我认为由于与硬件相关的问题，我们曾经看过一个读复制品陷入了糟糕的状态。关于read-replicas的好处是，你可以随时终止一个并在你想要/需要的时候创建一个新副本。只要新副本具有与旧副本完全相同的实例名称，其DNS等将保持不变，因此除了暂时不可用之外，对于最终用户来说一切都应该是非常透明的。有一两次我们也只是重新启动了一个卡住的读取副本，它最终能够自己赶上。
除了处理从master数据库发送的命令之外，任何方法都无法更新只读副本上的数据。无论用户拥有什么权限，RDS都不允许您在读取副本上运行类似插入，更新等的操作。因此，您无需担心读取副本上的数据更改，从而导致事物与主服务器不同步。
如果某人提交了一个长时间运行的查询，有时候副本可能会稍微落后于生产数据库，但是一旦查询完成，它通常会很快收回。在我们所有的生产环境中，我们都设置了一些监视器来监视复制并检查长时间运行的查询。我们使用pmp-check-mysql-replication-delay中的Percona Toolkit for MySQL命令来关注复制。它通过Nagios每隔几分钟运行一次。我们还有一个通过cron运行的自定义脚本，用于检查长时间运行的查询。它基本上解析“SHOW FULL PROCESSLIST”命令的输出，如果查询已经运行了很长一段时间，并发送一封电子邮件，同时运行它的人的用户名和命令，如果我们杀了查询决定我们需要。
通过这些检查，我们对read-replicas的问题几乎没有。
答案 1 :(得分：0)
MySQL复制的工作方式是在从属服务器上发生的事情对主服务器没有影响。
复制从属服务器询问主服务器上发生的事件的历史记录，并将其本地应用。主机永远不会在从机上写任何东西：从机从主机读取并自己写。如果从属服务器无法应用从主控服务器读取的事件，它将停止并显示错误。
这种数据复制方式的问题在于，如果您修改从属服务器，然后再修改主服务器，则从属服务器上的值可能与主服务器上的值不同。可以通过打开全局read_only变量来避免这种情况。