本番環境における「パスワードローテーション」という悩み
5,000以上の同時接続を抱えるデータベースに対して、おそるおそる ALTER USER コマンドを実行した経験があるなら、あなたは一人ではありません。定期的なパスワード変更（Password Rotation）はセキュリティ上必須ですが、常にサービス中断のリスクが伴います。
よくあるシナリオはこうです。MySQLサーバー側でパスワードを変更した後、大量のマイクロサービスの構成を急いで更新します。わずか数秒のズレで、システムログは Access denied エラーで埋め尽くされます。結果としてユーザーのリクエストは失敗し、上司から「なぜシステムが落ちているのか」と問い詰められることになります。
以前、Kubernetes上で20以上のサービスが稼働するFintechシステムを管理していました。ローリングアップデートを適用していても、ConfigMapの反映には一定の遅延が生じます。その5〜10秒の隙間が、何百もの決済トランザクションを失敗させるには十分でした。その時、従来のやり方は99.99%の可用性を求めるシステムにはもはや不適切だと痛感しました。
なぜ従来のパスワード変更はエラーを引き起こすのか？
問題は原子性（atomic）にあります。MySQL 8.0.14より前のバージョンでは、一人のユーザーは一度に一つのパスワードしか持てませんでした。変更コマンドを実行すると、古いパスワードは即座に上書きされます。
同期の遅延により、以下の不一致が発生します：
- サーバー側： すでに新しいパスワードに切り替わっている。
- クライアント側（アプリ）： コネクションプールや構成キャッシュ内の古いパスワードを使い続けている。
これを根本的に解決するには、移行期間中にユーザーが新旧両方のパスワードを並行して使用できる仕組みが必要です。
以前のTips：サブユーザーの作成とその煩わしさ
以前は、DBAが同じ権限を持つ一時的なユーザー（app_user_v2 など）を作成するのが一般的でした。アプリが新しいユーザーに安定して切り替わった後、古いユーザーを削除します。
この方法はダウンタイムを回避できますが、管理システムに「ゴミ」が残ります。また、古いユーザーから新しいユーザーへ数十もの権限（Privileges）を手動でコピーするのはミスが発生しやすく、制御困難なセキュリティホールを生む原因にもなります。
MySQL 8 Dual Password：ゲームチェンジャーとなる解決策
