※長文で恐縮です(^^;
書き込みのアクセスが一時的に急増するようなサービスにおいて
マスタースレーブ型の構成をとった場合、マスターDBが書き込み処理が間に合わなくなることがあるのではないか
完全同期または準同期型のレプリケーションであれば、ありえると思います。
一方、非同期型のレプリケーションであれば、それが原因でマスターDBへの書き込み遅延が発生する可能性は低いと思います。
質問1)
そのような場合、障害?と認定され、レプリケーションとして、スレーブDBがマスターDBに昇格するのでしょうか?
「レプリケーション機能自体にそのような仕組みがあるのか?」
という意図のご質問であれば、回答は
「いいえ」
です。
フェイルオーバー(スレーブをマスターに昇格させること)の仕組みは、レプリケーションとは別に構築してやる必要があります。
「システムとしてどのように対処するのが良いか?」
というご質問であれば、
「それはマスターDBへの書き込み遅延が発生している原因による」
と、私は考えます。
例えば遅延の原因が「マスターDBの処理能力を超える更新要求が発生した」であれば、フェイルオーバーしたところで意味はありません。
一般的なシステムでは、スレーブDBはマスターDBと同等かそれを下回る性能のもので構成するからです。
(書き込みが僅少で、スレーブから大量の読み取り処理が行なわれるようなシステムでは、
スレーブの方により多くリソースを投入するかもしれませんが)
一方、「ディスク故障などでマスターDBの書き込み性能が落ちた」ことが原因であれば、
フェイルオーバーさせることで遅延を解消できるかもしれません。
質問2)
昇格するまでの間は、書き込みに失敗するデータが出てくるのではないか
もちろん、ありえます。
こういうケースは一般的にどのように対処されているのでしょうか?
これは
「そのデータがどのくらい重要か」
によると思います。
多少の損失が許されるデータであればあえて何も対策を取らないでしょうし、
逆に絶対に損失が許されないデータであれば、例えば
・フェイルオーバーが完了するまで書き込みを待機させる
・一旦ログファイルなどに書き出しておき、後でDBに投入する
などの仕組みを実装することになります。
質問3)
そもそも、こういうケースにおいて、マスタースレーブ型を取るのは妥当なのでしょうか?
これも
「何のためにマスタースレーブ型を取るのか」
によると思います。
前述のように書き込みよりも読み取りの方が圧倒的に多いようなシステムでは、
マスタースレーブ型を取ったうえで読み取り処理をスレーブ側に回さないと、かえって性能問題を引き起こす可能性が高くなりますので。
質問4)
今後の対策としてどのようなことを取るのがいいのでしょうか?
まずは shi_ue様の回答にあるように
MySQLの徹底的なチューニングと、高速なサーバー&ストレージを利用する、など
を実施するのが一般的かと思います。
マルチマスタ(※)構成に変更したり別のDB製品に乗り換えたりするのは、システムの改修にかかるコストが大きくなりますので。
※ https://www.designet.co.jp/faq/term/?id=44Oe44Or44OB44Oe44K544K_
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。