オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ

こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした（幸いすぐにキャンセルして事なきを得ました）。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確

[theatrical]

"本番環境で実行する前に社内のステージング環境に対して同じ ALTER 文を実行していますが、トラフィック量の差から問題になることはありませんでした" そう言うの気づきにくいよな。

[strawberryhunter]

ALGORITHM=INPLACE, LOCK=NONEで検証できるんだな。／なんかもう弊社では常に末尾に追加するようになってるけど本番環境の列順がめちゃくちゃなのでレコード数も考慮してafterで列順の指定を入れようかと思ってる(優先度極低)。

[ka-ka_xyz]

昔々、alter tableするときに裏でテーブル内データをまるっとコピーするRDBMSがあって、さらにそのテーブルには（本番環境のみ）大量のlobが入っていて、結果としてコピーが完了するまで数日間更新不能になったことがある

[syu-m-5151]

本番と同じ環境を用意するのめちゃくちゃ難しいのでこういうの気付きにくいよなぁ...知見をためていくしかない

[efcl]

オンライン DDL を期待した ALTER 文が詰まる問題

[havanap]

すばらしい知見

[shingo-sasaki-0529]

こういうの見ると、本番同等のデータを持つステージングほしいよなぁ。このケースだとデータ量だけじゃなくてリクエストも本番同等でなきゃダメそうだけど。

[ya--mada]

長らくDBを触っていないので知識が古くなり過ぎているオレ。レプリカを作るところから準備を始めるとか、考えなくてよいのだな。

[kagehiens]

ステージング環境では何のためにテストしたのか。

[secseek]

本番止めずにAlter文流したくないんですけど、そういう要件は珍しくないんでしょうか…

[uzuki-first]

面白かった、オンラインDDLを検証できるの知らなかった。/これ、僕が匿名化DB生成ツールを作ろうと思った事故と同じだ、こういうトラブルを検知するために作った。https://github.com/kibitan/masking スライド: https://bit.ly/472zDzc

[lizy]

列を追加する際に順序を気にしてなかった。MySQL開発側も末尾追加のユースケースが大半と想定していたのかな

[stefafafan]

Generated Columnが存在していたから、なるほど

[kubecorn]

似たようなことで過去にやらかしかけたので、親近感が湧くという意味で好きのブクマ。

[unfallen_castle]

なるほど、事前に気づきにくい罠だ

[tumo300-500]

知見〜！

[knjname]

5は知らないが8のオンラインDDLは INSTANT > INPLACE > COPY の順で悪くなる / INPLACEでもINSERTのコンフリクトとか起こされると失敗するんだよなあ

[dominion525]

ぼくも「オンライン DDL を期待して ALTER 文を実行したら障害に"なった"話」あるなー。状況や原因もほぼ同じかなー、usersテーブルだし、ステージングで分からなかったのも。涙目で対応したけど。

[toricls]

ステージング環境の本番同一性をどうすればもっと高く持てるかについてより深く考え始めるきっかけになりました

[integrated1453]

良い知見共有。オンラインDDLが可能な条件を都度判断するのが難しくて、安全側に寄せてメンテナンス作業でALTERしてる会社も多いはず。しっかりドキュメント読んで事前検証すれば平日日中に作業できることも増えるのね