AWS实例类型的EOL(End of Life)支持方式

我相信大家都有过这样的经历,亚马逊云服务(AWS)不断更新和引入新的资源,但老旧的资源将逐渐被淘汰,这使得我们只能提升之前已经运行的资源水平。

今年12月1日将有多少种实例类型将被停用?

建议在2022年12月1日之前升级到新一代的节点类型,因为前一代的节点T1、M1、M2、M3和R3将于2022年12月1日停止支持(EOL)。

这一代不仅受到RDS的影响,还受到Elaticache的影响。由于已经消失,因此必须自己进行新一代的更改。

普通的方式

在中国,最容易做出这样的变化是直接改变数据库!AWS是下一代的首选解决方案,并且可以帮助您轻松实现此目标。

Previous Generation Node typeRecommended Node Typecache.m1.smallcache.t3.smallcache.m1.mediumcache.t3.mediumcache.m1.largecache.m5.largecache.m1.xlargecache.m5.xlargecache.m2.xlargecache.m5.xlargecache.m2.2xlargecache.m5.2xlargecache.m2.4xlargecache.m6g.4xlargecache.m3.mediumcache.t3.mediumcache.m3.largecache.m5.largecache.m3.xlargecache.m5.xlargecache.m3.2xlargecache.m5.2xlargecache.r3.largecache.r5.largecache.r3.xlargecache.r5.xlargecache.r3.2xlargecache.r5.2xlargecache.r3.4xlargecache.r5.4xlargecache.r3.8xlargecache.r6g.8xlargecache.t1.microcache.t3.microcache.t2.microcache.t3.microcache.t2.smallcache.t3.smallcache.t2.mediumcache.t3.medium

由于我所使用的是R3数据库,所以应该在R5进行更改。

Screen Shot 2022-11-21 at 20.28.36.png

在进行更改时,当然会发生停机时间,您将无法访问!具体时间取决于数据库的大小。

但是,我想要验证!虽然实例的改变应该不会很大,但是数据库版本变化相当大,但实例确实是硬件,所以没有那么大的差别。

为了进行验证,我们可以创建一个新的r3实例,并将其更改为r5!这就是令人悲伤的地方,我们无法创建旧一代的实例。所以,如果有问题,我们可以将其更改回r3!这也是令人悲伤的地方,一旦变成r5就无法回到r3了。哭泣。

安全的方法 de

回到话题,检查VPC的访问限制和安全组,确认数据库在实例内部。

Untitled Diagram.drawio (1).png

为了确保安全,同时制造旧一代和新一代的产品。

Untitled Diagram.drawio (2).png

然而,如果是在相同的时间点,数据的依赖性会变得更加严重,即使从备份中创建,正在创建中的r5也不是相同的数据。我们需要做更多的工作!问题是,如果有访问旧世代的情况,那是没有意义的。

进行一项任务
三个步骤
用三步来完成

排序和时间

    • 古い世代をアクセス止める。

 

    • バックアップを作成する。

 

    • バックアップから新しい世代を作成する。

 

    新しい世代のアクセスポイントをコードに修正とリリースする。

添加安全组

Screen Shot 2022-11-21 at 20.50.20.png

如果有这样的SG配置,就无法进行访问!只需将TCP设置为0即可解决问题!

访问顺序

一旦您可以确认设置,接下来就是时机的问题!

Untitled Diagram.drawio (4).png
    • 古い世代の今あるSGを外して、no-accessのSGを付けます。

 

    • アクセスが出来なくになった、バックアップを作成する。

 

    • バックアップ終われば、そのバックアップからインスタンスを作成する。

 

    新しい世代のエンドポイントARNをコード修正して、サーバーへのリリースする。

由於畫面操作會變得很緩慢,所以我們將使用AWS CLI進行SG的變更!

aws elasticache modify-replication-group --replication-group-id <redis cluster名前> --security-group-ids sg-XXX (no-accessのSG id
aws elasticache modify-cache-cluster --cache-cluster-id <memcache cluster名前> --security-group-ids sg-XXX (no-accessのSG id
aws rds modify-db-cluster --db-cluster-identifier <RDSのDB名前> --vpc-security-group-ids sg-XXX (no-accessのSG id

不同的服务会导致命令的变化。无论是哪个服务,安全组都没有问题,只需注意VPC即可。

我很惊讶地发现,Elasticache有两种选项,分别是Redis和Memcache,但是操作方式不同,Redis需要更改复制组(replication-group),而Memcache需要使用修改缓存集群(modify-cache-cluster)。

得出结论

使ってるシステム次第でやり方が変わるので自分で決めるしかないです。この記事を書いた時はまだお試しでやってましたですが、やっと本番をやったらちょっと気をつけるべきものもありました!

如果给SG添加了no-access,则无法建立新的连接,但仍然保持连接的服务器仍在运行中!只能自行断开连接了。

断开连接的方法

mysql/aurora :

mysql -h <エンドポイント> -p -u <ユーザー> mysql -s -e "SELECT GROUP_CONCAT(ID) FROM information_schema.PROCESSLIST WHERE USER = '<ユーザー>';"
GROUP_CONCAT(ID)
1765260,1765256,1669793,1445918,1720350,1720349,1669739,1720368,685452,685365

これはコネクションのプロセスリストです。リストあったらプロセスをkillするべきです。

mysqladmin kill 1765260,1765256,1669793,1445918,1720350,1720349,1669739,1720368,685452,685365 -h <エンドポイント> -p -u <ユーザー>

redis

RedisはまだRDSと違って、一時的な再起動など出来ません。Multi-AZこクラスタあったら出来ます。

一旦マインのノードをfailoverして、failoverが無事に終わったらこの2番目のノードを再起動すれば、マインのノードに戻るし、コネクションもなくなります。

大注意!
マインのノードを再起動すれば、データが消えます!確かにコネクションなくなるけどデータもなくなります。

结束。

广告
将在 10 秒后关闭
bannerAds