導入事例B社 「データベースのバックアップを見直したい！」
- お客様からのご要望
-
- バックアップを定期的に取得したい。
- レプリケーション遅延を解消したい。
導入前の概況
データベースサーバのバックアップを取得しておらず有事の際の対応に懸念が発生していました。また、データベースとしてMySQLをMaster-Slave構成で利用していましたが、アクセスの増加と共にレプリケーションの遅延が目立ち始めていました。
RHEMS Japanの解決手法
- 1.最小のコストでバックアップ
-
LVMによるsnapshotの取得
ファイルシステムにLVMが採用されていたため、snapshot機能でのバックアップのご提案となりました。但し、RPO(目標復旧地点)やRTO(目標復旧時間)のポリシーが存在していないとのことでしので、暫定的に”RPO=24時間/RTO=12時間として1日1回の定時batch処理の組込みのご提案となりました。
- 2.地道な調査でボトルネックの解消
-
チューニングの実施
お客様のご協力の元、slow.logの出力とクエリの分析およびサーバスペックやログの調査を実施しました。結果、ディスクIOがボトルネックであることが判明しました。クエリの見直しを含めて、各種パラメータの調整を少しずつ実施することで遅延の解消が実現できました。
システム構成図
プラスα
Master-Slave構成を維持しつつ耐障害性を向上させるツールとしてDRBDの導入を検討しました。機能検証、負荷検証をお客様にもご協力をいただきつつ実施し、性能をご理解いただくことで、最終的な導入が決定しました。なお、データベーススレーブはバックアップではありませんので、適切なRTO/RPOの決定までは都度バックアップを取得する必要がありました。こちらについては、サーバ作業の際の都度利用可能なプログラムの作成とご提供をさせていただきました。
事例による改善で大幅なコストの軽減が実現しました。