7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

RDS(MYSQL5.6)の Security Advisory について

Posted at

RDS(MySQL) 使っているなら、AWS からメールでなんだこれ、いきなりやーと阿鼻叫喚な先月から立て続けにあるイベント。
ほんとため息しかでない。
ちなみに、先月のメンテ( Xen の脆弱性対応)と違い、今回は MySQL 自身のアップデート。
で、今の状況整理。

MySQL5.5(5.5.40)についてのアップデートメンテは完了。

MySQL5.5(5.6.21)につては、以下の公式フォーラムで"無制限アクセスを許可していない MySQL 5.6 インスタンス"のメンテは延期されている。

Discussion Forums

以下抜粋


無制限アクセスを許可していないMySQL 5.6 インスタンスに関して、当初日本時間2014年10月21日早朝のアップグレード開始を予定しておりました。しかし、特定の条件において、MySQL 5.6リードレプリカが、5.6.21 へのアップグレード後にクラッシュする可能性があることが判明し、アップグレード開始を見合わせて頂きました。この問題は、下のページで記述されているMySQL 5.6.4で導入されたdate型やtimestamp型のカラムの格納フォーマットに関連しています。
https://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html

このフォーマット変更のため、 5.6.4 より前のバージョンで稼動している(もしくはそれらのバージョンからアップグレードされた)マスタから、date型やtimestamp型のカラムを変更する 行ベースログのトランザクション を 5.6.21 のリードレプリカが受信した際に、リードレプリカがクラッシュをする可能性があります。対応方法を含む、詳細につきましては、下のページにある "Known Issues and Limitations" をご覧ください。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.KnownIssuesAndLimitations

また、MySQL 5.6.20より始まった blob のログ出力方法との非互換性を考慮し、12.8MB 以上のサイズの blob を変更する場合には "innodb_log_file_size" パラメータを 変更する blob の最大サイズの 10 倍に調整する必要があります。この変更の詳細につきましては、下のページをご覧ください。
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html


で読んでみたけどよくわからん、今回の延期はなんで?


・延期理由1
とりあえずリードレプリカがぶっ壊れる。
これはもともと MySQL5.5 を使用していて、その後 MySQL5.6 へアップグレートしたもので発生。
Why?
→MySQL 5.6.4 で導入された date 型や timestamp 型のカラムの格納フォーマットの違い。
 ようは小数部の扱いやTime フォーマットの違いで発生。

しかし、発生する可能性は低いんじゃないか。
*これ試していないけど、binlog の V1 を使うことでなんとかならんのかな?

 
・延期理由2
アップグレードしたらストレージが一杯。
これは兼ねてよりあった checkpoint が上書きされる Bug の修正に対応したものだろう。
RDS 側で自動的に対応
→既存 max allow packe の10倍の数値を innodb_log_file_size に設定。
(AWSからメールで変更したよと連絡あり。)
これは、ようは max allow packe に収まるクエリなら、checkpoint 処理で上書きされることを回避できるだろうという理由だろう。

で例えば max allow packe を 1GB にしてたら、勝手に innodb_log_file_size が 10GB に。
この数値はなんかよくわからないけど、だめだろうと思う人がほとんどだろう。ええほんとうに・・。

以下影響あること。

・Crashrecovery がクソながくなる。
Choosing proper innodb_log_file_size
古いversionだけど、あれからCrashrecoveryのスピードが上がっても時間がかかるものはかかる。
1GB per 10 minutes of recovery time

・redo_log の flushing に間接的に関係してくる。
innodb_adaptive_flushing_lwm

昔運用していた MySQL は、水平分割してたとはいえ、100万 DAU のソーシャルゲームでも 512MB で余裕。


7
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?