Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
•
4 gefällt mir•3,045 views
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
Ähnlich wie Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS (20)
Mehr von Yahoo!デベロッパーネットワーク
Mehr von Yahoo!デベロッパーネットワーク (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
Yahoo! JAPANのプライベートRDBクラウドとマルチライター型 MySQL #dbts2017 #dbtsOSS
- 1. 2017年6月19日 1 db tech showcase OSS 2017 Yahoo! JAPANのプライベートRDBクラウドと マルチライター型 MySQL Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved
- 2. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 3. 自己紹介 • 三谷 智史（@mita2） • ヤフー（株） • データ&サイエンスソリューション統括本部 データプラットフォーム本部 MySQL • 第６代黒帯 ～RDB～ • MySQLとの関わり • 2002年～ 主に利用して開発 • 2010年～ 主に運用・管理する立場 3
- 4. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 5. Yahoo! JAPAN 利用者数 5 9,000万1日 ユニーク ブラウザ ※出所：Yahoo! JAPAN社内データ（2016年4月-6月の平均）
- 6. 提供サービス 6 Media US Search Video Answer Mail JP US JP Membership C2C Payment C2C EC B2C EC Local
- 9. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 11. クラスタ リング z 統合環境 初代構成 • マスターは 共有ストレージのHA • 1サーバに複数mysqld • Oracle Clusterware 11 共有ストレージ アクティブ サーバ スタンバイ サーバ スレーブやクライアント mysqld mysqld mysqld Failover
- 12. 共有ストレージ 採用理由 1. データロストが許容できない • loss-less semi-sync replication は 当時、未登場 2. 同様のアーキテクチャによる Oracle databaseの運用ノウハウ 12
- 13. 集約することで解決できた課題 1. DB構築時間の短縮 2. 運用レベルの統一 3. HA、冗長性の確保 4. 集約管理によるコスト削減 13
- 14. 新たな課題 14
- 17. メンテナンス • 計画停止メンテナンス • 数分程度の更新停止を伴う 一斉メンテナンスを年に１～２回 実施 • セキュリティパッチ当てなど • 約200DB / 年 が対象 17
- 18. もっとメンテナンスしたい 18 • 設定・SWバージョンの統一 • チューニング等の試行錯誤 • 障害の予行演習としてのメンテ
- 20. リプレイス • SW/HWのEOLにあわせて実施 • ３～５年に１度 • 約200DB / 年 • 旧→新でレプリ、サービス停止、接続先を切り替え • 正味の「寿命」は、もっと短い • 複数DB 利用サービスは負担大 20
- 21. もっとリプレイスしたい • HW構成の統一 • DCラックの有効活用 • 長く使うのはコスト増 • × できるだけ長く使う • ○ 最新のHW/SW を常に利用する 21
- 22. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 27. ヤフーにおける豊富な運用実績 27 0 5 10 15 20 25 1 year ago Half year… Today vCPU (x10k) Memory (x10TB) Block (x1PB)
- 28. OpenStack Trove • Database As A Service コンポーネント • Tesora Inc, を中心に 開発されている 28
- 29. OpenStack Trove • 機能・API • DBインスタンスの作成 • DBアカウントの管理 • DBの起動・停止 • リサイズ（VMスペック変更） • バックアップ取得 • etc… • 対応しているデータストア • MySQL, MariaDB, Percona, Redis, Cassandra… 29
- 30. OpenStackの導入意図 1. APIによる自動化のしやすさ • 構成情報、ステータス、起動や停止 • 抽象化、自動化の役割分担 2. VMイメージによる構成管理 30
- 32. Percona XtraDB Cluster • マルチライター型 高可用性ソリューション • Percona Server for MySQL • MySQL の fork • MySQL との高い互換性 • Percna XtraDB Cluster • さらにマルチライター対応したもの
- 33. Multi Master , Multi Writer ? マルチマスター マルチライター Client Client
- 34. マルチマスター • 従来のレプリケーションは非同期 • 同時書込すると・・・ • レプリケーション停止 • データ不整合 34
- 35. 不整合の具体例 35 マスター１ COMMIT OK COMMIT OK マスター２ テーブル 変更 Binlog 追記 テーブル 変更 Binlog 追記 relaylog 追記 relaylog 追記 ログ適用ログ適用 UPDATE col1 = 1 UPDATE col1 = 2 col1=1col1=2 時間 不整合
- 37. Multi Master , Multi Writer ? • 不整合の考慮が必要 • 片方にのみ書込、Active/Standby • 同時更新で不整合は起こらない • 容易に高可用性構成が組める Client Client
- 38. 解決後 デプロイ メンテ例 38
- 39. ゴールデンイメージ準備 1. 新しいゴールデンイメージ準備 39 $ yum update イメージ作成用VM イメージ ファイル snapshot $ nova create-image $ mysql –e ‘select * from hoge’ 自動テスト実行
- 40. 無風化 2. 無風化する 40 mysql> UPDATE clutercheck SET status = ‘DISABLED’ WHERE node = ‘node1’ ロードバランサ node1 node2 node3 httpd httpd httpd I’m offline
- 41. OSから入れ替え 3. OS再インストール 41 $ nova rebuild イメージ ファイル OpenStackのOS再インストールAPIを実行 node2 node3
- 42. データの自動同期 4. データを同期 42 node1 node2 node3
- 45. 頻繁にメンテを実行 • １５０本番DB/月に対して実行 • 9ヶ月の実績 • 全自動 • SW構成は４パターンに集約 • v5.6 / v5.7 x 新旧イメージ 45
- 47. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 48. PXCの特徴 • Percona XtraDB Cluster の特徴 1. 概要 2. ロック 3. データ同期遅延とFlow Control 4. リカバリの仕組み（SST/IST） 5. 制限事項
- 49. PXC 概要 • マルチライターのMySQL • 用途 • ビルドイン 高可用性 • Read Scalability • Disaster Recovery • スレーブも追加可 49 async slave async slave
- 50. PXCの特徴 • Percona XtraDB Cluster の特徴 1. 概要 2. ロック 3. データ同期遅延とFlow Control 4. リカバリの仕組み（SST/IST） 5. 制限事項
- 51. いつものロック
- 53. PXCのロック 53 時間 行の値 トランザクション１ on ノード1 トランザクション２ on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) (ノード１の更新内容が伝わってくる） T4 A mysql> COMMIT; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
- 54. PXCのロック 54 時間 行の値 トランザクション１ on ノード1 トランザクション２ on ノード2 T1 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘A' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T2 - mysql> BEGIN; Query OK, 0 rows affected (0.00 sec) mysql> UPDATE grplt.tbl SET col1 = 10, who_update = ‘B' WHERE pk = 1; Query OK, 1 row affected (0.00 sec) Rows matched: 1 Changed: 1 Warnings: 0 T3 A mysql> COMMIT; Query OK, 0 rows affected (0.00 sec) (ノード１の更新内容が伝わってくる） T4 A mysql> COMMIT; ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction • 異なるノードでロックが競合した場合、「先勝ち」 • デッドロックは必要に応じてリトライ • LBをSingle-Primaryで運用すれば、従来と同じ挙動に
- 55. マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. 概要 2. ロック 3. データ同期遅延とFlow Control 4. リカバリの仕組み（SST/IST） 5. 制限事項
- 56. Galera Replication http://galeracluster.com/documentation-webpages/certificationbasedreplication.html 56 • PXCはバイナリログとは違う仕組みで レプリケーションする • Write Sets • トランザクション • 更新内容をPKを使って表したもの • Write Sets を伝播することで データ同期する
- 57. 2 データ同期遅延 57 1 Replicate Certification Certification Apply commit finalized commit finalized 遅延 COMMIT OK • クライアントがCOMMITを実行した ノードと、他のノードの間で同期遅延 が発生する • 大きなトランザクションだと顕著
- 58. flow control • 遅れたノードがほかのノードに 「更新をこれ以上受け付けない で」と「待った」をかける • 遅延が拡大するのを防ぐ 58
- 59. flow control を回避するには？ • 大きすぎるトランザクションを避ける • 遅延を許容し、閾値を引き上げる • gcs.fc_limit • 遅延もFCも許容できない場合は Single-Primary 運用 59
- 60. flow control • ステータスでFCの状況が確認可 • wsrep_flow_control_paused_ns • FCで待たされた累積秒数（ナノ秒） • wsrep_flow_control_sent • FC命令を発した累積回数 • 遅れているノードでカウントアップ • wsrep_flow_control_recv • FC命令を受信した累積回数 60
- 61. マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. 概要 2. Galera Replication 3. ロック 4. データ同期遅延とFlow Control 5. リカバリの仕組み（SST/IST） 6. 制限事項
- 62. リカバリの仕組み • Incremental State Transfer • State Snapshot Transfer 62
- 63. Incremental State Transfer • 差分同期 • 「gcache」というファイルに履歴を保存 • gcache.size パラメータでサイズ指定可能 63 1 gcache 2 gcache 差分適用
- 64. State Snapshot Transfer • 全データのコピーを行う • ヤフーではHVに10GbEx2 UPLINK 40GbE を採用 • 100GB / 10min（並列は試してない） • 発生タイミング • 新規ノード追加、長期間停止後、異常終了後 • 同期完了するまで該当ノードは接続を受付ない 64
- 65. マルチライター型 MySQLの特徴 • Percona XtraDB Cluster の特徴 1. ロック 2. データ同期の仕組み（SST/IST） 3. データ同期遅延とFlow Control 4. 制限事項
- 66. PXC 制限事項 • InnoDB のみ利用可 • LOCK TABLESは未サポート • ノード間でロック情報は共有されない • mysqldump –skip-lock • ALTER TABLEは全更新をブロックする • pt-osc ツール や RollingSchemaUpgrade で回避 66
- 67. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 68. MySQL Group Replication • Oracle 純正 • MySQL 5.7.17 (201612) でリリース • PXCとだいたいと同じことができる • Windows な人も大丈夫！
- 69. GR vs PXC (1) 69 Group Replication PXC (galera family) 通常のマスター昇格 1 マルチライター 対応 対応 非対応 2 データ同期の仕組み GTID Replication base Galera / wsrepl GTID or 非GTID 3 バイナリログ 必須 必須ではない 必須 4 Flow Control 有り Certifier / Applier 有り Applier のみ閾値設定可 無し 4 ストレージエンジン InnoDB のみ InnoDB のみ 制限なし 5 ノード間の ロック仕組み 楽観的ロック / 独立したエ ラーコード (First Commit Wins) 楽観的ロック / デッドロック としてエラーが返る (First Commit Wins) 競合しない ※ マルチライターでは ない 6 DDLロック 対象テーブルのみ 全体ロック オンラインDDL
- 70. GR vs PXC (2) 70 Group Replication PXC (galera family) 通常のマスター昇格 7 AutoIncr 衝突回避 ○ 自動 ○ 自動 - 8 クラスタリングや フェイルオーバ機構 ビルドイン(XCom) ビルドイン (GCS) ビルドインされない ※ 自分で用意 9 自動リカバリ(差分) ○ GTID Replication ○ (IST) ○ レプリケーション 10 自動リカバリ(全体) × ○ (SST) × 11 SplitBrain 対応 ○ 対応 ただし、クエリ受付可 ○ 対応 × 非常に難しい 12 ステータス確認 performance_schema GLOBAL STATUS performance_schema or SHOW 13 提供形態 ○ プラグイン Windows も可 △ 別製品。互換性はあ り。Linux のみ。 -
- 71. 本日の内容 1. Yahoo! JAPAN の概要 2. Yahoo! JAPAN のMySQLの歴史と課題 3. プライベートRDBクラウドの構成 4. マルチライター型 MySQL PXCの特徴 5. PXC vs Group Replication 6. まとめ – Q&A
- 72. まとめ 72
- 74. Questions ? 74
- 75. Thank you