Macのbrewを使ったeksctlインストールは非推奨に！安全なインストール方法
saratogax
サラトガ牧場
Aurora MySQL の ALTER で Reader が「Table doesn’t exist」を返す不具合｜発生条件と回避策
saratogax
記事内に商品プロモーションを含む場合があります
Aurora MySQL 3 系で ALTER TABLE を実行したあと、アプリケーションから Table ‘xxx’ doesn’t exist というエラーが返ってきたことはないでしょうか。
テーブルは確かに存在しているのに、Reader（リーダーインスタンス）経由の参照だけが失敗する現象です。
私も本番環境でこれを踏みました。
そして2026年7月30日にリリースされた Aurora MySQL 3.10.5 のリリースノートで、この不具合の発生条件が具体的に明記されました。
ただし後述するとおり、同じ症状に対する修正記載は過去のバージョンにも複数あり、リリースノートを読むだけでは「自分のケースが直っているか」を判断しきれません。
この記事では、リリースノートから読み取れる発生条件と、調査時に必ずハマる「DB のエラーログに 1146 が出ない」という落とし穴、そして回避策を整理します。
あわせて後半では、LTS（長期サポート）版である 3.10.x にステイするか、より新しい 3.11 / 3.12 系へ動くかの判断材料もまとめました。
Contents
3.10.5 で明記された発生条件
まず結論となる 3.10.5 のリリースノートの記述を見てください。
Fixed an issue where the reader reports ERROR 1146 (table not found) during certain online DDL operations on the writer when using the INPLACE algorithm. This can occur when either the reader has not previously opened the table before the DDL begins, or the reader restarts or a new reader is created while the DDL is in progress.
ここから読み取れる発生条件は次のとおりです。
- Writer で ALGORITHM=INPLACE の online DDL を実行している
- かつ Reader が DDL 開始前にそのテーブルを一度も開いていない
- または DDL 実行中に Reader が再起動する、新しい Reader が作成される
「Reader がテーブルを一度も開いていない」が条件に入っているのが重要です。
これはALTER の合間に Reader を参照しておくという回避策が効く理由の裏返しになっています。
参照を一度入れておけばテーブルが開かれた状態になるので、条件から外れるわけです。
逆に言えば、しばらく参照されていないテーブルに重い ALTER をかけるケースが最も危険ということになります。
DB のエラーログに 1146 は出ない
この事象を調査するときに知っておきたいのが、エラーの見え方が 2 種類あることです。
アプリケーション側には、SQL 層のエラーとして ERROR 1146（Table ‘xxx’ doesn’t exist） が返ります。
一方 CloudWatch などで見る DB のエラーログには、InnoDB 層の別のメッセージが記録されます。
[Warning] [MY-012382] [InnoDB] Cannot open table your_database/your_table Please refer to http://dev.mysql.com/doc/refman/8.0/en/innodb-troubleshooting.html for how to resolve the issue. (ha_innopart.cc:837)
ここが調査の落とし穴でした。
1146 はクライアントへ返す応答なので、DB のエラーログには残りません。
私も当初 DB のエラーログを Table doesn't exist で検索してしまい、見つからずに戸惑いました。
DB 側で探すなら MY-012382 または Cannot open table をキーにしてください。
なお末尾の ha_innopart.cc はパーティションテーブル用のハンドラなので、対象がパーティションテーブルだったことがここから分かります。
ただし 3.10.5 のリリースノートに、パーティションへの言及はありません。
ところが後述する第三者の検証では、パーティションテーブルかどうかで、修正が届いたバージョンが分かれています。
リリースノートの文面だけを読んでいると、この違いには気づけません。
もう一点、成功した DDL は MySQL のエラーログには残りません。
「Writer 側に ALTER のログがないから DDL は無関係」とは判断できないので、DDL の実行時刻はマイグレーションツールの履歴テーブルや binlog で追う必要があります。
マイグレーションファイルを分けると条件を踏みやすい
私が遭遇したケースでは、同じテーブルへのカラム追加を 2 つのマイグレーションファイルに分けて実行していました。
2000 万レコードほどのテーブルだったため、DDL 1 本あたりの実行時間は 6 分から 7 分ほどかかっていました。
Flyway の履歴テーブルから、それぞれの実行区間を割り出したものが以下です。
| DDL | 開始(逆算) | 実行時間 | 完了 |
|---|---|---|---|
| 1 本目 | 02:10:00 | 約 7 分 | 02:17:00 |
| 2 本目 | 02:17:00 | 約 6 分 | 02:23:00 |
ここで注意したいのが、flyway_schema_history の installed_on は実行開始ではなく完了日時だという点です。
開始時刻は execution_time を引いて逆算する必要があります。
そしてエラーが発生したのは 02:20 頃で、2 本目の DDL 実行区間のただ中でした。
注目したいのは、1 本目の完了と 2 本目の開始がぴったり連続していることです。
この間に Reader からの参照が入る余地がありませんでした。
つまり「DDL のあと Reader 参照を挟まないまま次の DDL を実行し、その実行中に Reader が参照した」という流れになっていたわけです。
これは前述の発生条件そのものです。
1 ファイル・1 ステートメントにまとめていれば DDL は 1 回で済み、「DDL の直後に次の DDL が始まる」という状況自体が発生しませんでした。
マイグレーションファイルを細かく分けるのは変更履歴として綺麗ですが、同一テーブルへの重い DDL に限っては、まとめたほうがリスクが下がります。
同じ症状の修正が何度も入っている
ここで一つ注意したい点があります。
この症状の修正は、3.10.5 が初めてではありません。
2026年2月リリースの 3.12.0 に、同じ症状の修正記載があります。
Fixed an issue, which in rare cases, caused intermittent unavailability of an Aurora Read Replica or table definition inconsistencies with error ‘Table does not exist’ on the replica due to concurrent read queries on the replica and DDL operations on the writer.
さらに遡ると、2024年11月18日リリースの 3.08.0 にもほぼ同一文言の記載があります。
Fixed an issue that, in rare cases, caused either intermittent unavailability of an Aurora read replica or table definition inconsistencies, sometimes with the error Table does not exist, on the replica. This is due to concurrent read queries on the replica and Data Definition Language (DDL) operations on the writer DB instance.
条件（Reader での read と Writer での DDL の同時実行）も症状（Reader での Table does not exist）も一致しており、実質同じ内容です。
つまり 3.08.0 で一度修正されたが取りきれておらず、3.12.0 と 3.10.5 で再度修正されたという経緯に見えます。
実際、私が踏んだのは 3.08.0 の修正が入ったあとのバージョンでした。
同種の前例もあります。
freee さんと CyberAgent SRG の記事では、3.04.1 で発見された同じ事象が、リリースノートで修正扱いになった 3.04.2 でも再現したと報告されています。
リリースノートに「修正した」と書かれていても、同じ症状で再度修正が入る可能性は残ります。
複数のパターンが存在する
この点については、私が事象に遭遇した際に AWS サポートへ問い合わせています。
詳細な内容は控えますが、この症状には複数のパターンが存在し、一部は修正されたものの、発生するパターンが残っているという趣旨の回答でした。
あわせて、リリースノートから判断できない場合はその時点での修正状況をサポートへ問い合わせてほしいとの案内もありました。
つまり、リリースノートに「修正済み」と書かれたバージョンへ上げたとしても、自分が踏んでいるパターンが直っているとは限りません。
3.10.5 の記述は発生条件が具体的で信頼したくなりますが、私自身まだ検証できていないため、これで解決すると断言はできない状況です。
アップグレードで対応する場合も、次に挙げる回避策を併用しておくほうが安全だと私は考えています。
そして判断に迷ったら AWS サポートに確認するのが最短です。
第三者の検証では 3.12.0 で再現、3.10.5 で解消
私自身の検証はこれからですが、この不具合を実機で確かめた検証記事が公開されています。
2026年8月3日に CyberAgent SRG から公開されたもので、先ほど挙げた 3.04.2 の記事と同じ組織による続報にあたります。
検証手順は「1 本目の DDL 完了後、Reader へ SELECT を挟まずに 2 本目の DDL を実行し、その実行中に Reader から SELECT する」というものです。
私が本番で踏んだ経路と、ほぼ同じ形ですね。
報告されている結果は次のとおりです。
- パーティションでないテーブルは、3.08.0 の時点で解消していた
- パーティションテーブルは、3.12.0 でも再現した
- 3.10.5 では、パーティションテーブルでも再現しなかった
- Aurora MySQL 8.4.7 でも再現しなかった
3.10.5 での検証結果は、記事中でこう書かれています。
2回目のDDL実行中にリーダーエンドポイントにSELECTしてもエラーが出ません！
注目したいのは、修正記載が先に出た 3.12.0 のほうで再現しているという点です。
リリースノートに修正と書かれていても条件次第で残る、ということを示す実例になっています。
そして分かれ目になっていたのがパーティションの有無でした。
これは AWS サポートから受けた「複数のパターンが存在し、一部が残っている」という回答とも噛み合います。
私のケースでエラーログに ha_innopart.cc が出ていたことを踏まえると、残っていたパターンを踏んでいた可能性が高そうです。
ただしこれはあくまで他社環境での検証結果です。
テーブル構成も DDL の内容も環境ごとに違うので、アップグレードを判断する前にご自身の環境で確かめることをお勧めします。
私も実際に上げるときは、この結果を鵜呑みにせず自分で再現テストを行うつもりです。
アップグレード以外の回避策
すぐにバージョンを上げられない場合の回避策も整理しておきます。
- ALGORITHM=COPY を明示指定する — 発生条件が INPLACE なので外せます。ただし実行時間とディスク使用量は増えます
- pt-online-schema-change を利用する — 導入コストはかかりますが、大きなテーブルでは選択肢になります
- DDL の前に Reader で対象テーブルを参照しておく — 「Reader がテーブルを開いていない」条件から外します
- 同一テーブルへの DDL は 1 ステートメントにまとめる — 危険な時間帯そのものを短くします
あわせて、DB のエラーログに対して MY-012382 や Cannot open table でモニターを張っておくと、次に踏んだときの切り分けが速くなります。
LTS の 3.10.x にステイするか、3.11 / 3.12 へ動くか
ここまでの経緯には、LTS 運用そのものの論点が含まれています。
今回の不具合に関する修正記載は、3.12.0（2026年2月）で先に登場し、LTS 系の 3.10.5 に届いたのは 2026年7月30日でした。
約 5 ヶ月のタイムラグがあります。
LTS は「安定性」と引き換えに、新機能もバグ修正も到達が遅いという性質があります。
この 5 ヶ月をどう捉えるかが、ステイするか動くかの判断の核心になります。
3.10.x (LTS) 系のサマリー
LTS（長期サポート）版である 3.10.x 系統は、MySQL 8.0.42 をベースにした「安定性の決定版」です。
3.10.3（2026年1月2日リリース）では、通信暗号化時の CPU 負荷軽減や監査ログの信頼性向上といった、運用に直結する重要な修正がしっかりバックポートされています。
新機能の追加は控えめですが、その分「予期せぬ挙動の変化」が極めて少なく、一度構築したシステムを長く安心して使い続けたいプロジェクトにとって、今なお最も信頼できる選択肢です。
2026年3月30日、3.10.4 がリリースされました。 新機能はなく、可用性に関わるバグ修正が中心です。特に以下の修正が含まれています：
- ライター巻き込み再起動の修正 — Write Forwarding（ローカル・グローバル）が有効な環境で、リーダー再起動がライターの再起動を誘発することがあった問題を修正
- ZDR (Zero-downtime Restart) の修正 — Global Write Forwarding 有効化後の初回 ZDR で既存接続が維持されなかった問題を修正
- ロックテーブル満杯による再起動の修正 — セミコンシステント読み込み中にロックテーブルが満杯になるとインスタンスが再起動する問題を修正
Write Forwarding を利用している環境では、3.10.3 から 3.10.4 へのアップグレードを優先的に検討してください。
そして最新の 3.10.5（2026年7月30日）が、本記事で扱った DDL 不具合の修正記載を含むバージョンです。
3.11.x 系のサマリー
3.11.x 系統は MySQL 8.0.43 互換となっており、LTS から一歩踏み込んだ機能強化が行われています。
特に、AWS Lambda 呼び出し時のタイムアウト設定が可能になったことや、64TB を超えるような超巨大ボリュームでの S3 エクスポート速度の最適化など、特定の高度なユースケースに応える内容が中心です。
その他にも、Serverless v2 のメモリ管理や長時間トランザクション時の安定性向上が図られていますが、多くのプロジェクトにとっては「あれば嬉しいが、必須ではない」という機能が多いため、LTS から移行する決定打としては少し弱い印象です。
3.12.0 のサマリー
最新の 3.12.0（MySQL 8.0.44 互換）は、パフォーマンス改善に意欲的です。
数 TiB クラスの巨大 DB における再起動時間の短縮や、特定の書き込み負荷時の IOPS 向上など、大規模環境で恩恵を受ける修正が目立ちます。
そして前述のとおり、本記事で扱った DDL 不具合の修正記載が LTS より 5 ヶ月早く登場したバージョンでもあります。
ただし前述の第三者検証では、パーティションテーブルに限り 3.12.0 でも再現したと報告されています。
この不具合を理由に 3.12.0 へ動くという判断は、成り立ちにくそうです。
3.10, 3.11, 3.12 の比較まとめ
| 比較項目 | 3.10.5 (LTS) | 3.11.1 | 3.12.0 (最新) |
|---|---|---|---|
| MySQL互換性 | 8.0.42 | 8.0.43 | 8.0.44 |
| 運用のスタンス | 安定性と保守を最優先 | 特定の新機能が必要な場合 | 性能と最新修正を追求 |
| 主なメリット | 長期サポートの安心感 Write Forwarding 関連の再起動問題を修正（3.10.4） INPLACE DDL 時の Reader 1146 エラーに修正記載（3.10.5） 同エラーは第三者検証でも解消を確認 | Lambda連携の柔軟性向上 | 巨大DBの再起動高速化 DDL 不具合はパーティション表で再現の報告あり |
| バグ修正の到達速度 | 遅い（DDL 不具合は 3.12.0 の約 5 ヶ月後） | 早い | 最も早い |
| サポート期間 | 長期 (LTS) | 短期（次のLTSまで） | 短期（次のLTSまで） |
まとめ：バージョンに頼りきらず回避策を併用する
この不具合について、私の現時点の結論は「アップグレードは進めつつ、それだけに頼らない」です。
同じ症状の修正記載が 3.08.0・3.12.0・3.10.5 と繰り返し登場している以上、バージョンを上げただけで安心はできません。
実際、第三者の検証では 3.12.0 の修正記載後もパーティションテーブルで再現しています。
重い DDL を流すときは、ALGORITHM=COPY の指定や DDL 前の Reader 参照といった回避策を併用するのが確実です。
そして自分のケースが直っているか判断できないときは、AWS サポートに確認するのが最短です。
バージョン選択については、多くの環境では 3.10.x 系の LTS を維持しておくのが低リスクだと考えています。
3.11 / 3.12 の新機能は、多くのプロジェクトにとって「必須」とは言いにくい内容です。
短期サポートである以上、いずれ次の LTS へ移る作業も発生します。
ただし今回のように、修正の到達が LTS では数ヶ月遅れることは覚悟しておく必要があります。
回避策の運用コストが高すぎる、あるいは巨大 DB の再起動高速化のような性能面のメリットが必要な場合は、3.12.0 を検証する価値があります。
その際はブルー/グリーンデプロイメント等を使って、実際のワークロードで挙動が変わらないかテストしてみることをお勧めします。
Aurora MySQL の最新メジャーである 8.4 の GA 情報や、RDS for MySQL 8.0 のサポート終了への対応も、あわせて参考にしてください。
あわせて読みたい
Aurora MySQL 8.4 が GA。Aurora 利用者目線でリリースノートを読み解く
あわせて読みたい
RDS for MySQL 8.0 サポート期限切れ後の分岐｜課金か強制アップグレードかは設定で決まる
ABOUT ME
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
