AWSでPostgreSQLを前から使っている方はアップグレードメンテナンスが必要です

AWSのサポートからこんなメールが届きました。

Dear Amazon RDS Customer,
A system update is now available for any Amazon RDS PostgreSQL database instances you created before 13 October 2015. We recommend installing this update to take advantage of several performance improvements and security fixes. You may choose to install this update immediately, or during your next scheduled maintenance window. After approximately six weeks, your RDS instance will be automatically upgraded during your maintenance window. To learn more about scheduling or installing an upgrade, please refer to the RDS documentation: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.OSUpgrades.html.
Installing this update will have an availability impact for a few minutes on your RDS instance (60-120 seconds for Multi-AZ instances). To reduce downtime, you may consider converting your Single-AZ instances to Multi-AZ. If you have any questions or concerns, please contact your TAM or AWS Support.
Sincerely,
The Amazon RDS Team
Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210

同様の内容がフォーラムにも投稿されています。

2015/10/13 より前に作成したPostgreSQLインスタンスは、セキュリティ修正と少々のパフォーマンス向上のために、アップデートを適用しなければいけないそうです。
アップデートにはダウンタイムが発生するため、DBを利用中のアプリケーションが停止してしまいます。
Multi-AZの場合は、AZ切り替えに必要な時間である1〜2分程度のダウンで済むそうですが、Single-AZの場合はどうなんでしょう…メールには記載されていませんが、再起動が行われそうな気がするので、通常のRDSインスタンス再起動と同程度かそれ以上のダウンが発生すると考えておいて良いと思います。

メンテナンスは以下のスケジュールから選択できるようです。

  • 猶予期限内で任意のメンテナンスウィンドウ
  • 即時（手動）
  • 猶予期限が切れた直後のメンテナンスウィンドウ

猶予期限は「After approximately six weeks」と書いてあるので、おそらくフォーラムの投稿日である1月15日から6週間くらいだと思います。サポートに入っている人は確認してみてください。

メンテナンス実施の手順は、前回のMySQLのメンテナンスの時の内容を記事にしてくださっている方がいらっしゃいましたので、その記事を参考にしたいと思います。
[AWS] RDS の OS アップグレードのメンテナンスを実施する。 | LexTech http://tech.lexues.co.jp/archives/1864

さて、自分が管理しているRDSインスタンスを確認したら、確かに対象のインスタンスの「メンテナンス」列が「必須」に変更されていました。


上記４つのインスタンスは全部PostgreSQLですが、一番下の最近作ったやつだけメンテナンス対象外になっています。

運用中のアプリによってはダウンタイムの調整に時間がかかるかと思いますので、事前にしっかり確認して対応していきましょう…と自分に言い聞かす。

コメント

コメントを投稿

このブログの人気の投稿

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

イメージ
一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。
続きを読む

[AWS] WAF を自分で組み立てるなら SAM でテンプレート書いた方が楽だよ

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に
続きを読む

[#CentOS][#Apache] CentOS6 でApacheが起動できない

CentOS 6 で httpd を起動させようとした時のこと $ sudo /etc/init.d/httpd start httpd を起動中: httpd: bad user name apache    [ 失敗 ] なんじゃこりゃ。 ■問題 Apacheが起動できない。問題はapacheユーザ ■原因 httpd.confには ユーザ：apache グループ：apache　でhttpdを起動するようになっている。 ユーザとグループを確認してみよう… $ cat /etc/passwd | grep apache $ ユーザが居ない… $ cat /etc/group | grep apache apache:x:48: グループはある。なんでこうなってんだ？ ■対処 ユーザ「apache」を作ってグループ「apache」に入れてあげよう。 # useradd -g apache apache useradd: /etc/passwd をロックできません。後でもう一度試してください。 は？(#ﾟДﾟ) # ll /etc/*.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/passwd.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/shadow.lock これを消すか # rm /etc/passwd.lock rm: remove 通常ファイル `/etc/passwd.lock'? y # rm /etc/shadow.lock rm: remove 通常ファイル `/etc/shadow.lock'? y これでもう一度apacheをuseraddして…あれ、もしかしてロックファイルがApahceをインストール剃る前からあって、もしかしてyumのインストールシーケンスの中でユーザ作成だけ失敗してたりしてるのかな？ ということでApacheをインストールし直す方向で。 # yum remove httpd $ sudo yum install httpd httpd-devel mod_wsgi Pythonの勉強したいからmod_wsgiも入れてます。 で、yum入りました。 Transaction Summary
続きを読む