Submit Search
Upload
MySQLのバックアップ運用について色々
•
112 likes
•
35,601 views
yoku0825
Follow
2015/02/27 OSC 2015 Tokyo/Spring
Read less
Read more
Technology
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 59
Download now
Download to read offline
Recommended
基本に戻ってInnoDBの話をします
基本に戻ってInnoDBの話をします
yoku0825
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
Mikiya Okuno
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
Recommended
基本に戻ってInnoDBの話をします
基本に戻ってInnoDBの話をします
yoku0825
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
マルチテナント化で知っておきたいデータベースのこと
マルチテナント化で知っておきたいデータベースのこと
Amazon Web Services Japan
What's New in MySQL 5.7 InnoDB
What's New in MySQL 5.7 InnoDB
Mikiya Okuno
はじめてのElasticsearchクラスタ
はじめてのElasticsearchクラスタ
Satoyuki Tsukano
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
NTT DATA Technology & Innovation
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
Yoshitaka Kawashima
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
Kentaro Yoshida
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
NTT DATA OSS Professional Services
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
NTT DATA Technology & Innovation
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
やってはいけない空振りDelete
やってはいけない空振りDelete
Yu Yamada
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
Kosuke Kida
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Miki Shimogai
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
Takaaki Suzuki
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
yoku0825
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
yoku0825
More Related Content
What's hot
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
泰 増田
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
Kentaro Yoshida
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
Hiroshi Ito
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
NTT DATA Technology & Innovation
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
NTT DATA OSS Professional Services
TLS, HTTP/2演習
TLS, HTTP/2演習
shigeki_ohtsu
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
NTT DATA Technology & Innovation
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
やってはいけない空振りDelete
やってはいけない空振りDelete
Yu Yamada
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
Kosuke Kida
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Miki Shimogai
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
Takaaki Suzuki
PostgreSQLアンチパターン
PostgreSQLアンチパターン
Soudai Sone
What's hot
(20)
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
祝!PostgreSQLレプリケーション10周年!徹底紹介!!
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
TLS, HTTP/2演習
TLS, HTTP/2演習
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
やってはいけない空振りDelete
やってはいけない空振りDelete
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
PostgreSQLアンチパターン
PostgreSQLアンチパターン
More from yoku0825
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
yoku0825
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
yoku0825
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれや
yoku0825
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
yoku0825
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
yoku0825
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術
yoku0825
MySQLステータスモニタリング
MySQLステータスモニタリング
yoku0825
わかった気になるMySQL
わかった気になるMySQL
yoku0825
わたしを支える技術
わたしを支える技術
yoku0825
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
yoku0825
Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験
yoku0825
MySQLアンチパターン
MySQLアンチパターン
yoku0825
MySQLerの7つ道具 plus
MySQLerの7つ道具 plus
yoku0825
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
yoku0825
MySQLerの7つ道具
MySQLerの7つ道具
yoku0825
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQL
yoku0825
5.7の次のMySQL
5.7の次のMySQL
yoku0825
mikasafabric for MySQL
mikasafabric for MySQL
yoku0825
とあるイルカの近況報告
とあるイルカの近況報告
yoku0825
MySQL Fabricでぼっこぼこにされたはなし
MySQL Fabricでぼっこぼこにされたはなし
yoku0825
More from yoku0825
(20)
逝くぞ最新版、罠の貯蔵は十分か
逝くぞ最新版、罠の貯蔵は十分か
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
サーバーが完膚なきまでに死んでもMySQLのデータを失わないための表技
MySQLレプリケーションあれやこれや
MySQLレプリケーションあれやこれや
MySQL 8.0で憶えておいてほしいこと
MySQL 8.0で憶えておいてほしいこと
片手間MySQLチューニング戦略
片手間MySQLチューニング戦略
MySQLを割と一人で300台管理する技術
MySQLを割と一人で300台管理する技術
MySQLステータスモニタリング
MySQLステータスモニタリング
わかった気になるMySQL
わかった気になるMySQL
わたしを支える技術
わたしを支える技術
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
MySQL 5.7の次のMySQL 8.0はどんなものになるだろう
Dockerイメージで誰でも気軽にMroonga体験
Dockerイメージで誰でも気軽にMroonga体験
MySQLアンチパターン
MySQLアンチパターン
MySQLerの7つ道具 plus
MySQLerの7つ道具 plus
MySQL 5.7の次のMySQLは
MySQL 5.7の次のMySQLは
MySQLerの7つ道具
MySQLerの7つ道具
MHAの次を目指す mikasafabric for MySQL
MHAの次を目指す mikasafabric for MySQL
5.7の次のMySQL
5.7の次のMySQL
mikasafabric for MySQL
mikasafabric for MySQL
とあるイルカの近況報告
とあるイルカの近況報告
MySQL Fabricでぼっこぼこにされたはなし
MySQL Fabricでぼっこぼこにされたはなし
Recently uploaded
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
taisei2219
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
iPride Co., Ltd.
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
Hiroki Ichikura
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
Toru Tamaki
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
Toru Tamaki
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
sugiuralab
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Yuma Ohgami
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
Toru Tamaki
Recently uploaded
(8)
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
TataPixel: 畳の異方性を利用した切り替え可能なディスプレイの提案
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
MySQLのバックアップ運用について色々
1.
MySQLのバックアップ運⽤について ⾊々 2015/02/27 ⽇本MySQLユーザ会 yoku0825 OSC 2014
Tokyo/Spring
2.
\こんにちは/ yoku0825@とある企業のDBA オラクれない- ポスグれない- マイエスキューエる- 家に帰ると 妻の夫- せがれの⽗- 娘の⽗- Twitter: @yoku0825 Blog: ⽇々の覚書 1/58
3.
バックアップ を運⽤するお はなし 2/58
4.
前提条件 バックアップが取得できなければいけない バックアップ取得はサービスに影響を与えてはいけない- バックアップ取得にかかる時間は現実的でなければいけ ない - バックアップファイルは保管されなくてはいけない- バックアップはリストアできなければいけない リストアにかかる時間は現実的でなければいけない- 3/58
5.
バックアップ 取得の選択肢 4/58
6.
バックアップ ステップ的なもの フルバックアップ- 差分バックアップ- 増分バックアップ- 範囲的なもの 全体バックアップ- 部分バックアップ ⼀貫性の問題で、全体バックアップ以外は使いにくい - 5/58
7.
リストアステップ (最新の)フルバックアップの戻し (最新の)差分バックアップの戻し (↑でリストアした時点からリストア時点までの)増 分バックアップの戻し 6/58
8.
ステップ的なもの 7/58
9.
たとえば1/4 のデータを復 元するなら 8/58
10.
1/1のフル + 1/2の増分
+ 1/3の増分 + 1/4の増分 9/58
11.
あるいは1/1のフル + 1/3の差分
+ 1/4の増 分 10/58
12.
ステップ的なもの サイズ 使いどころ コマンド例 フルバックアップ
でかい 必ず必要 tar, rsync, mysqldump, XtraBackup 差分バックアップ ⼩さい フルバックアップの 間隔が短ければ要ら ない mysqldump(スキー マに制約) XtraBackup 増分バックアップ 更新量に依存 ほぼ間違いなく必要 cp, rsync, mysqlbinlog 11/58
13.
というわけで差分 バックアップはあ まり使わない 12/58
14.
フルバックアップの選択肢 コマンド エンジン アプリ影響
⽅式 サイズ tar, rsync MyISAM × 停⽌またはロッ ク 物理 ⼤きめ tar, rsync InnoDB × mysqld停⽌ 物理 ⼤きめ LVMスナップ ショット MyISAM InnoDB △ 性能劣化がひど い 物理 ⼤きめ mysqldump MyISAM × ロック 論理 ⼩さめ mysqldump InnoDB ○ 論理 ⼩さめ XtraBackup MyISAM × ロック 物理 ⼤きめ XtraBackup InnoDB ○ 物理+論理 ⼤きめ 13/58
15.
フルリストアのしやすさ コマンド エンジン リストアのしやすさ
時間 tar, rsync MyISAM InnoDB 簡単 短い mysqldump MyISAM InnoDB 簡単 超⻑い XtraBackup MyISAM InnoDB 慣れるまで⾯倒 やや短い 14/58
16.
増分バックアップ バックアップ scp, rsynなどでコピー- MySQL 5.6からは–raw
–stop-neverでリアルタイムバ ックアップもできる - リストア mysqlbinlogでデコード- 15/58
17.
ここまでのまとめ フルバックアップと増分バックアップが両⽅必要 フルバックアップの頻度が⼗分なら差分バックアップは 要らない - 16/58
18.
ここまでのまとめ ファイルコピーの特徴 バックアップもリストアも速くて楽ちん- 容量はやや⼤きめ。制御⽤のファイルやインデックスの 中⾝など全て保管。 - 取得時のインパクトがでかい- 17/58
19.
ここまでのまとめ mysqldumpの特徴 バックアップはやや遅めくらいだがリストアが超重い バックアップもリストアもシングルスレッド。 派⽣: MyDumper - 容量は⼩さめ。制御⽤の構造とかインデックスの中⾝は 要らないから。 テキストなら圧縮と相性が良い。 - フルスキャンによる性能劣化はある- 18/58
20.
ここまでのまとめ XtraBackupの特徴 ホットな物理バックアップ、しかもマルチスレッド- 慣れるまで難しいものの、慣れれば夢のソリューション- ただしMyISAMが混じるとロックが必要- 最新版はMySQL 5.1 InnoDB
Plugin以降のサポート- MySQL Enterprise Backup(商⽤版MySQLのユーティリ ティー)がもっと便利なことできる - 19/58
21.
安全に運⽤するために バックアップ専⽤スレーブを作る リストアのケースを整理する クラッシュはするものとして織り込む モニタリングは⼤事 20/58
22.
こんな感じ 21/58
23.
マスター 22/58
24.
スレーブ 23/58
25.
バッチ 24/58
26.
バックアップ 25/58
27.
アーカイブサーバー 26/58
28.
マスター - バック アップサーバー間 は非同期レプリケ ーション 27/58
29.
バックアップサ ーバーで innobackupex 28/58
30.
アーカイブサ ーバーに転送 29/58
31.
シンプルにできること それっぽく⾔うと「疎結合に作る」ということ 分離することで、コスト(スペック)⾯も運⽤⾯も柔 軟性が上がる マスターに求められる要件とバックアップに求められる 要件は違う - 分離されたバックアップサーバーは⽌められる- データをロールバックする必要のないリストアな ら、⽌めてrsyncで話が済む 30/58
32.
シンプルにできてないこと マスターとスレーブのスキーマを変えている場合 は、それ⽤の⼿順も必要(ままある) マスターにブラックホールがあると⼼が⿊くなっちゃう- バッチ⽤サーバーには専⽤ユーザーがいたり、インデッ クスが追加されてたり - サービス系にはHandlerSocketがいるけどバックアップ ⽤にはいないとか - 環境の差異の吸収も⾃動化したい(できてない)- マスターとスレーブのバージョンが違う…だと…︓ (︔゙゚ʼω゚ʼ)︓ 31/58
33.
均⼀化への道 ブラックホールを使って稼ぎ出したDisk容量、今 なら1万円で買えるよ、みたいな ⽌められる時が技術的負債の繰り上げ返済チャン ス。 泥臭く頑張るしかないと思ってやってる 32/58
34.
必要なスペック(1) マスター, スレーブ サービスに必要なだけ- VMなサーバーもある- 基本はSSD, メモリーは⼤めに メモリーが⼩さいとInnoDB圧縮かけた時に死ぬ - マスターの性能がスレーブの性能より⾼いとたまに死ぬ マスターはマルチスレッドで更新かかるけどスレーブはシングルスレッド(SQLスレッ ドのみ) - クラッシュしたらデータは捨てる
と割り切れば、パラメ ータを危険側に倒すこともできる - 33/58
35.
必要なスペック(2) バッチサーバー ないサービスもある- 基本的にはユーザートラフィックなし- いざという時にサービスに⼊れられる程度のスペックの マシンに複数インスタンス相乗り - サービスレイヤーがシングルマスターな時はあった⽅が いざという時の備えに - 34/58
36.
必要なスペック(3) バックアップサーバー インスタンス相乗り- 速度よりも容量マター RAID5 SATAとかでもOK 全く遅延してはいけないわけではないので、バックアップ取る時に追いついていれば 基本OK - パラメーターはとにかく安全側に倒す。- 35/58
37.
必要なスペック(4) アーカイブサーバー 容量だけが正義と⾔いたいけど、ファイル転送や圧縮伸 ⻑にはそれなりにメモリーもCPUも使う - バックアップサーバーからXtraBackup(または.tar.gz)で フルバックアップを2世代保存 それ以降の世代はテープやDC外に転送して削除 - バイナリーログを貯めるのもここ(rsyncかmysqlbinlog)- 36/58
38.
リストアのケースを整理 スレーブの新規作成 最新のデータに戻せればOK- 基本、そこまで急がない- クラッシュからの復旧(MyISAM, 羃等でないSQL, サーバーが上がらない, Diskの⼆重障害…) 最新のデータに戻せればOK- 基本急ぐ- ほとんどの場合この2パターン 37/58
39.
最新のデータに戻せればOKな場合 バックアップサーバー⽌める 基本、その⽌めた時点のデータが⼿に⼊る- rsync 所要時間= ファイルの転送にかかる時間- 新しいサーバーとバックアップサーバー上げる ⼗数分あればだいたい追いつく- バックアップサーバーがあればそもそもリストアです らない 38/58
40.
リストアのケースを整理 データのロールバック(ロールフォワードリカバリ ー) ロールバック時点から1世代前のフルバックアップからの リストア + ロールバック時点までのbinlog適⽤ - ⾯倒
+ 時間かかる上に⼤概急ぐ- 原因はだいたい「やらかした」 もしくはおもむろに「過去のスナップショット⾒たい」とか、事前に予測のつかない 理由 - 最低限の準備だけしてあとはその時考える 39/58
41.
データのロールバック地点 少なくとも急ぐやつは、かなりのケースが過去数時 間以内へのロールバック 体験上、99%以上は過去24時間まで考慮すればフォロー できる デイリーのフルバックアップ2世代(フルバックアップ取得直前へのロールバックを最 悪ケースとして) アワリーのbinlogバックアップをフルバックアップの世代と合わせて - それより過去へのロールバックは急がないケースが ほとんどだし頻度も滅多にないので、DC外や mysqldumpで容量節約 DC外に保持しているのも⼊れると90⽇前までリストアで きるポリシー - 40/58
42.
クラッシュはするものとして考える ハードウェアクラッシュは避けようがない 体感ではハングアップの⽅が多いけど- Mroongaさんとか⼼が⿊くなっちゃうこともある それに⽐べればInnoDBはホント落ちない Assertも数年に1回レベル - 他にも不測の事態はいくらでもやってくる 2か所同時障害とか考えたくないけど 2か所同時に落ちてもいいように…はつらい- けれど、2か所同時に落ちた時にどうすればいいかは考え ておく - 41/58
43.
クラッシュしたら データを全て消してバックアップサーバーからコピ ーした⽅がいい場合 クラッシュアンセーフなストレージエンジン MyISAM, Mroonga, その他 InnoDBでも innodb̲flush̲log̲at̲trx̲commit
!= 1なマスター skip-innodb-doublewrite 羃等でないSQLを使っているスレーブ sync̲master̲info, sync̲relay̲log̲infoを両⽅1にできないものとして考えてる UPDATE .. SET age= age + 1 は2回実⾏すると結果がズレる UPDATE .. SET age= 32 ならまだマシ binlog̲format= ROWならエラってくれるはず - 42/58
44.
クラッシュするんだから InnoDBを安全に使っておく トランザクションのサポート= 確実なクラッシュリカバ リーの保証 - マスターはinnodb̲flush̲log̲at̲trx̲commit= 1- skip-innodb-doublewriteは毎回作り直す覚悟が必要- 43/58
45.
クラッシュするんだから なるべくスレーブで重複実⾏されても痛みが少ない SQLを選ぶ トランザクションを使ってSELECTして値を得てからその 値でUPDATE - MySQL 5.6以降ならrelay̲log̲recovery= 1
&& relay̲log̲info̲repository= TABLEでクラッシュセーフ スレーブに(クラッシュしてもレプリケーションが正しく 再開される) - 44/58
46.
クラッシュしたあとは スレーブ, マスターの整合性チェック必須 pt-table-checksumというツールが便利 オンラインのままマスターとスレーブのデータの不整合をチェックできる データが読めなければエラるので、⼀応破損チェックにもなる pt-table-checksum - 45/58
47.
クラッシュしたあとは マスターのsync̲binlog != 1
だと、スレーブの master̲log̲positionが先に進んでしまうとか どっちを⽣かす︖- log̲slave̲updatesしてればスレーブを⽣かせるんだけ どさ。。 GTID有効ならlog̲slave̲updates必須なので、⼀意に選択できる。 - ⾃動昇格に任せるという⼿もある(Durabilityよりも ConsistencyとAvailabilityを取る) - 46/58
48.
モニタリングは⼤事 バックアップはちゃんと取れてるのか リストアできないバックアップとか笑えない innobackupexの出⼒をチェックして通報 - バックアップ取る時点でレプリケーションが遅れすぎて いないか 多少は許容するといっても、バックアップ⽇時とデータの時間がズレてるとリストア しにくい サービス系でやってるのと同じ仕組みでSeconds̲behind̲masterを監視(閾値がユ ルイ) - 47/58
49.
モニタリングは⼤事 レプリケーションに不整合は起きていないのか リストアできたとしても、間違ったデータじゃ意味がな い binlog̲format= STATEMENT &&
sysdate-is-nowしてない状態でsysdateとか (実話) 非決定性クエリーに関してはエラーログに吐いてくれる。 binlog̲format= ROWで Error: 1032(HA̲ERR̲KEY̲NOT̲FOUND) で⽌まって くれた⽅がマシ(感じ⽅には個⼈差があります) マスターからバックアップするのが⼀番確実ではある バックアップサーバーに直接UPDATE⽂を投げられたことがあってだな。。 read-only付け忘れるとか Super̲priv良くない pt-table-checksumが簡単だけど、テーブルサイズが⼤きくなってくるとなかなかつ らいものもある。。 - 48/58
50.
ここまでのまとめ バックアップ専⽤スレーブを作る リストアのケースを整理する クラッシュはするものとして織り込む もとのサーバーにリストアできるとは限らない モニタリングは⼤事 49/58
51.
その他ちょこ ちょこしたこ と 50/58
52.
バックアップのサイズも⼤事 300GBのdatadirを物理バックアップするとだいた い45GB(bzip2圧縮) それを100DBぶん取ると1世代で4.5TB- 何世代保管する︖- 圧縮, 転送, 解凍のための時間を織り込まないといけない パラレルでアーカイブしてから転送する︖
パラレル転送してからアーカイブする︖ - 51/58
53.
バックアップのサイズも⼤事 mysqldumpの⽅がサイズが⼩さいのは 制御ファイル(ib̲logfile*とかundoセグメントとか)はバ ックアップに含まれない - インデックスはバックアップに含まれない(DDLとデータ から再作成できるから) - BLOBをふんだんに盛り込んでなければ圧縮が効きやすい- FacebookはmysqldumpをHDFSに保管してるって聞い た(単に容量がでかすぎるかららしい) - 52/58
54.
どこに保管するのか データセンターに1PB詰め込んでも怒られないファ イルサーバーがあるといいな ウチにはない かつてはテープに詰め込んでたけど S3をはじめとするクラウドストレージ︖ 転送前に暗号化案件。 それ、mysqlbackupとinnobackupexならできるよ - 53/58
55.
もとのサーバーにリストアできるとは限らない 主にハードウェアクラッシュで上がってこないパタ ーン クラウドなら楽ちん ベアメタルクラウドも結構ラク - ベアメタルでも、ウチの環境は結構融通が利いてる(世間 ⼀般的なことはわからないけれども) - 最後の⼿段、バッチレイヤーのサービスレイヤーへの接 続 何があってもバックアップサーバーだけはサービスレイヤーには晒さない - 54/58
56.
最近の事情 直近のバックアップはデータセンター, 48時間以上 過去のバックアップは外部 テープドライブに詰められるテープの総容量を超えたの で外部転送に DC内完結では問題にならなかった帯域の問題 - バックアップは⾃動化されているが、リストアは⼿作業 DC内で完結する作業だけでも継続的リストアテストしたい(それが9割以上だし) - DCに残ってないフルバックアップからPITRするためのバ イナリーログがDCに残ってたりする - 55/58
57.
直観的なヒント ⽌めて物理バックアップ => mysqldump
=> XtraBackup => 混合、と推移していくものかなと 思う。 次のステップに進むべき時にはたぶん⾃然とわかる ⽌めて物理バックアップで⾜りている時期にはXtraBackupのドキュメント読んでもき っと⾯⽩くもなんともない mysqldumpでリストアが無理だろうってなった時にはXtraBackupの機能はきっとわ かる 順当にやってきてれば、XtraBackupだけでつらくなってきた時に他の選択肢をきっと 思いつく - 56/58
58.
夢のようなソリ ューションがあっ たら教えてくださ い 57/58
59.
Any Question? 58/58
Download now