Aurora RDS MySQL 5.6.10a (1.14.1) 升级到 5.7 (2.x) 并最终升级到 8.0 。

0

【以下的问题经过翻译处理】 你好,

我在RDS上拥有一个8TB的Aurora MySQL数据库,并有2个只读副本。当前数据库引擎版本是5.6.10a(1.14.1)。

实例: db.r3.2xlarge db.r3.2xlarge db.r3.xlarge

我想将其升级至至少1.22.3,以便根据此文档(https://aws.amazon.com/blogs/database/performing-major-version-upgrades-for-amazon-aurora-mysql-with-minimum-downtime/)通过绿蓝升级过程将其升级至5.7(2.x)。

我想知道从1.14.1升级到1.22.3是否会是磁盘密集型操作,还是纯粹的“软件更新”?

我找不到任何文件指示两者之间的不同,我不敢启动无法取消的操作,并在过程中使我们的生产环境停机数小时/数天。

是否最好创建克隆版本并升级克隆版本以获得合理的升级时间判断?(忽略它上面没有负载,可能并不是速度的准确表示)

非常感谢!

1 Antwort
0

【以下的回答经过翻译处理】 嗨mshussein,

与主要版本(从1.x到2.x,以及从2.x到3.x)升级不同,从1.14.1升级到1.22.3不会是磁盘密集型操作,因为它是一个小的升级版本。顺便说一下,最新的补丁版本目前是1.22.5,我建议使用1.22.5而不是1.22.3,因为它修复了其他一些错误。

但是,虽然小的升级版本不会进行磁盘数据文件变化,但它包括停机时间,每当停止并启动MySQL数据库时,数据库将执行启动过程(在崩溃恢复期间也是如此),这需要更长的时间,活动会话和读取视图在数据库中打开。我建议在启动任何升级程序之前,您应该连接到数据库并执行以下操作:

  • 使用此处描述的过程检查历史列表长度(HLL不应超过几千)。
  • 通过运行“SHOW PROCESSLIST;”或查看您的实例是否激活了Performance Insights,检查是否存在长时间运行的活动会话(特别是写会话,如DCL、DDL和DML)。

在没有活动事务、活动会话和catched-up清除的集群中,整个小的升级程序通常需要几分钟,但其停机时间通常不到一分钟。

但是,我仍然建议首先在从快照或克隆还原的集群中测试整个过程,文档中也提到了这一点。

profile picture
EXPERTE
beantwortet vor 8 Monaten

Du bist nicht angemeldet. Anmelden um eine Antwort zu veröffentlichen.

Eine gute Antwort beantwortet die Frage klar, gibt konstruktives Feedback und fördert die berufliche Weiterentwicklung des Fragenstellers.

Richtlinien für die Beantwortung von Fragen