我们公司使用的是亚马逊云AWS,请问如何修改AWS的RDS-MYSQL数据库的默认时区？

您可以通过修改AWS参数组的参数：time_zone修改MySQL的时区。关于如何修改亚马逊AWS参数：AWS参数是动态的，所以修改后立即生效。

对于已经建立的连接，不生效；对于新建立的连接才生效。

如果您创建了只读副本，您可以为主库和读从库设置不同的时区。

如果是从快照恢复数据库，时区将会被设置成UTC

如果是恢复到时间点，时区将会保持和原库一致

25000IOPS。

AmazonRDS，是一种托管服务，可以简化在云中设置、 *** 作和扩展关系数据库的过程。它在管理耗时的数据库管理任务的同时，提供经济高效的可调容量，使您能够腾出时间专注于应用程序和业务。

AmazonRDS可以自动备份您的数据库，并使您的数据库软件版本保持最新。您可以灵活方便地扩展与关系数据库实例相关联的计算资源或存储容量，并从中受益。此外，AmazonRDS还可通过复制轻松增强数据库可用性、改进数据耐久性或扩展读取密集型数据库工作负载中单一数据库实例的容量限制。

最近居然被 MySQL 主从同步的问题坑了, 简直丢尽了老司机的脸, 总结一下.

问题很简单, 一个业务由于 MySQL 主从同步延迟导致读取的数据有问题. 问题解决了, 但如何在 AWS RDS 中获取 MySQL 的延迟信息呢? 非 AWS RDS 的传统 MySQL 中, 可以直接连到 server 通过 SHOW SLAVE STATUS 获取延迟信息.

RDS 呢?

AWS 中大多数(我也不确定是不是所有服务)都接入了 Cloudwatch. Cloudwatch 的好处就是可以作为一个中间层抽象, 将不同系统的数据抽象成一个模型, 统一通过 Cloudwatch API 访问. 就拿主从延迟来说, MySQL/MariaDB 和 PostgeSQL 的计算方法显然是不一样的:

因此, 只要通过 Cloudwatch API 获取 ReplicaLag 这个 metric 的值就可以判断主从同步延迟, 不管是哪种 DB

看上去挺简单的 API, 还是需要"进城手册", 避免挠头:

由于 Cloudwatch 支持的最细颗粒度的 metric 是1分钟, 因此仅仅获取前一分钟的数据可能会有 Cloudwatch 数据还未抓取到的问题.

建议是获取前一段时间(比如10分钟)的数据, 确保前10分钟的 ReplicaLag 都为0(或者小于一个可以接受的值), 则认为现在的状态是满足数据需求的.

MySQL 主从同步从入行就知道是需要重点关注的, 结果还是忽略了一下就掉坑里了. AWS Cloudwatch 也支持根据 ReplicaLag 的值直接告警的, 建议一定要设置一个.

---