gpt4 book ai didi

mysql - RDS 只读副本注意事项

转载 作者:可可西里 更新时间:2023-11-01 06:40:29 24 4
gpt4 key购买 nike

我们聘请了一名实习生,希望他能够处理我们的数据以生成有用的报告。目前我们只是拍摄了一个数据库快照并创建了一个我们授予他访问权限的新 RDS 实例。但由于生产数据库的变化,它几乎立即就过时了。

我们想要的是我们实际数据库的实时(或接近实时)镜像,我们可以让他访问而不用担心他修改任何真实数据或意外地关闭我们的生产数据库(例如通过运行像 SELECT (*) FROM ourbigtable 这样的愚蠢查询或非常慢的连接)。

只读副本是否适合此用途?看起来它至少会保持最新状态,但我不清楚如果只读副本出现故障或数据被意外更改或任何其他潜在责任会发生什么。

我能找到的唯一与此相关的东西 was this SO question这让我有点担心(强调我的):

If you're trying to pre-calculate a lot of data and otherwise modify what's on the read replica you need to be really careful you're not changing data -- if the read is no longer consistent then you're in trouble :)

TL;DR Don't do it unless you really know what you're doing and you understand all the ramifications.

And bluntly, MySQL replication can be quirky in my experience, so even knowing what is supposed to happen and what does happen if there's as the master tries to write updated data to slave you've also updated.... who knows.

如果我们让实习生在未引用的只读副本上使用它,对生产数据库是否有任何风险?

最佳答案

几年来,我们一直在运行生产数据库的只读副本,没有出现任何重大问题。我们所有需要能够运行查询的销售、营销等人员都可以访问副本。它工作得很好,并且大部分时间都很稳定。生产数据库被锁定,因此只有我们的应用程序可以连接到它,只读副本只能从我们的办公室通过 SSL 访问。设置安全性非常重要,因为您将在主数据库上创建所有用户帐户,然后将它们复制到只读副本。

我想我们曾经看到一个只读副本由于硬件相关问题而进入错误状态。只读副本的好处在于,您可以在任何需要/需要的时候简单地终止一个副本并创建一个新副本。只要新副本与旧副本具有完全相同的实例名称,其 DNS 等将保持不变,因此除了短暂不可用之外,一切都应该对最终用户非常透明。一两次,我们还简单地重新启动了一个卡住的只读副本,它最终也能够自己 catch 来。

除了处理从主数据库发送的命令之外,无法通过任何方法更新只读副本上的数据。 RDS 根本不允许您在只读副本上运行插入、更新等操作,无论用户拥有什么权限。因此,您无需担心只读副本上的数据更改会导致与主副本不同步。

如果有人提交长时间运行的查询,副本有时会落后于生产数据库,但通常在查询完成后很快恢复。在我们所有的生产环境中,我们都设置了一些监视器来关注复制并检查长时间运行的查询。我们利用 pmp-check-mysql-replication-delay命令在 Percona Toolkit for MySQL密切关注复制。它通过 Nagios 每隔几分钟运行一次。我们还有一个通过 cron 运行的自定义脚本,用于检查长时间运行的查询。它基本上解析“SHOW FULL PROCESSLIST”命令的输出,如果一个查询已经运行了很长时间,它会发送一封电子邮件,连同运行它的人的用户名和终止查询的命令,如果我们决定我们需要。

有了这些检查,我们在只读副本方面几乎没有问题。

关于mysql - RDS 只读副本注意事项,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25852696/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com