Now a days, thousands of database are supporting many kind of Rakuten's services. and it is hard to manage many databases well. especially, backup and restore. so, we are progressing new backup system for our databases. I am going to share some know-hows and experiences that have been acquired with you

1. Rakuten New MySQL Backup
System With Xtrabackup
Vol.01 Jul/14/2016
Uijun Lee
Global Operations Department, Rakuten Inc.
http://www.rakuten.co.jp/

2. 2
Table of Contents
0. Introduction
1. Current MySQL Backup
2. Xtrabackup
3. New MySQL Backup System
4. Future

3. Introduction

4. 4
Who am I?
2008 ~ 2010, 名古屋大学情報科学研究科、修士卒業
2010 ~, 新卒で楽天入社
MySQL DB Engineer
DB Application, DB platform 設計、開発、構築
Python , Ruby, Java, Shell-script, Coffee-script等でプログラミング
~ 2008, 韓国で大学まで
??

5. 5
History in Rakuten (~2014年)
権限付与、スキーマ変更等
スキーマ & SQL review, DB構築, migration
DB consulting, Online-schema 導入,
bench-mark with YCSB & TPCC, 自動化script
Monitoring design (Almond) / development

6. 6
MySQL Monitoring System (Almond)

7. 7
In Progress
USER DB (Prod)
「Almondは進行中」

8. 8
[Improvement] Almond Bot System
Hipchat, Hubot, Cloud Storage を使って対話ができるように実現！
いつでもアプリを使ってstatusの確認、閾値変更などができる

9. 9
Next Mission
What is Next?

10. 10
My Goal
DBaaS?
DBPlatform?

11. 11
Cloud Database Design
Monitorはある程度安定しているので、次はbackup?

12. 12
My Strategy
Monitoring Design / Development ( ~ 2014年)
Backup Design / Development
Deploy, Alert Design / Development
DBaaS / DB Platform
Other DBs (No-SQL, and so on)

13. Current MySQL Backup

14. 14
The History Of Database Structure & Backup
Age DB Structure Backup Structure
VCS VCS + Replication
VCS + Shard
SAN Snapshot
IA + SSD IA Server + SSD LVM
CLOUD Private Cloud Veeam
SAN
VIP
VIP
Active Standby Active Standby Backup
VCS IA + SSD

15. 15
The Features Of Current Backup
 重複排除により効率的なbackup
backup sizeを節約できるので、ストレージ容量を削減できる
 Jobの実行サーバと管理用のサーバが独立している
負荷分散ができる
 SnapShotでのbackup

16. 16
Merits
 VM単位でbackupがとれる
「Copy構築」が簡単にできる
 OS領域まで含めたbackupが出来る
 簡単な画面操作
GUIで操作するので、簡単にbackup、restoreができる
 Restore用の本番から独立した環境が選択できる
自由なテストが可能になる

17. 17
[Demerit] Using Remote-desktop
 Remote-DesktopでWindows serverに接続して作業する
不便で、誰かが接続すると場合によってはセッションが切れる
 Running中のjobが多いと、画面操作が重くなる

18. 18
[Demerit] Dangerous
 間違った選択で、本番稼動中のサーバに上書きしてしまう！

19. 19
[Demerit] Must Change Network Values
 必ずnetwork設定を直さないと本番サーバと IP衝突 するので危険！
 Operationが危ないので必ず作業チェック者が必要
作業costが高い

20. 20
Many Restore Operations
 様々なサービスがDBを使っているので、restore作業が比較的に多い
 テスト環境構築
 データ取得のため
 slave構築（copy構築）

21. 21
Nothing Solutions？
Backupは今のレベルを「維持」しながら、
Restoreがより「簡単」でより「安全」に出来て、
Platformを「自由」に作れるのは無いのか？

22. Xtrabackup

23. 23
What is Xtrabackup?
 Percona社が提供しているMySQLのbackup
 Open-source hot backup utility
 High-performance, non-blocking backup system
 InnoDB, XtraDBテーブルが基本
 MyISAMテーブルもbackupが可能 (Innobackex利用）
 XtrabackupはCで、innobackupexはPerlで書かれている

24. 24
What is Innobackupex?
 Xtrabackupはlow level binary
 Innobackupexはxtrabackupのためのhigher-level Perl wrapper
 一般的には、innobackupexで実行
引用 : Nilnanadan Joshi
http://www.slideshare.net/nilnandan/percona-xtrabackup-mysql-meetup-mumbai

25. 25
Structure
MySQL
client
MySQL
client
MySQL
client
MySQL
Server
InnoDB
Data
Transaction
Logs
Target
Directory
Backup Process
Binary file copy
Transaction info check
引用 : Nilnanadan Joshi
http://www.slideshare.net/nilnandan/percona-xtrabackup-mysql-meetup-mumbai

26. 26
Files
 Backup-my.cnf
→ apply-log実行のための最低限のInnoDB設定情報が入っている
 Xtrabackup_info
→ backupに関するすべての情報がある
→ xtrabackup server version, backup time, binlog position等
 Xtrabackup_binlog_info
→ binaryのloggingがONの場合生成される
→ Masterで取ったbackupからslaveを構築する時必要
 Xtrabackup_checkpoints
→ backupに関するメータデータが格納されている
 Xtrabackup_logfile
→ applylogで必要なデータが格納されている

27. 27
Xtrabackup Version
Version Compatibility Feature
2.0 MySQL 5.0, 5.1, 5.5, 5.6 MySQL5.0対応
2.1 MySQL 5.1, 5.5, 5.6 compact backup サポート
2.2 MySQL 5.1, 5.5, 5.6
2.3 MySQL 5.1, 5.5, 5.6 xbcloud binary (Cloudに流せる）
2.4 MySQL 5.1, 5.5, 5.6, 5.7 MySQL 5.7対応
 Xtrabackup 2.3 からは、xbcloudを使ってOpenStack Swiftにも飛ばせる
 AWS等は何時対応するのか？

28. 28
Strengths
 Backupを速く安定して取れる
 Backup中に トランザクション処理を干渉しない
 ディスクやネットワークを効率良く使える
 ストリーム機能でリモートにも飛ばせる
 オープンソースである

29. 29
Weaknesses
 差分backupは管理等が難しい
 オプションを付けるとコマンドが長くなる
 MyISAMだとlockが必要
 XtrabackupとMySQL間でバージョン依存がある
 Linux のみ対応、Solaris,Windows他には対応していない

30. New MySQL Backup System (Rbackup)

31. 31
New
Backup
& Restore
Service
自動化
簡単
(インストール、
操作)
Xtrabackup
(2.2.8)
シンプル
What is Rbackup?

32. 32
Goals
Service
Cloud
Storage
DBaaS
Automation Simple
Open
Source

33. 33
Conditions
DB構成を標準化している
• OS (Linux) , MySQLバージョン等
Recoveryはほとんど無い
• Restoreはほとんどテスト用 （検証、データ取得等）
• 過去のデータでのrestoreはほとんどない
DB稼働状況
• 専用のBackupサーバが無いサービスも多い
• Single masterで動いているDBサーバも多数
DB運用ポリシー
• 短期、中期、長期の保存policyがある
• Security levelが存在する

34. 34
Concept
短期保存はstorage、中長期はcloudに転送
Client-daemonは予約情報を確認
Binary−logで差分backup
Backup情報の中央管理
• （storage情報、backup option情報、保存期間等)
Auto-mount

35. 35
CLI化
まず、スクリプトをシンプルにしないと！

36. 36
Command (First time)
10 10 * * 3 /usr/local/bin/python /home/uijun/script/Xtrabackup/Xtrabackup.py --s
${BACKUP_INSTANCE} --d {BACKUP_DIR} --comp y --mv N --remote N --interval 7
innobackupex --host=${BACKUP_HOST} --port=${BACKUP_PORT} --user=${BACKUP_USER}
--password=${BACKUP_PASSWORD} –socket=/mysql/${BACKUP_SVR}.sock --defaults-
file=${BACKUP_CNF} --ibbackup=xtrabackup --slave-info --safe-slave-backup --compress --
rsync ${BACKUP_DIR}
(applylog)
innobackupex --host=${RESTORE_HOST} --port=${RESTORE_PORT} --
user=${RESTORE_USER} --password=${RESTORE_PASSWORD} –
socket=/mysql/${BACKUP_SVR}.sock --defaults-file=${BACKUP_CNF} --ibbackup=xtrabackup -
-apply-log ${RESTORE_DIR}
(restore)
innobackupex --host=${RESTORE_HOST} --port=${RESTORE_PORT} --
user=${RESTORE_USER} --password=${RESTORE_PASSWORD} –
socket=/mysql/${RESTORE_SVR}.sock --defaults-file=${RESTORE_CNF} --copy-back
${RESTORE_DIR}

37. 37
Command (Now)

38. 38
Locking Issue
やっぱり一番気になるのは “lock” 周り

39. 39
Backup Options (locking time)
[ --rsync ]
 すべてのnon-innoDB filesをコピーする代わりにrsyncを使ってbackup
 --stream optionとは一緒に使えない
 実際に、使う前には9秒から2秒に改善
９秒 2秒

40. 40
Backup Options (locking time)
[ --lock-wait-timeout ]
 Innobackupexはこの値までFTWRLの実行を待つ
 その時間までlong-queryが存在するとInnobackupexがエラー終了する
 Defaultは “０”で、この設定だと待たずにすぐFTWRLを実行する
 Rbackupではdefault “3600” にしてある
[ --lock-wait-threshold ]
 FTWRLを獲得する前に流れているlong-queryのランニングタイム
 それ以上のqueryが流れている場合はFTWRLを実行しない
 Lock−wait−timeoutが “0”だと、このオプションは使えない
 Defaultは “60”
 Rbackupではdefault “10” にしてある

41. 41
Lock-wait-timeout & Lock-wait-threshold
(the present)
5秒
7秒
Xtrabackup FTWR
L
3秒
2秒
1秒
Lock-wait-threshold
Check “process list”
waiting
Lock-wait-timeout

42. 42
Backup Options (locking time)
[ --no-lock ]
 FLUSH TABLES WITH READ LOCKを無効化
 全てのテーブルがInnoDBの場合、
かつ、Binary−logのpositionを気にしない場合は使える
 DDL実行がなく、non-InnoDBテーブルの変更がない場合は使える
 Xtrabackup_binlog_infoが作成されない
 Rbackupでは使っていない (整合性のため）
[ --lock-wait-query-type ]
 InnobackupexがグローバルLockを発行する前、
どちら(all, update)のqueryを待つのかを選択出来る
 Defaultは “all”

43. 43
Installation Forecast
VMs (only our team)
Size (Gbyte, only our team)
年内２５０VM以上！
年内３００TB以上！
(binary backupとデータの自然増加を含む）

44. 44
Backup Options (disk size)
[ --compress ]
 InnoDB fileを圧縮してbackupするため
 Backup速度が上がる可能性がある
 ディスクサイズを節約出来る
 Decompress時は時間かかる
[ --compact]
 Secondary Indexのコピーをしない
 Secondary Index分のディスク節約ができる
 Rbackupでの使用を検討中

45. 45
Backup Options (disk size)
[ --rebuild-indexes]
 --compact オプションを使った場合Secondary Indexを再作成する
 --apply-log の時に実行出来る
[ --rebuild-threads]
 Secondary Indexの再作成を並行で処理出来る

46. 46
Backup Options (slave)
[ --slave-info ]
 Slave serverでの backupの時有効
 Binary−log positionとmasterサーバ名が出力
 Change master情報がファイル “xtrabackup_slave_info” に出力
[ --safe-slave-backup ]
 FTWRLの実行前にSQL threadを止める
 ”Slave_open_temp_tables”が ”0”になるまでbackupを待つ
[ --safe-slave-backup-timeout ]
 ”Slave_open_temp_tables”が ”0”になるまでどれくらい待つのかを設定
 Defaultは “300”

47. 47
Backup Options (other)
[ --parallel ]
 多数の ibd fileがある場合、複数のchild processでbackup出来る
 Rbackupでは、CPU数の半分で設定される

48. 48
Structure
Web
Rbackup Web
ManageDB
Rbackup Storage
Rbackup Batch
Cloud
DB
Xtrabackup

49. 49
Rbackup Demo
1. Rbackup-Client install (pip install with Git)
 pip install git+https://git.com/juni/rbackup_client.git

50. 50
Rbackup Demo
2. /etc/init.d/rbackupd [ start | stop | status ]

51. 51
Rbackup Demo
3. Rbackup check
 tailf ${rbackup_check_log}

52. 52
Rbackup Demo

53. 53
Rbackup Demo
4. Web login
5. Backup 予約
6. Restore 予約

54. 54
Storage Is Main For Backup
Backupデータをどう保存するのか重要なIssueで、
ストレージの決定は重要ポイントである
1. Dedup機能があるストレージ
2. シンプル構成
3. DR対策
4. 効率的なネットワークトラフィック
5. より簡単な管理、運用
6. 負荷分散
BACKUP
STORAGE
(BIG)
BACKUP
STORAGE
(BIG)
BACKUP
STORAGE
(SMALL)
BACKUP
STORAGE
(SMALL)

55. 55
Deduplication function
5.5x (81.7%) 削減！
実際のサイズ
保存サイズ
(2016.07.04時点)

56. 56
Public Cloud Object Storage
 どのサービスをするのか検討中
AWS, Azure, Oracle Cloud
 どんな構成で飛ばすのか検討中
 Merit
 Storageの運用負担が減る
 データ管理がしやすい
 Demerit
 ネットワーク issue
 Security issue
 運用、管理が難しくなる
AWS
Azure
Google Cloud
Oracle Cloud
.
.
.

57. Future

58. 58
Rbackup Improvement
 Rbackup-clientの re-design (API化)
 ストレージ選択機能 (local storage, cloud 等）
 Error handlingの改善、restoreの改善
 Xtrabackup バージョンアップ
 Deployまで自動化
 様々なアプリケーションがお互いAPIで通信
「DBaaS実現に繋げる！」

59. 59
Future
Monitoring Design / Development ( ~ 2014年)
Backup Design / Development
Deploy, Alert Design / Development
DBaaS / DB Platform
Other DBs (No-SQL, and so on)

60. 60
PR
楽天に興味のある方いらっしゃいますか？
http://corp.rakuten.co.jp/careers/engineering/
10.22 Rakuten Technology Conference 2016
http://tech.rakuten.co.jp/

61. 61
Contact me
ご静聴ありがとうございました
李 宜俊（イ ウイジュン）
FB https://www.facebook.com/uijun.lee.1
Linkedin https://www.linkedin.com/in/uijun-lee-542b0561
Email uijun.lee@rakuten.com