More Related Content Similar to [db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介 (20) More from Insight Technology, Inc. (20) [db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介1. 楽天MySQL Backup Structure
~ 過去、現在、そして未来へ~
Keisuke.Awata (keisuke.awata@rakuten.com)
Data Store Administration Group
Infrastructure Administration Section
Global Infrastructure Development Department
3. 3
自己紹介
職歴
2007年4月 楽天株式会社へ新卒入社
• 2007年8月 - 2012年6月
AD Platform を開発/運用するアプリケーションエンジニア
• 2011年5月 - 2012年5月
サーバー設計エンジニアを兼務
• 2012年6月 - 現在
DBA
- Review・Bookmarkなどの ソーシャルプラットフォーム
- 広告、アフィリエイトなどのマーケティングプラットフォーム
- Oracle以外のID、Point、Coupon などの会員情報プラットフォーム
- 社内ツール系
7. 7
楽天のDatabase Architecture
時代とともに構成は変わってきた
VCS 構成(Active-Standby on SAN)
VCS + Replication
VCS + Shard
IA Server + SSD
Private Cloud
詳細は前回の db tech showcase の資料をご覧ください
[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシュストレージへ
8. 8
VCS 時代 ~ IA+SSD 時代初期
サービスの安定稼動
コンポーネントを共用
職人的DBAの全盛期
サービスの基盤を支えていた実績
細かなレビューとチェック項目
9. 9
スピードや柔軟性
古典的なチケットシステム
膨大な量のレビューとチェック項目
VCS 時代 ~ IA+SSD 時代初期
迅速かつ多様な要望に応える必要性
追い討ちをかけるように
アジャイルプロジェクトの増加
MongoDB/Redis 等の NoSQL の台頭
クラウドサービスの多様化
増強
増強 = HW購入
EOSLタイミングが同じサーバ達
10. 10
ターニングポイント
DC 移設プロジェクト
DCの移設に伴い 250以上のDBを9ヶ月で Private Cloud へ移設
主に既存DBに新DBをレプリケーションさせて切り替え
BackupからのRestoreする方式
アーカイブからのリストア
時間がかかる
あるある失敗談
レプリケーション元サーバに binlogなかった
binlog転送によりネットワークを逼迫
SJIS Database の存在
新しいDCに建てるサーバはグローバル化に伴い UTF8 に統一
レプリケーション方式は使えない
11. 11
Migration Tool
CLI Base の Migration Tool
dump → import → Change Master
dump → import のパラレル実行
thread を分けてdump 実行
encode (SJISの場合)
import
期限内に全てのDB移設を完了!
15. 15
DBA の仕事の変化
DB管理の責任範囲
全てのサービスを同じレベルで見ることはもはや不可能に近い状況
だからエンジニアが
知りたい
やりたい
ことを自分たちで出来るようなWeb インターフェースを隙間時間で自作
本当にサポートが必要なサービスに目を向けるための基盤作り
23. 23
DB Restore タイミング
Point in time recovery
年に一度、あるかないか
実際は障害訓練でやる程度
移設増強タイミング
restore したデータを利用してレプリケーション設定
検証/調査
定期メンテナンス
DBAタスク時間見積もり
オペレーション確認
アプリエンジニアからの過去データ調査依頼
前日トラブルがあり、データを確認したい
本番データを用いたアプリケーションテストのため
結合テスト
負荷テスト
24. 24
楽天 の Database Backup方法
Database Architecture 主なBackup 方法
VCS 構成
SAN SnapshotVCS + Replication
VCS + Shard
IA Server + SSD mylvmbackup
Private Cloud Veeam
その他
mysqldump
mysqlhotcopy
file copy
25. 25
SAN Snapshot によるBackup
DB Server1
DB
Active Mirror
DB Volume DB Volume
Backup NFS
NAS
Compress
Backup Server
1.Mirror Volume へ Backup Serverから mount
2.DB Lock
mysql>FLUSH TABLE WITH READ LOCK
3.Active から Mirror へ 再同期
4.Active と Mirrorを切り離し
5.DB Unlock
mysql>UNLOCK TABLES
6.Mirror Volumeをマウント
7.BackupNFSをマウント
8.バックアップ領域へtar archive作成
9.Mirror Volumeをアンマウント
DB Server2
DB
26. 26
mylvmbackup による Backup
DB Server
DB
OS Volume DB Volume Backup Volume Backup NFS
NASCompress
File
1.DBロック取得
mysql>FLUSH TABLE WITH READ LOCK
2.バックアップ時のポジション取得
mysql>SHOW SLAVE STATUS
mysql>SHOW MASTER STATUS
3.スナップショット取得
lvcreate -s -l 100%FREE --name=#{db_backup} #{Volname}
4.DBロック開放
mysql>UNLOCK TABLES
5.スナップショット領域をマウント
6.バックアップ領域へtar archive作成
7.スナップショット領域をアンマウント
8.スナップショット領域の使用サイズ確認
lvdisplay #{LVName}
9.スナップショット領域を開放
lvremove -f #{LVName}
27. 27
SAN Snapshot / mylvmbackup の Restore
Backup NFS
NAS
DB Server
DB
Local disk に余裕がある場合
1.Backup NFS を mount
2.tar archive ファイルを Local へ Copy
3.tar archive ファイルの 展開
Local disk に余裕がない場合
1.Backup NFS を mount
2.tar archive ファイルをNAS上で展開
Compress
File
DB
Restore 先は 共有環境 or NFS
tar 展開に非常に時間がかかる
特に定期メンテナンスの前になるとリソースの取り合い
ディスクだけでなくメモリ含め
性能は本番環境に比べて著しく低い
29. 29
Veeam Restore
Windows GUI ベースのオペレーション
Restoreしたい日付を選んでいくつかの項目を選択
VM 設定全て引き継いでいる
Restore 後 Network 設定等 OS オペレーション
Traget DB Server
DB
Restored DB Server
DB
30. 30
Restore の改善
Backup Restore の過去、現在
SAN Snapshot / mylvmbackup
Restore 先は 共有環境 or NFS
tar 展開に非常に時間がかかる
特に定期メンテナンスの前になるとリソースの取り合い
ディスクだけでなくメモリ含め
性能は本番環境に比べて著しく低い
Veeam
Restore 先は Private Cloud 環境
用途によって性能環境を分けられる
負荷試験環境 => 本番と同じストレージ(FC/SSD)
データ確認用 => 性能を求めない安いストレージ
Restore にやや時間がかかる
展開先のストレージによる
SSDなら30分、FCなら2時間 など
32. 32
Veeam Backup
VeeamによるBackupの問題点
License Fee
日に日にDBサーバが増えていく現状ではコストが上がる一方
VMware 依存
Platform は時代とともに変わってくる
VCS → IA + SSD → VMware → Next!
運用管理
台数が多くなるにつれてGUI処理が重くなっている
Restore Operation の危険性
既存で動いているサーバにバックアップを上書き
既存で動いているIPアドレスをそのまま別のサーバで使用
など危険な操作が出来てしまう
→ VMと社内ネットワークに対する最低限の理解が必要
33. 33
新しいBackup システムの導入検討
要件
Platformとして提供
数百台のサーバのBackup管理
アプリケーションエンジニアでも
「いつでも」
「かんたんに」
リストアできるサービス
中央管理が出来ること
Backup Script は DBサーバ自体に配置
インストールが簡単であること
Jobをコントロールするのは別のアプリケーション
履歴管理ができること
スケジュールの登録/変更が簡単であること
候補
Xtrabackup
MySQL Enterprise Backup
35. 35
Xtrabackup VS MySQL Enterprise Backup
検証方法
tpcc を利用した ベンチマークにより検証
様々なトランザクションを並列実行した結果を見るため
3回ずつ実行し中間の値を取得
36. 36
base command
Test
Scenario
Command
Full Backup Only Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} ${Backup Path}
EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --backup-dir=${Backup Path} backup
Full Backup +
Compress
Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress ${Backup Path}
EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress --backup-dir=${Backup Path}
backup
Compress +
process thread 2
+ Full Backup
Xtra innobackupex --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress --parallel=2 ${Backup Path}
EP mysqlbackup --defaults-file=${my.cnf Path} --user=${USER} --
password=${PASSWORD} --compress --process-threads=2 --backup-
dir=${Backup Path} backup
37. 37
結果
Category TPCC
Backup
Time(min)
Lock
Time
Backup
Size
(GB)
tpmC(Only Backup Time)
Load
(Only Backup Time)
Max
tpmC
Min
tpmC
Average
tpmC
Max
Load
Average
Load
T10(105) 0:35:00 N/A N/A N/A 14340 5256 11829.6 3.03 2.830
T10(106) 0:35:00 N/A N/A N/A 14544 10356 13091.4 2.92 2.562
XB N/A 0:19:24 0:00:04 38 N/A N/A N/A 2.99 1.842
EB N/A 0:18:43 0:00:03 38 N/A N/A N/A 2.26 1.607
T10 + XB 0:20:10 0:16:49 0:00:52 39 13380 0 10418.198 4.37 3.162
T10 + EB 0:20:10 0:16:02 0:00:53 38 14232 0 3622.135 3.46 2.510
XB + C + T10 0:20:10 0:14:23 0:00:03 23 12876 0 10594.058 3.19 2.479
EB + C + T10 0:20:10 0:08:31 0:00:03 22 11916 0 7154.796 2.65 1.999
XB + C + Th2 +
T10
0:20:10 0:14:28 0:00:53 23 12504 0 9800.483 3.87 3.359
EB + C + Th2 +
T10
0:20:10 0:09:03 0:00:04 22 11556 0 7765.982 3.42 2.915
* 弊社実行環境による検証結果
(4vCPU-16GB Memory)
40. 40
Lock Time
ほぼ同じ
FLUSH TABLES WITH READ LOCK
流れてくるクエリの Transaction タイミングによる
MyISAM DBに対しては必ずLockがかかる
mysql db ・・・
41. 41
Load Average
Enterprise Backupに軍配も誤差の範囲
どのパターンでも EBの方がXBに比べてLoadは低めだった
Category
Load
(Only Backup Time)
Max
Load
Average
Load
T10(105) 3.03 2.830
T10(106) 2.92 2.562
XB 2.99 1.842
EB 2.26 1.607
T10 + XB 4.37 3.162
T10 + EB 3.46 2.510
XB + C + T10 3.19 2.479
EB + C + T10 2.65 1.999
XB + C + Th2 +
T10
3.87 3.359
EB + C + Th2 +
T10
3.42 2.915
Compress を使ったほうが 負荷が低い
43. 43
EB のデフォルト値
EBではprocess-threads のデフォルトは 6
何も考えずに叩くと process-threads が6で設定される
http://dev.mysql.com/doc/mysql-enterprise-backup/3.11/en/backup-capacity-options.html
差は縮まったが Xtrabackup に軍配
44. 44
Summary
今回は Xtrabackup を採用
いずれもBackup Platformを作る、という観点で言えば同じことが出来る
Backup取得中のDBへのパフォーマンス影響が小さい
ライセンスを気にしなくていい
Xtrabackup Enterprise Backup
Running Time △ ○
Load Average △ ○
Lock Time ほぼ同じ
tpmC ○ △
Backup Size ほぼ同じ
Cost ◎ ○
46. 46
Option の決定
前提
様々なサイズ、リソース、トランザクション数を持つDBがある
個別最適を行わない
自動で判断できないことはしない
Compress オプションは必須
Options
vCPU/2 が最も効率的だった
Compress Thread 数は1で固定
47. 47
Restore
decompress
Backupのタイミングで Compressをしているため1step 必要
Backupファイルを tar.gz するかどうか
するとしたらそのタイミングは?
tar.gz してしまうと 増分/差分backupをするためにtar展開しな
ければならない
1週間後?
copy-back or move-back?
Restore 先のサーバは基本的にはサービス停止している
memory や CPU は使える限り使う
Memory => mem * 0.75
Parallel
48. 48
Restore に必要な Disk Size
Compressed
Directory Size
Decompressed
Directory size
Max Usage Size
23GB 69GB 78GB
必要なDisk Size
最大のテーブルサイズ分を考慮したdisk設計をする
backupファイルをどこで展開するかを決める
NFS or Local
50. 50
絶賛開発中
Restore のしやすさ
Veeam で Restore するよりも安全性は上げられるか
Serviceとしてどこまで展開できるか
アプリケーションエンジニアでも Restoreできる様にする
Server をあらかじめ用意しておく必要がある
Cost
Veeam の Cost を超えない運用Costに抑えられるか
本番への影響
Veeamは Snapshotをとる数秒だけ
Xtrabackup は backup 処理中ずっと
どこまで優位性を出せるか?