[db tech showcase tokyo 2015] c27:楽天mysql backup structure by 楽天株式会社 粟田啓介
TRANSCRIPT
楽天MySQL Backup Structure~ 過去、現在、そして未来へ~
Keisuke.Awata ([email protected])
Data Store Administration Group
Infrastructure Administration Section
Global Infrastructure Development Department
2
Self Introduction
3
自己紹介
職歴 2007年4月 楽天株式会社へ新卒入社
• 2007年8月 - 2012年6月AD Platform を開発/運用するアプリケーションエンジニア
• 2011年5月 - 2012年5月サーバー設計エンジニアを兼務
• 2012年6月 - 現在DBA- Review・Bookmarkなどの ソーシャルプラットフォーム- 広告、アフィリエイトなどのマーケティングプラットフォーム- Oracle以外のID、Point、Coupon などの会員情報プラットフォーム- 社内ツール系
4
楽天のDatabase
5
RDBMS
会員データ、ポイントデータ、商品データといった特にミッションクリティカルなデータが格納
巨大DBMS環境。非常に昔から使用している。購買データなどクリティカルなデータが格納。古くから有るが故複雑な依存
楽天のメインRDBMS。ミッションクリティカルなデータから、社内サービスまで幅広く使用
Informix
Oracle
Clustrix PostgreSQL
6
楽天のデータベースの規模感
71.90%
7.54%
7.36%
11.56% 1.64%
# of Server (%)
MySQL
Clustrix
Informix
Oracle
PostgreSQL
# of MySQL DB Total Size
3500 + 100TB +
7
楽天のDatabase Architecture
時代とともに構成は変わってきた VCS 構成(Active-Standby on SAN)
VCS + Replication VCS + Shard
IA Server + SSD Private Cloud
詳細は前回の db tech showcase の資料をご覧ください[楽天] 詳説 楽天のデータベースアーキテクチャ史 -シングルノードから仮想化フラッシュストレージへ
8
VCS 時代 ~ IA+SSD 時代初期
サービスの安定稼動 コンポーネントを共用
職人的DBAの全盛期 サービスの基盤を支えていた実績 細かなレビューとチェック項目
9
スピードや柔軟性 古典的なチケットシステム 膨大な量のレビューとチェック項目
VCS 時代 ~ IA+SSD 時代初期
迅速かつ多様な要望に応える必要性
追い討ちをかけるように アジャイルプロジェクトの増加 MongoDB/Redis 等の NoSQL の台頭 クラウドサービスの多様化
増強 増強 = HW購入 EOSLタイミングが同じサーバ達
10
ターニングポイント
DC 移設プロジェクト DCの移設に伴い 250以上のDBを9ヶ月で Private Cloud へ移設
主に既存DBに新DBをレプリケーションさせて切り替え
BackupからのRestoreする方式 アーカイブからのリストア
時間がかかる あるある失敗談
レプリケーション元サーバに binlogなかった binlog転送によりネットワークを逼迫
SJIS Database の存在 新しいDCに建てるサーバはグローバル化に伴い UTF8 に統一
レプリケーション方式は使えない
11
Migration Tool
CLI Base の Migration Tool dump → import → Change Master
dump → import のパラレル実行 thread を分けてdump 実行 encode (SJISの場合) import
期限内に全てのDB移設を完了!
12
# of VMs in Private Cloud
13
楽天 MySQL DB Tools
14
Private Cloudの急激な成長
管理するDatabase数も比例して増加 現在の私たちのグループのDBAは5人 担当するサーバーは本番だけで600台弱 毎月30台ペースでDBサーバが構築されていく
15
DBA の仕事の変化
DB管理の責任範囲 全てのサービスを同じレベルで見ることはもはや不可能に近い状況
だからエンジニアが 知りたい やりたい
ことを自分たちで出来るようなWeb インターフェースを隙間時間で自作
本当にサポートが必要なサービスに目を向けるための基盤作り
16
Status Monitoring
17
Deploy
18
Operation
19
FAQ Portal
20
Cloud化による仕事の変化
21
楽天DBAを取り巻く環境は年々変わってきている
仕事の仕方も変化せざるを得ない トップダウンの決定だけで変化しているわけではない!
現場のDBAのアクションで 自分たちが主導になり 新しいことを取り入れることが出来る環境はある 失敗してもいい、という気持ちが大切
やるかやらないかは自分次第!
22
楽天の MySQL Database のBackup/Restore 方式
23
DB Restore タイミング
Point in time recovery 年に一度、あるかないか 実際は障害訓練でやる程度
移設増強タイミング restore したデータを利用してレプリケーション設定
検証/調査 定期メンテナンス
DBAタスク時間見積もり オペレーション確認
アプリエンジニアからの過去データ調査依頼 前日トラブルがあり、データを確認したい
本番データを用いたアプリケーションテストのため 結合テスト 負荷テスト
24
楽天 の Database Backup方法
Database Architecture 主なBackup 方法
VCS 構成
SAN SnapshotVCS + Replication
VCS + Shard
IA Server + SSD mylvmbackup
Private Cloud Veeam
その他mysqldump
mysqlhotcopy
file copy
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
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
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 展開に非常に時間がかかる 特に定期メンテナンスの前になるとリソースの取り合い
ディスクだけでなくメモリ含め 性能は本番環境に比べて著しく低い
28
Veeam によるBackup
VirtualAPP
Veeam ManagementServer
1.DBロック取得
mysql>FLUSH TABLE WITH READ LOCK
2.バックアップ時のポジション取得
mysql>SHOW SLAVE STATUS
mysql>SHOW MASTER STATUS
3.VMスナップショット取得
4.DBロック開放
mysql>UNLOCK TABLES
5.Backupファイル作成
Backup NFS
NAS
VMWareに特化した仮想バックアップソフト フル/増分(差分)バックアップ、重複排除により効率的なバックアップ 現在の楽天のバックアップの主流 本番への影響はSnapshotを取得する数秒のみ
29
Veeam Restore
Windows GUI ベースのオペレーション Restoreしたい日付を選んでいくつかの項目を選択 VM 設定全て引き継いでいる Restore 後 Network 設定等 OS オペレーション
Traget DB Server
DB
Restored DB Server
DB
30
Restore の改善
Backup Restore の過去、現在 SAN Snapshot / mylvmbackup
Restore 先は 共有環境 or NFS tar 展開に非常に時間がかかる 特に定期メンテナンスの前になるとリソースの取り合い
ディスクだけでなくメモリ含め 性能は本番環境に比べて著しく低い
Veeam Restore 先は Private Cloud 環境
用途によって性能環境を分けられる 負荷試験環境 => 本番と同じストレージ(FC/SSD) データ確認用 => 性能を求めない安いストレージ
Restore にやや時間がかかる 展開先のストレージによる
SSDなら30分、FCなら2時間 など
31
Next Backup Platform
32
Veeam Backup
VeeamによるBackupの問題点 License Fee
日に日にDBサーバが増えていく現状ではコストが上がる一方
VMware 依存 Platform は時代とともに変わってくる
VCS → IA + SSD → VMware → Next!
運用管理 台数が多くなるにつれてGUI処理が重くなっている
Restore Operation の危険性 既存で動いているサーバにバックアップを上書き 既存で動いているIPアドレスをそのまま別のサーバで使用など危険な操作が出来てしまう
→ VMと社内ネットワークに対する最低限の理解が必要
33
新しいBackup システムの導入検討
要件 Platformとして提供
数百台のサーバのBackup管理 アプリケーションエンジニアでも
「いつでも」 「かんたんに」リストアできるサービス
中央管理が出来ること Backup Script は DBサーバ自体に配置
インストールが簡単であること
Jobをコントロールするのは別のアプリケーション 履歴管理ができること スケジュールの登録/変更が簡単であること
候補 Xtrabackup MySQL Enterprise Backup
34
構成図イメージ
?
?
35
Xtrabackup VS MySQL Enterprise Backup
検証方法 tpcc を利用した ベンチマークにより検証
様々なトランザクションを並列実行した結果を見るため 3回ずつ実行し中間の値を取得
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
結果
Category TPCCBackup
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)
38
Running Time
Enterprise Backupに軍配 どのパターンでも EBの方が早く終わった
Compress を使ったほうが早い!
39
Backup Size
ほぼ同じ
40
Lock Time
ほぼ同じ FLUSH TABLES WITH READ LOCK 流れてくるクエリの Transaction タイミングによる MyISAM DBに対しては必ずLockがかかる
mysql db ・・・
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 を使ったほうが 負荷が低い
42
tpmC
Category
tpmC(Only Backup Time)
Average tpmC
T10(105) 11829.6
T10(106) 13091.4
T10 + XB 10418.198
T10 + EB 3622.135
XB + C + T10 10594.058
EB + C + T10 7154.796
Xtrabackup の圧勝!? XB vs EB → 2.87倍 Compress → 1.48倍
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
Summary
今回は Xtrabackup を採用 いずれもBackup Platformを作る、という観点で言えば同じことが出来る Backup取得中のDBへのパフォーマンス影響が小さい ライセンスを気にしなくていい
Xtrabackup Enterprise Backup
Running Time △ ○
Load Average △ ○
Lock Time ほぼ同じ
tpmC ○ △
Backup Size ほぼ同じ
Cost ◎ ○
45
Backup and Restore System
46
Option の決定
前提 様々なサイズ、リソース、トランザクション数を持つDBがある
個別最適を行わない 自動で判断できないことはしない Compress オプションは必須
Options vCPU/2 が最も効率的だった Compress Thread 数は1で固定
47
Restoredecompress
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
Restore に必要な Disk Size
CompressedDirectory Size
DecompressedDirectory size
Max Usage Size
23GB 69GB 78GB
必要なDisk Size 最大のテーブルサイズ分を考慮したdisk設計をする backupファイルをどこで展開するかを決める
NFS or Local
49
Backup and Restore System
50
絶賛開発中
Restore のしやすさ Veeam で Restore するよりも安全性は上げられるか Serviceとしてどこまで展開できるか
アプリケーションエンジニアでも Restoreできる様にする Server をあらかじめ用意しておく必要がある
Cost Veeam の Cost を超えない運用Costに抑えられるか
本番への影響 Veeamは Snapshotをとる数秒だけ Xtrabackup は backup 処理中ずっと
どこまで優位性を出せるか?
51