・ 導入前の状況
RDBMSにMySQLをマスタースレーブ構成で導入済み。
DBサーバの台数はマスタースレーブ構成を2セットの計4台。
バックアップを定期的に取得していない、レプリケーションが遅延する。

まず、第一にお客様に申し上げたことは、「スレーブはバックアップにはなりません」ということです。
バックアップの目的を考えたとき、あらゆる不測の事態から復旧ができなくては意味がありません。
スレーブはあくまでマスターのレプリカ　“複製”　ですので、マスター側で誤操作をしてしまった場合誤操作の情報も 複製されてしまいます。(例えば、ユーザー情報を消してしまった場合ただちにスレーブ側でも情報が消えてしまいます)
今回の事例ではOSにCentOS5.5、ファイルシステムにLVMを使用したシステムでしたので、LVMのスナップショットを使用したバックアップの構成をご提案いたしました。
レプリケーション遅延の原因の多くはディスクIOがネックになることが多く、今回の事例でもディスクIOが原因となっておりました。
遅延の原因を探るにはお客様と綿密な打ち合わせ、また運用による統計情報の把握など、地道な方法による改善が必要なのですが、 本事例ではMySQLのチューニングを見直すことで改善可能でした。

マスタースレーブ＋バックアップの構成で、不測の事態が起こったときに最悪でもデータがすべてなくなるということはなくなりますが、それだけでは、障害時にサービスが停止する時間が大きいままです。
当社では、マスタースレーブ＋バックアップ＋耐障害性を考え、DRBDを導入を致しました。