mysql レプリケーション スケーラビリティ ·...
TRANSCRIPT
<Insert Picture Here>
MySQLレプリケーション&スケーラビリティ
日本オラクルMySQL Global Business Unit
テクニカルアナリスト 奥野幹也2011年10月28日
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。
Oracleは、米国オラクル・コーポレーション及びその子会社、関連会社の米国及びその他の国における登録商標または商標です。他社名又は製品名は、それぞれ各社の商標である場合があります。
2
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
期待できること
• レプリケーションのいろいろな使い方を概観できる
• レプリケーションの細かいセットアップ方法(ファイル修正、パラメタ設定など)には立ち入らない
• 開発者 vs. 管理者のアプローチ
3
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションとは?
1 つのMySQLデータベースサーバー(マスター)から 、1 つ以上のMySQLデータベースサーバーにデータを複製(レプリケート)します。
Master Slave
binlog relay log
4
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションのタイプとフォーマット
• タイプ:
– 非同期 –マスターから更新を受け取るために、スレーブはずっと接続しておく必要がない。
– 準同期 –マスターから、スレーブのうち最低一つのスレーブがコミットをリレーログに書き込んだことを確認する。
– 同期 –全てのスレーブがコミットをデータベースにまで書込込んだことを確認する。
• フォーマット:
– 文ベース – SQL文をマスターからスレーブに伝搬する
– 行ベース –各行の変更をマスターからスレーブに伝搬する
– Mixed –文ベースと行ベースの混合
5
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションの短所
• 真の高可用性(High Availability)ではない
–システムダウンの際データがロストする
一つ以上のスレーブのフェイルオーバー/フェイルバックが複雑
リカバリしたマスターはバイナリログ(binlog)に記録されなかった変更が欠損する
スレーブはマスターから送れるタイムラグがある
6
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションの利用法
• 高可用性(High Availability) (フェイルオーバー)
• スケーラビリティ–スケールアップ/スケールアウト
• データセキュリティ/バックアップ
• 分析
• 長距離間のデータ配布
7
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーション構成
• バイナリロギングのメカニズムがベース
• マスターはレプリケーションには「無関係」
• それぞれのスレーブがバイナリログとの連動をキープ
• スレーブは接続・切断可能
• マスターとスレーブはそれぞれユニークなidを持つ
• スレーブはマスターのhostid,バイナリログ名とバイナリログ内の位置を知る必要がある
8
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
MySQL バイナリログ(binlog)
• バイナリログ(binlog) –データベースにおこなった全ての変更を記録する
– 複数のファイルから構成される
– 古いバイナリログは削除する
– Binlog インデックスファイル: どのバイナリログが存在するかという情報を持つ
• バイナリログは次の用途に使われる:
– レプリケーション
– ポイントインタイムリカバリ(Point-in-time recovery)
– 監査(Auditing) (更新のみの限定的な監査)
9
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
バイナリログの例
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! |
+-------------------+
1 row in set (0.00 sec)
10
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
バイナリログのイベント
mysql> show binlog events¥G
*************************** 2. row ***********************
Log_name: mysql-bin.000001
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.000001
Pos: 289
Event_type: Query
Server_id: 1
End_log_pos: 408
Info: use `sample`; insert into test values (“Replication!”)
11
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションのセットアップ
• マスターでバイナリログをONにする – edit my.cnf ファイルを修正: ([mysqld]グループ)
– 追加: log-bin = master-bin
– 追加: log-bin-index = master-bin.index
• ユニークなサーバidを構成
– 追加: server-id = 1
• マスターに接続できてレプリケーション権限を持つユーザを別途用意する(オプション)
12
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
マスターのクローニング
• テーブルをフラッシュしてREAD LOCKする
• 現在のbinlog positionを書き留める
• マスターのバックアップを作成する
• マスターのテーブルをUNLOCKする
• バックアップをスレーブにリストアする
• スレーブを構成する
• スレーブをスタートする
• スレーブがスタートしマスターに追いつく
Master
Slave
13
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
マスタのクローニング
master> flush tables with read lock;
master> show master status¥G
*************************** 1. row ***************************
File: mysql-bin.000001
Position: 47710
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.000001’
-> MASTER_LOG_POS = 47710;
slave> start slave;
バックアップにMysqldumpを使う場合--master-data=2を
つけるとflush tables~とbinlog
positionの確認、change mater toが不要です。
14
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションアーキテクチャの基本
Master Slave
binlog
relay log
Clients
I/O Thread
SQL Thread
1
2
dump thread
3 4
5
15
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
一般的なレプリケーション/スケールアウトの利用法
• 読み取り用ロードバランス
• 掻きこみ宇ロードバランス
– データロールベースの配布
– 地理的領域によるパーティショニング
• ホットスタンバイによる災害回避
• リモートレプリケーションによる災害回避
• バックアップ
• レポート作成
• データのパーティショニング又はフィルタリング
16
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
読込(書込ではない)のスケールアウト
• 全てのスレーブがマスターから同じ書込負荷を受けるという前提
Avg. Load = ∑ Read Load + ∑ Write Load(master) ∑ Capacity
Avg. Load = 6000 (reads) + 4000 (writes)(master) 10,000
Avg. Load = 6000 + (4 x 4000) = 22,000 = 55%(master + 3 slaves) 4 x 10,000 40,000
17
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
マスターと3つのスレーブ
Master
App/WebServer
SlavesClients
Writes
Reads
18
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
書込(読込ではない)のスケールアウト
• データシャーディング (分化(splintering)またはパーティショニング)
• シャーディングの理由:
– 地理的にユーザに近い場所に置く
– ワーキングセットのサイズを削減する
– ロードバランシング
• シャード(shards)のバランシングと移動
• シャードの場所が固定でない
19
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
Shards with Central Repository
Node 1 Node 2
Shard 1Shard 3
Shard 2Shard 4Shard 5
ClientsClients
CentralRepository
20
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
ホットスタンバイ
• レプリケーショントポロジで一番簡単• ホットスタンバイがマスターを二重化• 潜在的な問題:
– 新しいマスタからのレプリケーションは、バイナリログの位置(binlog position)をオリジナルのものから翻訳する必要がある。
– ホットスタンバイの変更はスレーブにマッチしないかもしれない。
– 修復されたマスターは追加のバイナリログの変更を持つかもしれない。
21
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
ホットスタンバイ
Master
Hot Standby
Failover
Slavebinlog
relay log
binlog
relay log
22
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
リモートレプリケーション
• 地理的に離れた二つのデータセンター間のレプリケーション
• 災害時復旧(Disaster recovery)
• ユーザの近くにデータを置く
• SSLによるセキュリティ/暗号化
– 組み込みのレプリケーション通信暗号化を使う
– SSL tunnel作成のためにStunnellを使う
– Sshをtunnel modeで使う
23
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションをバックアップに利用する
• 一般的なレプリケーションのバックアップ利用
– バックアップとリカバリ
– ポイントインタイムリカバリ(PITR)
• スレーブを停止、バックアップを実行
– 物理ファイルコピー(tar, WinZip)
– mysqldumpの使用
• MySQL Enterprise Backup(MEB)
– スレーブ停止の必要なし
24
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レポートの生成
• マスターサーバーのストレスを取り除く• レポート作成の間はスレーブを停止
• レポートはビジネストランザクションほどクリティカルなものではない
• 手順は自動化できるかもしれない
– スレーブで真夜中前にレプリケーションを停止
– 真夜中後、マスターから最新のバイナリログ位置を取得
– スレーブをスタートして、この位置に達するまで走らせる
– レポート作成実行
– スレーブを再起動
25
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
バイナリログのフィルタリング
• my.cnf ファイルオプション: binlog-do-db, binlog-ignore-db– [mysqld]
– binlog-ignore-db = two_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
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
階層レプリケーション/リレースレーブ
• マスターがレプリケートできるスレーブ数は限られる
• リレースレーブを使うことによりマスターの付加を軽くすることができる
– マスターから来る変更をバイナリログに記録
– データベースに変更を書かないようにBlackholeエンジンを使う
• リレースレーブはさらなる遅延を発生させる
• 階層型のセットアップは通常より難しい
27
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
スレーブのリレー
Relay SlaveMaster
SlavesClients
28
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
レプリケーションのトポロジ
Single
Multiple
Chain Circular
Multi - CircularMulti - Master
Circular構成は運用や障害の対処が難しいことに注意が必要
29
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
MySQL 5.6の新機能
•クラッシュセーフのスレーブ
•レプリケーション・チェックサム
•バイナリログサイズの削減 –完全/部分 RBR (row-based replication:行ベースレプリケーション) イメージ用のオプション
•時間遅延レプリケーション
•情報ログイベント
•バイナリログのリモートバックアップ
•サーバ UUID’s (Universally Unique Identifier)
DMDownload!
30
Copyright© 2011, Oracle. All rights reserved.Copyright© 2011, Oracle. All rights reserved.
MySQL 5.6の新機能マルチスレッドスレーブ –スレーブのパフォーマンス向上
負荷が並列に適用される: それぞれのデータベースへの変更が個別に適用、コミットされる
DMDownload!IO Thread SQL Thread
Coordination
SQL
Threads
(Workers
)
Databases
Database 01
Database 02
Database 03
Relay Log
Transaction 1
Transaction 2
T2
T1
31
Copyright© 2011, Oracle. All rights reserved. 32
Copyright© 2011, Oracle. All rights reserved. 33
Copyright© 2011, Oracle. All rights reserved. 34