MySQL レプリケーションスケーラビリティ · •データシャーディング(分化(splintering)またはパーティショニング) •シャーディングの理由:

<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


期待できること

• レプリケーションのいろいろな使い方を概観できる

• レプリケーションの細かいセットアップ方法(ファイル修正、パラメタ設定など)には立ち入らない

• 開発者 vs. 管理者のアプローチ

3


レプリケーションとは?

1 つのMySQLデータベースサーバー(マスター)から、1 つ以上のMySQLデータベースサーバーにデータを複製(レプリケート)します。

Master Slave

binlog relay log

4


レプリケーションのタイプとフォーマット

• タイプ:

– 非同期 –マスターから更新を受け取るために、スレーブはずっと接続しておく必要がない。

– 準同期 –マスターから、スレーブのうち最低一つのスレーブがコミットをリレーログに書き込んだことを確認する。

– 同期 –全てのスレーブがコミットをデータベースにまで書込込んだことを確認する。

• フォーマット:

– 文ベース – SQL文をマスターからスレーブに伝搬する

– 行ベース –各行の変更をマスターからスレーブに伝搬する

– Mixed –文ベースと行ベースの混合

5


レプリケーションの短所

• 真の高可用性(High Availability)ではない

–システムダウンの際データがロストする

一つ以上のスレーブのフェイルオーバー/フェイルバックが複雑

リカバリしたマスターはバイナリログ(binlog)に記録されなかった変更が欠損する

スレーブはマスターから送れるタイムラグがある

6


レプリケーションの利用法

• 高可用性(High Availability) (フェイルオーバー)

• スケーラビリティ–スケールアップ/スケールアウト

• データセキュリティ/バックアップ

• 分析

• 長距離間のデータ配布

7


レプリケーション構成

• バイナリロギングのメカニズムがベース

• マスターはレプリケーションには「無関係」

• それぞれのスレーブがバイナリログとの連動をキープ

• スレーブは接続・切断可能

• マスターとスレーブはそれぞれユニークなidを持つ

• スレーブはマスターのhostid,バイナリログ名とバイナリログ内の位置を知る必要がある

8


MySQL バイナリログ(binlog)

• バイナリログ(binlog) –データベースにおこなった全ての変更を記録する

– 複数のファイルから構成される

– 古いバイナリログは削除する

– Binlog インデックスファイル: どのバイナリログが存在するかという情報を持つ

• バイナリログは次の用途に使われる:

– レプリケーション

– ポイントインタイムリカバリ(Point-in-time recovery)

– 監査(Auditing) (更新のみの限定的な監査)

9


バイナリログの例

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


バイナリログのイベント

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


レプリケーションのセットアップ

• マスターでバイナリログをONにする – edit my.cnf ファイルを修正: ([mysqld]グループ)

– 追加: log-bin = master-bin

– 追加: log-bin-index = master-bin.index

• ユニークなサーバidを構成

– 追加: server-id = 1

• マスターに接続できてレプリケーション権限を持つユーザを別途用意する(オプション)

12


マスターのクローニング

• テーブルをフラッシュしてREAD LOCKする

• 現在のbinlog positionを書き留める

• マスターのバックアップを作成する

• マスターのテーブルをUNLOCKする

• バックアップをスレーブにリストアする

• スレーブを構成する

• スレーブをスタートする

• スレーブがスタートしマスターに追いつく

Master

Slave

13


マスタのクローニング

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


レプリケーションアーキテクチャの基本

Master Slave

binlog

relay log

Clients

I/O Thread

SQL Thread

1

2

dump thread

3 4

5

15


一般的なレプリケーション/スケールアウトの利用法

• 読み取り用ロードバランス

• 掻きこみ宇ロードバランス

– データロールベースの配布

– 地理的領域によるパーティショニング

• ホットスタンバイによる災害回避

• リモートレプリケーションによる災害回避

• バックアップ

• レポート作成

• データのパーティショニング又はフィルタリング

16


読込(書込ではない)のスケールアウト

• 全てのスレーブがマスターから同じ書込負荷を受けるという前提

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


マスターと3つのスレーブ

Master

App/WebServer

SlavesClients

Writes

Reads

18


書込(読込ではない)のスケールアウト

• データシャーディング (分化(splintering)またはパーティショニング)

• シャーディングの理由:

– 地理的にユーザに近い場所に置く

– ワーキングセットのサイズを削減する

– ロードバランシング

• シャード(shards)のバランシングと移動

• シャードの場所が固定でない

19


Shards with Central Repository

Node 1 Node 2

Shard 1Shard 3

Shard 2Shard 4Shard 5

ClientsClients

CentralRepository

20


ホットスタンバイ

• レプリケーショントポロジで一番簡単• ホットスタンバイがマスターを二重化• 潜在的な問題:

– 新しいマスタからのレプリケーションは、バイナリログの位置(binlog position)をオリジナルのものから翻訳する必要がある。

– ホットスタンバイの変更はスレーブにマッチしないかもしれない。

– 修復されたマスターは追加のバイナリログの変更を持つかもしれない。

21


ホットスタンバイ

Master

Hot Standby

Failover

Slavebinlog

relay log

binlog

relay log

22


リモートレプリケーション

• 地理的に離れた二つのデータセンター間のレプリケーション

• 災害時復旧(Disaster recovery)

• ユーザの近くにデータを置く

• SSLによるセキュリティ/暗号化

– 組み込みのレプリケーション通信暗号化を使う

– SSL tunnel作成のためにStunnellを使う

– Sshをtunnel modeで使う

23


レプリケーションをバックアップに利用する

• 一般的なレプリケーションのバックアップ利用

– バックアップとリカバリ

– ポイントインタイムリカバリ(PITR)

• スレーブを停止、バックアップを実行

– 物理ファイルコピー(tar, WinZip)

– mysqldumpの使用

• MySQL Enterprise Backup(MEB)

– スレーブ停止の必要なし

24


レポートの生成

• マスターサーバーのストレスを取り除く• レポート作成の間はスレーブを停止

• レポートはビジネストランザクションほどクリティカルなものではない

• 手順は自動化できるかもしれない

– スレーブで真夜中前にレプリケーションを停止

– 真夜中後、マスターから最新のバイナリログ位置を取得

– スレーブをスタートして、この位置に達するまで走らせる

– レポート作成実行

– スレーブを再起動

25


バイナリログのフィルタリング

• 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


階層レプリケーション/リレースレーブ

• マスターがレプリケートできるスレーブ数は限られる

• リレースレーブを使うことによりマスターの付加を軽くすることができる

– マスターから来る変更をバイナリログに記録

– データベースに変更を書かないようにBlackholeエンジンを使う

• リレースレーブはさらなる遅延を発生させる

• 階層型のセットアップは通常より難しい

27


スレーブのリレー

Relay SlaveMaster

SlavesClients

28


レプリケーションのトポロジ

Single

Multiple

Chain Circular

Multi - CircularMulti - Master

Circular構成は運用や障害の対処が難しいことに注意が必要

29


MySQL 5.6の新機能

•クラッシュセーフのスレーブ

•レプリケーション・チェックサム

•バイナリログサイズの削減 –完全/部分 RBR (row-based replication：行ベースレプリケーション) イメージ用のオプション

•時間遅延レプリケーション

•情報ログイベント

•バイナリログのリモートバックアップ

•サーバ UUID’s (Universally Unique Identifier)

DMDownload!

30


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



Documents

MySQL レプリケーション スケーラビリティ · •データシャーディング(分化(splintering)または パーティショニング) •シャーディングの理由:

MySQL レプリケーションスケーラビリティ · •データシャーディング(分化(splintering)またはパーティショニング) •シャーディングの理由: