ようで、でもちょっと違う微妙な構成にも徐々になれてきたでしょうか。環境が手元にないと簡単な検証を行うにも困ってしまいますね。触ってみたいけど環境がなくて...という読者の方は、このメルマガで少しでも雰囲気を味わっていただければ幸いです。インスタンスのアラートログから以下のメッセージを拾い上げました。処理時間が延びてしまう可能性があるということでしょうか。transactionalモードで停止します。データベースインスタンスを停止する場合には以下のオプションがあります。オプションが指定された場合の動作については、マニュアルに以下のような説明があります。開始は許可されません。接続されているすべてのクライアントが切断されます。場合と同じように停止します。手順は必要ありません。体が終了しないということになります。これに従わざるをえません。サーバのメンテナンスなどのシーンで使われるはずです。思ったら、まだインスタンスが切り替わっていなぁ~い!!ということになってしまうかもしれません。ところで読者のみなさんの環境ではサーバメンテナンスでインスタンスを停止する場合は、どのようにしているでしょうか。させ、実行中のトランザクション処理についてもロールバックさせるなどの対応をされているのではないでしょうか。いえどもやはりいつまでもトランザクションの終了を待ちたくはありません。30)」ということで、どうやら上限を設定することができるようです。分で再度確認してみます。分に対しては影響がありません。間隔を設定するようにしたところです。これで、「移行終了までの最大時間」までにトランザクションが終了しなかった場合にどうなるのかを確認できます。標準出力に以下のようなメッセージが表示されました。変わったタイミングでデータが欠損してしまいました。アラートログを確認して時系列と挙動を確認してみましょう。モードでインスタンスの停止が始まっています。待機している様子がみえます。方も確認しておきましょう。構成のノードが停止した時と同じようにマスタノードの再設定などが行われているようです。インスタンスリカバリは不要なはずです。相当の処理が実行されるようですねぇ。移行元のインスタンスがいきなり停止しているように見えた理由も納得がいきます。ロールバックされたと考えられます。中のトランザクションが終了するまで停止処理は待機する。制限時間まで待機する。ルバックされ、該当処理のデータは更新されない。待機時間を設定する必要があります。(そうしないと、途中まで進行した処理がロールバックされてしまう可能性があります。)あるいは、計画メンテナンスなどの作業が控えている状況においては、延々とトランザクションの終了を待ち続けるわけにもいかないでしょうから、事前に全ての処理を停止しておいてもらう様に周知しておく方が望ましいでしょう。このあたりは通常の運用と同じ考慮が必要ということです。使わずにガッツリとインスタンスを落としてみます。障害時のシミュレートです。reserved.トップページ企業概要プライバシーポリシ。