MySQL Replication and Scalability

Transcription

1 <Insert Picture Here> MySQL レプリケーション & スケーラビリティ 日本オラクル MySQL Global Business Unit テクニカルアナリスト奥野幹也 2011 年 10 月 28 日

2 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle は 米国オラクル コーポレーション及びその子会社 関連会社の米国及びその他の国における登録商標または商標です 他社名又は製品名は それぞれ各社の商標である場合があります 2

3 期待できること レプリケーションのいろいろな使い方を概観できる レプリケーションの細かいセットアップ方法 ( ファイル修正 パラメタ設定など ) には立ち入らない 開発者 vs. 管理者のアプローチ 3

4 レプリケーションとは? 1 つの MySQL データベースサーバー ( マスター ) から 1 つ以上の MySQL データベースサーバーにデータを複製 ( レプリケート ) します binlog relay log Master Slave 4

5 タイプ : レプリケーションの タイプとフォーマット 非同期 マスターから更新を受け取るために スレーブはずっと接続しておく必要がない 準同期 マスターから スレーブのうち最低一つのスレーブがコミットをリレーログに書き込んだことを確認する 同期 全てのスレーブがコミットをデータベースにまで書込込んだことを確認する フォーマット : 文ベース SQL 文をマスターからスレーブに伝搬する 行ベース 各行の変更をマスターからスレーブに伝搬する Mixed 文ベースと行ベースの混合 5

6 レプリケーションの短所 真の高可用性 (High Availability) ではない システムダウンの際データがロストする 一つ以上のスレーブのフェイルオーバー / フェイルバックが複雑 リカバリしたマスターはバイナリログ (binlog) に記録されなかった変更が欠損する スレーブはマスターから送れるタイムラグがある 6

7 レプリケーションの利用法 高可用性 (High Availability) ( フェイルオーバー ) スケーラビリティ スケールアップ / スケールアウト データセキュリティ / バックアップ 分析 長距離間のデータ配布 7

8 レプリケーション構成 バイナリロギングのメカニズムがベース マスターはレプリケーションには 無関係 それぞれのスレーブがバイナリログとの連動をキープ スレーブは接続 切断可能 マスターとスレーブはそれぞれユニークな id を持つ スレーブはマスターの hostid, バイナリログ名とバイナリログ内の位置を知る必要がある 8

9 MySQL バイナリログ (binlog) バイナリログ (binlog) データベースにおこなった全ての変更を記録する 複数のファイルから構成される 古いバイナリログは削除する Binlog インデックスファイル : どのバイナリログが存在するかという情報を持つ バイナリログは次の用途に使われる : レプリケーション ポイントインタイムリカバリ (Point-in-time recovery) 監査 (Auditing) ( 更新のみの限定的な監査 ) 9

10 バイナリログの例 mysql> create table test (text TEXT); Query OK, 0 rows affected (0.56 sec) mysql> insert into test values ( Replication!"); Query OK, 1 row affected (0.46 sec) mysql> select * from test; text Replication! row in set (0.00 sec) 10

11 バイナリログのイベント mysql> show binlog events G *************************** 2. row *********************** Log_name: mysql-bin Pos: 107 Event_type: Query Server_id: 1 End_log_pos: 210 Info: use `sample`; create table test (text TEXT) *************************** 4. row *********************** Log_name: mysql-bin Pos: 289 Event_type: Query Server_id: 1 End_log_pos: 408 Info: use `sample`; insert into test values ( Replication! ) 11

12 レプリケーションのセットアップ マスターでバイナリログを ON にする edit my.cnf ファイルを修正 : ([mysqld] グループ ) 追加 : log-bin = master-bin 追加 : log-bin-index = master-bin.index ユニークなサーバ id を構成 追加 : server-id = 1 マスターに接続できてレプリケーション権限を持つユーザを別途用意する ( オプション ) 12

13 マスターのクローニング テーブルをフラッシュしてREAD LOCKする 現在のbinlog positionを書き留める マスターのバックアップを作成する マスターのテーブルをUNLOCKする バックアップをスレーブにリストアする スレーブを構成する スレーブをスタートする スレーブがスタートしマスターに追いつく Master Slave 13

14 マスタのクローニング master> flush tables with read lock; master> show master status G *************************** 1. row *************************** File: mysql-bin Position: Binlog_Do_DB: Binlog_Ignore_DB: master $ mysqldump -all-databases host=master-1 > backup.sql master> unlock tables; slave $ mysql -host=slave-1 < backup.sql slave> change master to -> MASTER_HOST = master-1, -> MASTER_PORT = 3306, -> MASTER_USER = slave. -> MASTER_PASSWORD = password_value, -> MASTER_LOG_FILE = mysql-bin > MASTER_LOG_POS = 47710; slave> start slave; バックアップにMysqldumpを使う場合 --master-data=2をつけるとflush tables~とbinlog position の確認 change mater to が不要です 14

15 レプリケーションアーキテクチャの基本 Clients I/O Thread Master dump thread Slave 2 binlog relay log 5 SQL Thread 15

16 一般的なレプリケーション / スケールアウトの利用法 読み取り用ロードバランス 掻きこみ宇ロードバランス データロールベースの配布 地理的領域によるパーティショニング ホットスタンバイによる災害回避 リモートレプリケーションによる災害回避 バックアップ レポート作成 データのパーティショニング又はフィルタリング 16

17 読込 ( 書込ではない ) のスケールアウト 全てのスレーブがマスターから同じ書込負荷を受けるという前提 Avg. Load = Read Load + Write Load (master) Capacity Avg. Load = 6000 (reads) (writes) (master) 10,000 Avg. Load = (4 x 4000) = 22,000 = 55% (master + 3 slaves) 4 x 10,000 40,000 17

18 Clients マスターと 3 つのスレーブ Slaves Reads App/Web Server Writes Master 18

19 書込 ( 読込ではない ) の スケールアウト データシャーディング ( 分化 (splintering) またはパーティショニング ) シャーディングの理由 : 地理的にユーザに近い場所に置く ワーキングセットのサイズを削減する ロードバランシング シャード (shards) のバランシングと移動 シャードの場所が固定でない 19

20 Shards with Central Repository Clients Clients Shard 1 Shard 3 Central Repository Node 1 Node 2 Shard 2 Shard 4 Shard 5 20

21 ホットスタンバイ レプリケーショントポロジで一番簡単 ホットスタンバイがマスターを二重化 潜在的な問題 : 新しいマスタからのレプリケーションは バイナリログの位置 (binlog position) をオリジナルのものから翻訳する必要がある ホットスタンバイの変更はスレーブにマッチしないかもしれない 修復されたマスターは追加のバイナリログの変更を持つかもしれない 21

22 Master ホットスタンバイ binlog Slave Failover relay log relay log binlog Hot Standby 22

23 リモートレプリケーション 地理的に離れた二つのデータセンター間のレプリケーション 災害時復旧 (Disaster recovery) ユーザの近くにデータを置く SSL によるセキュリティ / 暗号化 組み込みのレプリケーション通信暗号化を使う SSL tunnel 作成のために Stunnell を使う Ssh を tunnel mode で使う 23

24 レプリケーションを バックアップに利用する 一般的なレプリケーションのバックアップ利用 バックアップとリカバリ ポイントインタイムリカバリ (PITR) スレーブを停止 バックアップを実行 物理ファイルコピー (tar, WinZip) mysqldumpの使用 MySQL Enterprise Backup(MEB) スレーブ停止の必要なし 24

25 レポートの生成 マスターサーバーのストレスを取り除く レポート作成の間はスレーブを停止 レポートはビジネストランザクションほどクリティカルなものではない 手順は自動化できるかもしれない スレーブで真夜中前にレプリケーションを停止 真夜中後 マスターから最新のバイナリログ位置を取得 スレーブをスタートして この位置に達するまで走らせる レポート作成実行 スレーブを再起動 25

26 バイナリログのフィルタリング my.cnf ファイルオプション : binlog-do-db, 例 : [mysqld] binlog-ignore-db = two_db binlog-ignore-db これはマスター側でのフィルタリング スレーブ側で行った方が自由度が高く問題が少ない > USE two_db; INSERT INTO table1 VALUES (1),(2); > USE two_db; INSERT INTO one_db.table1 VALUES (1),(2); > USE two_db; INSERT INTO one_db.table2, three_db.table1 SET a = b; 例えばデータベース. テーブルで書く代わりに use 使う INSERT INTO books.pages values( Binlog, 143 ); Instead, write: USE books; INSERT INTO pages values ( Binlog, 143 ); 26

27 階層レプリケーション / リレースレーブ マスターがレプリケートできるスレーブ数は限られる リレースレーブを使うことによりマスターの付加を軽くすることができる マスターから来る変更をバイナリログに記録 データベースに変更を書かないように Blackhole エンジンを使う リレースレーブはさらなる遅延を発生させる 階層型のセットアップは通常より難しい 27

28 スレーブのリレー Clients Slaves Master Relay Slave 28

29 レプリケーションのトポロジ Single Chain Circular Multiple Multi - Master Multi - Circular Circular 構成は運用や障害の対処が難しいことに注意が必要 29

30 MySQL 5.6 の新機能 クラッシュセーフのスレーブ レプリケーション チェックサム バイナリログサイズの削減 完全 / 部分 RBR (rowbased replication: 行ベースレプリケーション ) イメージ用のオプション 時間遅延レプリケーション 情報ログイベント バイナリログのリモートバックアップ サーバ UUID s (Universally Unique Identifier) DM Download! 30

31 MySQL 5.6 の新機能 マルチスレッドスレーブ スレーブのパフォーマンス向上 負荷が並列に適用される : それぞれのデータベースへの変更が個別に適用 コミットされる Transaction 1 Relay Log T2 Database 01 Transaction 2 Database 02 IO Thread SQL Thread Coordination SQL Threads (Workers ) T1 Database 03 Databases DM Download! 31

32 32

33 33

34 34