MySQL Technology Cafe No3

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |
MySQL高可用性構成
updated: 2019/05/09
日本オラクル株式会社
MySQL Global Business Unit

Safe Harbor Statement
以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。
また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはでき
ません。以下の事項は、マテリアルやコード、機能を提供することをコミットメントするも
のではない為、購買決定を行う際の判断材料になさらないで下さい。
オラクル製品に関して記載されている機能の開発、リリースおよび時期については、
弊社の裁量により決定されます。

InnoDB NDB
はじめに

はじめに
App Servers with
MySQL Router
MySQL Group Replication
MySQL Shell
Setup, Manage,
Orchestrate

InnoDB Cluster
App Servers with
MySQL Router
MySQL Group Replication
MySQL Shell
Setup, Manage,
Orchestrate
“高可用性は、MySQLにとって、
最も重要な中核の機能です！”
InnoDB Clusterで更に高いレベル
の可用性を提供します。

MySQL Group Replicationとは?
• 自動フェイルオーバー
• 構成の拡張/縮小
• 単一障害点無し
• 自動的に再構成
Application
MySQL Nodes Replication
Plugin
API
MySQL Server
Group Comms

Bが新しい
マスターに昇格
構成変更
冗長性: マスターがクラッシュした場合, スレーブをマスターに昇格
概要: レプリケーションの用途
障害発生障害発生
B B
C C

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. 8
Replication
InnoDB
MySQL Shell
MySQL
InnoDB
Cluster

Copyright © 2018, Oracle and/or its affiliates. All rights reserved.
MySQL Cluster
9

MySQL
Cluster
Multi
Master
Mission
Critical
In Memory
99.999
-
50,000,000
100,000,000
150,000,000
200,000,000
250,000,000
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32
Readspersecond
Data Nodes
FlexAsync Reads

• 永続性を持つインメモリテーブル＋ディスクテーブル
• 低レイテンシ
リアルタイム
• 自動シャーディング、マルチマスタ
• ACIDトランザクション、OLTPとリアルタイム分析
参照更新性能の
高い拡張性
• シェアードナッシング、単一障害点無し
• 自動復旧、オンラインメンテナンス
99.999% の可用性
• キー・バリュー型＋複雑なリレーショナルな処理
• SQL + Memcached + JavaScript + Java + HTTP/REST & C++
NoSQL + SQL
• オープンソース＋商用版運用支援ツール
• 特殊なハードウェア不要、管理監視ツール群、サポート
低コスト
MySQL Cluster の特徴

MySQL Clusterアーキテクチャ
データノード
ノード・グループ1
F1
F3
F3
F1
ノード1ノード2
ノード・グールプ 2
F2
F4
F4
F2
ノード3ノード4
アプリケーションノード
管理ノード管理ノード
RESTJPA

MySQL Clusterを構成する3種類のノード
• データノード
– データ、インデックスを管理し、トランザクションを制御するノード
– MySQL Clusterの中核となるノード
• アプリケーションノード（SQLノード）
– アプリケーションとデータノードをつなぐインターフェースとなるノード
– SQLで処理する場合は、MySQL Serverが稼働する
• 管理ノード
– MySQL Cluster全体を管理するノード
– 各ノードの設定管理、クラスタ全体の起動/停止、オンラインバックアップ、など

Data Node 1
Data Node 2
Data Node 3
Data Node 4
A fragment is a copy of a partition
Number of fragments = # of partitions * # of replicas
Table T1
P2
P3
P4
Px Partition
4 Partitions * 2 Replicas = 8 Fragments
P1
Automatic Data Partitioning
Nodes & Node Groups
Copyright 2011 Oracle Corporation 14

Data Node 1
Data Node 2
F1
Primary Fragment
Secondary Fragment
Data Node 3
Data Node 4Fx
Fx
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1
Primary Fragment
Secondary Fragment
F1
Data Node 3
Data Node 4Fx
Fx
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1
Primary Fragment
Secondary Fragment
F3 F1
Data Node 3
Data Node 4Fx
Fx
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1 F3
Primary Fragment
Secondary Fragment
F3 F1
Data Node 3
Data Node 4Fx
Fx
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1 F3
Primary Fragment
Secondary Fragment
F3 F1
Data Node 3
Data Node 4
F2 F4
F4 F2
Fx
Fx
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1 F3
Primary Fragment
Secondary Fragment
F3 F1
Data Node 3
Data Node 4
F2 F4
F4 F2
Node Group 1
Node Group 2
Fx
Fx
Node groups are created automatically
# of groups = # of data nodes / # of
replicas
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Data Node 1
Data Node 2
F1 F3
Primary Fragment
Secondary Fragment
F3 F1
Data Node 3
Data Node 4
F2 F4
F4 F2
Node Group 1
Node Group 2
Fx
Fx
As long as one data node in each
node group is running we have a
complete copy of the data
Table T1
P2
P3
P4
Px Partition
P1
Nodes & Node Groups

Network Memory
CPU Disk Drive
MySQL Cluster 優先順位
1 2
3 4

• 可能な限り高速
– 性能に直結
– 対障害性向上
• Network Bonding
• Node Group間のNetwork分離
• それでもVM環境化で利用の際
– halt_poll_ns or
monitor_control.desched = false
– SchedulerSpinTimer = 100
• Exsample
Network
Clients
Load
Balancer(s)
Bonding
Redundant switches

Memory ( Data Node )
• データ格納量に直結
• データノードの拡張は、一番小さいMemory Serverが基準
• DataMemory
• SharedGlobalMemory
– MaxOfTables
– MaxOfOderedIndexs
– MaxOfUniqueHashIndexs
– MaxNoOfConcurrentTransactions
– MaxNoOfConcurrentOperations
– ……..

• ndbd / ndbmtd
• /proc/cpuinfo
• CPUのcoreにスレッドをバインド
– ldm :ローカルクエリーハンドラ
– io(1) : I/O 専用スレッド
– tc :トランザクションコーディネータス
レッド
– main(1) :スキーマ管理
– rep(1) :レプリケーションスレッド
– recv :受信スレッド
– send :送信スレッド
CPU ( Data Node )
• ThreadConfig (Sample)
ThreadConfig=
ldm{count=8,cpubind=1,2,3,4,5,6,7,8},
main={cpubind=9},
io={cpubind=9},
rep={cpubind=10},
tc{count=4,cpubind=11,12,13,14},
recv={count=3,cpubind=15,16,17},
send{count=3,cpubind=18,19,20}

• Local Check Point (LCP)
– Data Memory -> Disk (File) : 2世代
• Global Check Point (GCP)
– REDO (更新データ) -> Disk(File) : 4
• Backup File
– ( ndb_mgm : START BACKUP )
• File systesm : Ext4 < XFS
• CompressLCP
Disk Drive ( Data Node )
メモリ上の
データ
DataMemory
LCP
LCP(最新世代)
LCP(一世代前)
GCP
GCP
GCP
GCP
GCP
GCP

MySQL Clusterにチャレンジ!!
• my.cnf / config.ini
• TABLE設計
– 1行の最大許容サイズは14000バイト
• テーブルは可能な限り小さく
– 8個のServiceのON/OFFは 1Byteで表現できる
• TEXT,BLOBは極力避ける
• SQL
– Data Node間をまたぐデータの取得は避ける
– トランザクションは細かく
• Data Nodeの再起動時間
0 0 0 0 0 0 0 0

More Tips

• デフォルトでは、データは各ノードに主キー
のハッシュ値に基づいて分散されるため、
ランダムに分散される
• パーティショニングテーブルを使って
シャーディングキーを変更でき、特定のキー
のデータを同じデータノードに格納可能
– トランザクションで必要となるデータが同じ
パーティション（同じデータノード）にある場合、
ノード間の通信量が少なくなる
⇒ 高速になる
• 頻繁に実行されるクエリーでアクセスする
行を同じパーティションに格納することで
高速化できる可能性がある
Distribution Aware Apps
SELECT SUM(population) FROM towns WHERE country=“UK”;
SELECT SUM(population) FROM towns WHERE town=“Boston”;

• 複数テーブルを意識したパーティション設計
• 同じ情報を持つ列でパーティショニングする
ことで、複数テーブルであっても同じ属性の
データを同じパーティション（同じデータ
ノード）に格納できる
• 例）
• 特定のデータノードに負荷が集中して
ボトルネックが発生する可能性に注意
Distribution Aware Apps – 複数テーブル
ALTER TABLE service_ids PARTITION BY KEY(sub_id);

アダプティブ・クエリー・ローカライゼーション(AQL)
mysqld
データ・ノード
mysqld
A
Q
L
データ・ノード
70倍以上の
パフォーマンス向上
• シャード間で複雑なクエリを実行
– JOIN処理をデータ・ノードに移行
– 並列実行
– 一つの結果セットをMySQLに戻す
• これまでは性能的に難しかった
処理も実行可能に
– リアルタイム分析
– レコメンデーション・エンジン
– クリックストリームを分析

AQL – 使用方法
• ndb_join_pushdown がONで有効（デフォルト）
• AQLを使用するためのルール:
– 結合する列のタイプは全て完全に同じ
– BLOBまたはTEXT列への参照なし
– 明示的ロックなし
– 結合内の子テーブルはref、eq_ref、またはconstを使用してアクセス
– テーブルは[LINEAR] HASH、 LIST、または RANGEを使用して明示的にパーティショニングされていない
– クエリー・プランが ‘Using join buffer’ を選択していない
– 結合のルートが eq_ref または const の場合、子テーブルは eq_refで結合
• 各テーブルに対し ANALYZE TABLE <tab-name> を実行
• EXPLAIN を使用してどのコンポーネントが移行されるか確認:
– Extra: Child of 'd' in pushed join@1

• バックアップからの読み取りは、
どのコピーからもデータの読み取り
を可能にします。
• 7.4までは、全ての参照処理は、
プライマリーフラグメントのみ参照。
• 処理内容によっては3割以上の
パフォーマンス向上
Reading from backup (NDB_READ_BACKUP, READ_BACKUP)
Node Group
Data Node 1 Data Node 2

Fully replicated (FULLY_REPLICATED)
• Fully replicatedは、対象テーブルに対して、どのデータノードにおいても、
ローカルでデータの読み書きが出来るようになります。
• 静的データに最適で、より高速なJOIN処理を実現可能。
Node Group
Node Group

MySQL Cluster 7.6
Copyright © 2018, Oracle and/or its affiliates. All rights reserved.
管理SQL処理の改善Capacity & Scaleout
・TBに対応向け再設計
・Diskデータでの高速化
・起動時間の高速化
・Backup処理の高速化
・Faster Joins
・Parallel Join
・CSVの並列インポート
・MySQL Enterprise
Monitor の統合
・Cluster Manager
and Configurator

Cluster 7.6: New! Up to 50% faster JOIN performance
SELECT
affiliates.uniquekey, affiliates_json, artists.name, artists.id, genres.name, genres.id,
genres.priorityid, subgenres.id, subgenres.name, meta.name, meta.id, meta.json,
formats.priority + formatclasses.priority + formattypes.priority,
media.path, media.id, cover.id, cover.name, coverclasses.id, coverclasses.name,
covertypes.id, covertypes.name
FROM
affiliates, meta, media, cover, coverclasses, covertypes, artistsmap, artists,
subgenresmap, subgenres, genres
WHERE
artiststmap.id = meta.id AND artiststmap.id = artists.id AND subgenremap.id = meta.id AND
subgenremap.id = subgenres.id AND subgenres.id = genres.id AND media.id = meta.id AND
media.id = formats.id AND cover.coverclassid = coverclasses.id AND
cover.canaddtocapability = 'Y' AND coverclasses.covertypeid = covertypes.id AND
covertypes.covertypeid IN (2) AND (media.id IN (31, 8, 76)) AND
affiliates.metaid = meta.id AND affiliates.affiliateid = ‘2';

Cluster 7.6: New! Partial Local Checkpoint
• Terabyteクラスタにむけローカルチェックポイントの再設計
• 部分的なCPは、データメモリの一部と変更のみ保存
• ディスク容量の削減（REDO / CP）
• チェックポイントの高速解放
• 頻繁に変更されないデータの書き込み率の削減
• 最大6倍高速
＊アップグレード時はinitial node restartが必要

MySQL NDB Cluster 8.0
MySQL
5.5
MySQL
5.6
MySQL
5.7
MySQL
8.0
Cluster
7.3
Cluster
7.5
Cluster
7.6
Cluster
8.0

MySQL NDB Cluster 8.0
• MySQL 8.0サーバーと並行開発
• テーブルの追加メタデータの管理方法を変更
• 外部キーをサポート

Replication

• GTIDの未サポート
• default_storage_engine=InnoDB
• ndb_apply_status
CREATE TABLE `ndb_apply_status` (
`server_id` INT(10) UNSIGNED NOT NULL,
`epoch` BIGINT(20) UNSIGNED NOT NULL,
`log_name` VARCHAR(255) CHARACTER SET latin1
COLLATE latin1_bin NOT NULL,
`start_pos` BIGINT(20) UNSIGNED NOT NULL,
`end_pos` BIGINT(20) UNSIGNED NOT NULL,
PRIMARY KEY (`server_id`) USING HASH
) ENGINE=INNODB DEFAULT CHARSET=latin1;
NDB cluster To MySQL Server(InnoDB)
SQL Node InnoDB

• データセンタ間でData Nodeを分割
– センタ間の同期レプリケーションおよび
自動フェイルオーバー
– ネットワーク・パーティションを処理す
るための通信速度が重要
• HAオプションの拡張
• アクティブ/アクティブ構成
– 競合処理の必要なし
マルチサイトクラスタリング
Node Group 1
Node Group 2
Data Node 1
Data Node 3
Data Node 2
Data Node 4

• データセンタ間での完全なクラスタ
の複製
– DRおよびデータのローカリティ
– Active/Passiveによる耐障害性向上
• 通常は１方向レプリケーション
– アプリケーションおよびスキーマの変
更の必要性の排除
– 競合処理の必要なし
• Replicationは非同期
Active/Passive Geographic Replication
Geo Replication
(非同期Replication)
Passive
Active

• データセンタ間での完全なクラスタ
の複製
– DRおよびデータのローカリティ
– パッシブリソースなし
• 単純化されたアクティブ/アクティブ
レプリケーション
– アプリケーションおよびスキーマの変
更の必要性の排除
– トランザクションレベルのロールバック
• (競合の検出)
• Replicationは非同期
Active/Active Geographic Replication
Geo Replication
(非同期Replication)
Active
Active

Active/Active Geographic Replication
• 拠点間のネット―ワーク帯域がデータの同期に直結
• Replicationは非同期の為、データの競合が発生
– データ競合に関する処理が必要

Geographic Replication – 競合検出
• GCI（グローバル・チェックポイント・インデックス）を反映することで、アプリ
ケーションは、潜在的に競合する各テーブルのタイムスタンプフィールドを
維持する必要がなくなります
– 2つのマスターのうちの1つが「プライマリ」として機能し、プライマリ・クラスタとセカン
ダリ・クラスタで同じ順序で変更が適用されなかった場合を確認する
– プライマリは、セカンダリ・トランザクションのすべての競合するトランザクション（オプ
ションで競合する行）を上書きします
• mysql.ndb_replicationのNDB $ EPOCH（）またはNDB $ EPOCH_TRANS（）
• 概要と実例：http://clusterdb.com/u/conf
• 日本語による詳細：https://dev.mysql.com/doc/refman/5.6/ja/mysql-
cluster-replication-conflict-resolution.html

Geographic Replication – 競合検出手順
• マスターカラムの制御：--ndb-log-update-as-write = OFF
• ndb_replication システムテーブルの作成
• 適用する競合解決関数の選択
• NDB$OLD(column_name)
• NDB$MAX(column_name)
• NDB$MAX_DELETE_WIN(column_name)
• NDB$EPOCH(),NDB$EPOCH_TRANS()
CREATE TABLE mysql.ndb_replication (
db VARBINARY(63),
table_name VARBINARY(63),
server_id INT UNSIGNED,
binlog_type INT UNSIGNED,
conflict_fn VARBINARY(128),
PRIMARY KEY USING HASH (db, table_name,
server_id)
) ENGINE=NDB
PARTITION BY KEY(db,table_name);

競合解決関数
• NDB$OLD(column_name) *
– column_name の値がマスター(「前」のイメージのカラム値)とスレーブで同じである
場合、更新を適用
• NDB$MAX(column_name) *
– 「もっとも大きいタイムスタンプが優先」
• NDB$MAX_DELETE_WIN(column_name) *
– 「もっとも大きいタイムスタンプ、削除が優先」
• NDB$EPOCH,NDB$EPOCH_TRANS()
– 複製されたエポックが、スレーブで発生した変更に関連してスレーブの MySQL
Cluster で適用される順番を追跡
– (NDB$EPOCH() :各行を再編成/DB$EPOCH_TRANS() :トランザクションを再編成)
* アプリケーション側に
て最終的なデータの整
合性の確認が必要

MySQL Cluster Carrier Grade Edition

MySQL Enterprise Support
• 最大のMySQLのエンジニアリングおよびサポート組織
• MySQL開発チームによるサポート
• 29言語で世界クラスのサポートを提供
• メンテナンス・リリース、バグ修正、パッチ、アップデートの提供
• 24時間x365日サポート
• 無制限サポート・インシデント
• MySQL コンサルティング・サポート
Get immediate help for any MySQL
issue, plus expert advice
～リモートDBAとして、是非ご活用ください！！～

MySQL Supportの特徴
• 「パフォーマンス・チューニング」や「SQLチューニング」まで
通常サポートの範囲内
– コンサルティングサポートが含まれており、「クエリ・レビュー」、「パフォーマンス・
チューニング」、「レプリケーション・レビュー」、「パーティショニング・レビュー」などに
対応可能
– 詳細はこちらを参照下さい
http://www-jp.mysql.com/support/consultative.html
• ソースコードレベルでサポート可能
– ほとんどのサポートエンジニアがソースを読めるため、対応が早い開発エンジニアと
サポートエンジニアも密に連携している

MySQL (NDB) Clusterのモニタリングをサポート
• NDB Clusterを構成するプロセスを自動的に検出
– ndbapi
– ndb_mgmd
– ndbd/ndbmtd
• Visual cluster topology
• レポート情報の新規追加
• アドバイザーの新規追加

ダウンタイムの低下、管理性の向上
MySQL Cluster Manager
管理作業の自動化
• ノード/クラスタ全体の
起動、停止
• オンライスケーリング
• オンライン再構成
• オンラインアップグレード
• オンラインバックアップ＆
リストア
• 既存環境のインポート
自己修復
• ノード監視
• SQLノード、管理ノード、
データノードの自己修復
HA 操作
• クラスタ全体で一貫性の
とれた設定変更
• 永続的な設定変更
• HA エージェント

MySQL Technology Cafe No3

More Related Content

What's hot (20)

Similar to MySQL Technology Cafe No3 (20)

MySQL Technology Cafe No3