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