Best practices for MySQL High Availability, presented in Tokyo Japan, for dbtechshowcase / dbtechshowcaseOSS - the slides also have some Japanese in it. This should help a Japanese audience to read it. If there are questions due to poor translation, do not hesitate to drop me an email (byte@bytebot.net) or tweet: @bytebot

1. Best practices for MySQL High Availability
(MySQLの⾼高可⽤用性のためのベストプラクティス)
Colin Charles, Chief Evangelist, Percona Inc.
colin.charles@percona.com / byte@bytebot.net
http://www.bytebot.net/blog/ | @bytebot on Twitter
db tech showcase OSS 2017, Tokyo, Japan
17 June 2017 #dbts2017 #dbtsOSS

2. whoami
• Chief Evangelist (in the CTO office), Percona Inc
• Percona Incのチーフエバンジェリスト（CTO事務所内）
• Founding team of MariaDB Server (MariaDB Serverの創業チーム)
(2009-2016), previously at Monty Program Ab, merged with
SkySQL Ab, now MariaDB Corporation
• Formerly MySQL AB (以前のMySQL AB) (exit: Sun Microsystems)
• Past lives include Fedora Project (FESCO), OpenOffice.org
• MySQL Community Contributor of the Year Award winner 2014

3. License
• Creative Commons BY-NC-SA 4.0
• https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode

4. Ecosystem

7. Uptime
Percentile target Max downtime per year
90% 36 days
99% 3.65 days
99.5% 1.83 days
99.9% 8.76 hours
99.99% 52.56 minutes
99.999% 5.25 minutes
99.9999% 31.5 seconds

8. Estimates of levels of availability
Method
Level of
Availability
Simple replication 98-99.9%
Master-Master/MMM 99%
SAN 99.5-99.9%
DRBD, MHA, Tungsten
Replicator
99.9%
NDBCluster, Galera Cluster 99.999%

9. HA is Redundancy
• RAID: disk crashes? Another works
• RAID：ディスクがクラッシュする 別の作品
• Clustering: server crashes? Another works
• クラスタリング：サーバーがクラッシュする 別の作品
• Power: fuse blows? Redundant power supplies
• ⼒力力：ヒューズが吹く？ 冗⻑⾧長電源
• Network: Switch/NIC crashes? 2nd network route
• ネットワーク：スイッチ/ NICがクラッシュしますか？ 第2ネットワークルート
• Geographical: Datacenter offline/destroyed? Computation to another DC
• 地理理的：オフライン/破壊されたデータセンター？ 別のDCへの計算

10. Durability
• Data stored on disks
• ディスクに格納されたデータ
• Is it really written to the disk?
• それは実際にディスクに書き込まれていますか？
• being durable means calling fsync() on each commit
• 耐久性があるということは、コミットごとにfsync（）を呼び出すことを意味
します
• Is it written in a transactional way to guarantee atomicity, crash safety, integrity?
• それは原⼦子性、衝突安全性、完全性を保証するためにトランザクション的な⽅方
法で書かれていますか？

11. High Availability for databases
• HA is harder for databases
• HAはデータベースにとってより難しい
• Hardware resources and data need to be redundant
• ハードウェアのリソースとデータが冗⻑⾧長である必要が
• Remember, this isn’t just data - constantly changing data
• これは単なるデータではなく、常に変化するデータであることを忘れないでください
• HA means the operation can continue uninterrupted, not by restoring a new/backup server
• HAとは、新しい/バックアップサーバーを復復元するのではなく、操作を中断しないで続ける
ことができることを意味します
• uninterrupted: measured in percentiles
• 途切れない：パーセンタイルで測定

12. InnoDB “recovery” time
•innodb_log_file_size
• larger = longer recovery times
• より⼤大きな=⻑⾧長い回復復時間
• Percona Server 5.5 (XtraDB) - innodb_recovery_stats

13. Redundancy through shared storage
• Requires specialist hardware, like a SAN
• SANのような専⾨門ハードウェアが必要
• Complex to operate
• 操作が複雑
• One set of data is your single point of failure
• 1つのデータセットが単⼀一障害点です
• Cold standby (コールドスタンバイ)
• failover 1-30 minutes (フェールオーバー1-30分)
• this isn’t scale-out (これはスケールアウトではありません)

14. Redundancy through disk replication
• DRBD
• Linux administration vs. DBA skills (DBAのスキル対Linuxの管理理)
• Synchronous (シンクロナス)
• Second set of data inaccessible for use
• 使⽤用のためにアクセスできないデータの第⼆二のセット
• Passive server acting as hot standby
• ホットスタンバイとして動作するパッシブサーバー
• Failover: 1-30 minutes (フェールオーバー：1〜30分)
• Performance hit compared to single node performance, with higher average latencies
• 単⼀一ノードのパフォーマンスと⽐比較して平均レイテンシが⾼高いパフォーマンス

15. Redundancy through MySQL replication
• MySQL replication
• Tungsten Replicator
• Galera Cluster
• MySQL Cluster (NDBCLUSTER)
• Storage requirements are multiplied
• ストレージ要件が乗算され、
• Huge potential for scaling out
• スケールアウトのための巨⼤大な潜在

16. MySQL Replication
• Generally statement based (⼀一般的にステートメントベース)
• Row based became available in 5.1, and the default in 5.7
• ⾏行行ベースは5.1で使⽤用可能になり、デフォルトは5.7
• mixed-mode, resulting in STATEMENT except if calling
• 呼び出す場合を除き、声明の中で得られた混合モード、
• UUID function, UDF, CURRENT_USER/USER function, LOAD_FILE function
• 2 or more AUTO_INCREMENT columns updated with same statement
• server variable used in statement
• storage engine doesn’t allow statement based replication, like NDBCLUSTER
• default in MariaDB Server 10.2

17. MySQL Replication II
• Asynchronous by default
• 既定で⾮非同期
• Semi-synchronous plugin in 5.5+
• 半同期プラグイン5.5+
• However the holy grail of fully synchronous replication is not part of standard
MySQL replication
• しかし、完全に同期レプリケーションの聖杯は、標準のMySQLのレプリケー
ションの⼀一部ではありません
• MariaDB Galera Cluster is built-in to MariaDB Server 10.1
• Group replication plugin for MySQL 5.7 / Percona Server 5.7

18. The logs
• Binary log (binlog) - events that describe database changes (データベースの変
更更を記述するイベント)
• Relay log - events read from binlog on master, written by slave i/o thread (スレー
ブI / Oスレッドによって書かれた、マスターのbinlogから読み取られたイベント)
• master_info_log - status/config info for slave’s connection to master (スレーブが
マスターに接続するためのステータス/設定情報)
• relay_log_info_log - status info about execution point in slave’s relay log (スレー
ブの中継ログの実⾏行行ポイントに関するステータス情報)
• All binlogs are crash-safe (すべてのバイナリログはクラッシュセーフです)

19. Semi-synchronous replication
• semi-sync capable slave acknowledges transaction event only after written to relay log & flushed to
disk
• セミシンク可能なスレーブは、ログに書き込まれ、ディスクにフラッシュされた後にのみトラン
ザクションイベントを確認します
• IF timeout? master reverts to async replication; resumes when slaves catch up
• IFタイムアウト？ マスターは⾮非同期レプリケーションに戻ります。 奴隷隸が追いつくと再開する
• e.g. at scale, Facebook runs semi-sync: http://yoshinorimatsunobu.blogspot.com/2014/04/semi-
synchronous-replication-at-facebook.html
• (obviously, Google must too, since the semi-sync patches came from them in the start; and they
contributed enhanced semi-sync to MariaDB Server)
• 明らかに、Googleはあまりにも、半同期パッチ以降開始でそれらから来なければなりません。
そして彼らは、MariaDB Serverに強化された半同期を寄付しました

20. MySQL Replication in 5.6
• Global Transaction ID (GTID)
• Server UUID
• Ignore (master) server IDs (filtering)
• Per-schema multi-threaded slave
• Group commit in the binary log
• Binary log (binlog) checksums
• Crash safe binlog and relay logs
• Time delayed replication
• Parallel replication (per database)

21. Replication: START TRANSACTION WITH
CONSISTENT SNAPSHOT
• Works with the binlog, possible to obtain the binlog position corresponding to a transactional snapshot of the
database without blocking any other queries.
• 他のクエリをブロックすることなく、データベースのトランザクションのスナップショットに対応するバイナリ
ログ位置を得るために、バイナリログで可能働きます。
• by-product of group commit in the binlog to view commit ordering
• コミットの順序を⾒見見るためにbinlog内のグループコミットの副産物
• Make a full non-blocking backup using this command (このコマンドを使⽤用して完全なノンブロッキングバックアッ
プを作成する): mysqldump--single-transaction --master-data
• Works consistently between transactions involving more than one storage engine
• 複数のストレージエンジンを含むトランザクション間で⼀一貫して動作する
• Originally from MariaDB Server, but present in MySQL 5.7 also (もともとMariaDB Serverのものでしたが、MySQL
5.7にも含まれています)
• Percona Server improved it, by session ID, and also introducing backup locks
• Percona Serverは、セッションIDによって、それを改善し、またバックアップのロックを導⼊入します

22. Multi-source replication
• Multi-source replication - (real-time) analytics, shard provisioning, backups, etc.
• マルチソースレプリケーション - （リアルタイム）分析、シャードプロビジョニング、バッ
クアップなど
• @@default_master_connection contains current connection name (used if connection name is
not given)
• 現在の接続名（接続名が与えられていない場合に使⽤用）が含まれてい
• All master/slave commands take a connection name now (like CHANGE MASTER “connection_name”,
SHOW SLAVE “connection_name” STATUS, etc.)
• Remember syntax differences in MySQL 5.7 and MariaDB Server 10.0+
• MySQL 5.7およびMariaDB Server 10.0以降の構⽂文の違いを覚えておいてください

23. Why is MariaDB Server 10.0+ GTID different
compared to MySQL 5.6?
• MySQL 5.6 GTID did not support multi-source replication (only 5.7 supports
this)
• MySQL 5.6 GTIDはマルチソースレプリケーションをサポートしていませ
ん（これは5.7のみサポートしています）
• Supports —log-slave-updates=0 for space efficiency (like 5.7)
• スペース効率のために-log-slave-updates = 0をサポートします（5.7など）
• Turn it on without having to restart the topology (just like 5.7)
• トポロジーを再起動することなくオンにする（5.7と同様）

24. All in… sometimes replication can get out
of sync
• Changed information on slave
directly (スレーブ上の変更更され
た情報を直接)
• Statement based replication
• non-deterministic SQL
(UPDATE/DELETE with LIMIT
and without ORDER BY)
• triggers & stored procedures
• Master in MyISAM, slave in
InnoDB (deadlocks)
• --replication-ignore-db with fully
qualified queries
• Binlog corruption on master
• PURGE BINARY LOGS issued
and not enough files to update
slave
• read_buffer_size larger than
max_allowed_packet
• Bugs?

25. Replication Monitoring
• Percona Toolkit is important (Percona Toolkitは重要です)
• pt-slave-find: find slave information from master (マスターからスレーブ情報を⾒見見つ
ける)
• pt-table-checksum: online replication consistency check (オンラインレプリケー
ションの整合性チェック)
• executes checksum queries on master (マスター上でチェックサムクエリを実⾏行行
する)
• pt-table-sync: synchronise table data efficiently (効率的にテーブルのデータを同期)
• changes live data, so your working backups are important (ライブデータを変更更す
る / 作業中のバックアップは重要です)

26. Replication Monitoring with PMM
•http://pmmdemo.percona.com/

27. mysqlbinlog versions
• ERROR: Error in Log_event::read_log_event(): 'Found invalid event in
binary log', data_len: 56, event_type: 30
• 5.6 ships with a “streaming binlog backup server” - v.3.4; MariaDB
10 doesn’t - v.3.3 (fixed in 10.2 - MDEV-8713)
• 5.6は「ストリーミングバイナリバックアップサーバ」と⼀一緒に出
荷されます - v.3.4; MariaDB 10はそうではありません - v.3.3（10.2
- MDEV-8713で修正されました）
• GTID is different in MySQL and MariaDB Server!
• MySQLとMariaDB ServerではGTIDが異異なります！

28. Slave prefetching
• Replication Booster
• https://github.com/yoshinorim/replication-booster-for-mysql
• Prefetch MySQL relay logs to make the SQL thread faster
• MySQLリレーログをプリフェッチしてSQLスレッドを⾼高速化する
• Tungsten Replicator has slave prefetch
• タングステンレプリケータにはスレーブプリフェッチがあります
• Percona Server till 5.6 + MariaDB till 10.1 have InnoDB fake changes
• Percona Server 5.6 + MariaDBまで10.1までInnoDBの偽の変更更がある

29. What replaces slave prefetching?
• In Percona Server 5.7, slave prefetching has been replaced by doing intra-
schema parallel replication
• Percona Server 5.7では、スレーブのプリフェッチがスキーマ内の並列列レプ
リケーションを⾏行行うことで置き換えられました
• Feature removed from Percona XtraDB storage engine
• Percona XtraDBストレージエンジンから削除された機能
• MariaDB Server 10.2 uses InnoDB so use intra-schema parallel replication too
• MariaDBサーバー10.2はInnoDBがそう余りに内のスキーマのパラレル・レ
プリケーションを使⽤用して使⽤用しています

30. Tungsten Replicator
• Replaces MySQL Replication layer (MySQLレプリケーション層を置き換える)
• MySQL writes binlog, Tungsten reads it and uses its own replication protocol, a
Transaction History Log (THL)
• MySQLはbinlogを書き込み、タングステンはそれを読み取り、独⾃自のレプリケーショ
ンプロトコル、トランザクション履履歴ログ（THL）
• Global Transaction ID
• Per-schema multi-threaded slave
• Heterogeneous replication (異異種複製): MySQL <-> MongoDB <-> PostgreSQL <-> Oracle
• Multi-master replication (マルチマスターレプリケーション)
• Multiple masters to single slave (multi-source replication)
• Many complex topologies

31. In today’s world, what does it offer?
•opensource MySQL <-> Oracle replication to aid in your migration
•あなたの移⾏行行に役⽴立つopensource MySQL < - > Oracleレプリケーション
• automatic failover without MHA
• multi-master with cloud topologies too
•Oracle <-> Oracle replication (this is like Golden Gate for FREE)
•Oracle < - > Oracleレプリケーション（これはゴールデンゲートのようなもので
す）
• Replication from MySQL to MongoDB
• Data loading into Hadoop

32. Galera Cluster
• Inside MySQL, a replication plugin (wsrep)
• MySQLの内部では、レプリケーションプラグイン（wsrep）
• Replaces MySQL replication (but can work alongside it too)
• MySQLのレプリケーションを置き換えます（ただし、それと同時に動作します）
• True multi-master, active-active solution
• 真のマルチマスター、アクティブ - アクティブソリューション
• Virtually Synchronous (事実上同期)
• WAN performance: 100-300ms/commit, works in parallel
• No slave lag or integrity issues (スレーブ遅延や整合性の問題はありません)
• Automatic node provisioning (⾃自動ノードプロビジョニング)

33. 33

34. Percona XtraDB Cluster 5.7
• Engineering within Percona (ペルコナ内の⼯工学)
• Bundled load balancing with ProxySQL
• ProxySQLによるバンドルされたロードバランシング
• Integrated with Percona Monitoring & Management (PMM)
• Percona Monitoring＆Management（PMM）と統合されていま
す。
• Benefits of all the MySQL 5.7 feature-set
• すべてのMySQL 5.7機能セットの利利点

35. Group replication
• Virtually fully synchronous replication (update everywhere), self-healing, with elasticity,
redundancy
• 実質的に完全同期レプリケーション（どこでも更更新）、⾃自⼰己回復復、弾⼒力力性、冗⻑⾧長性
• Single primary mode supported (シングルプライマリモードをサポート)
• MySQL InnoDB Cluster - a combination of group replication, Router, to make magic!
• MySQLのInnoDBクラスタ - グループのレプリケーションの組み合わせ、ルータ、魔
法を作る！
• Relevant blogs:
• https://www.percona.com/blog/2017/02/24/battle-for-synchronous-replication-in-
mysql-galera-vs-group-replication/
• https://www.percona.com/blog/2017/02/15/group-replication-shipped-early/

36. Summary of Replication Performance
• SAN has "some" latency overhead compared to local disk. Can be great for throughput.
• SANは、ローカルディスクと⽐比較して、ある程度の待ち時間オーバーヘッドを持っています。 スループットに優れ
ています。
• DRBD has a performance penalty (DRBDにはパフォーマンス上のペナルティがあります)
• Replication, when implemented correctly, has no performance penalty
• 複製が正しく実装された場合、パフォーマンス上のペナルティはありません
• But MySQL replication with disk bound data set has single-threaded issues!
• しかし、ディスクにバインドされたデータセットを使⽤用したMySQLレプリケーションでは、シングルスレッドの
問題があります。
• Semi-sync is poorer on WAN compared to async
• セミ同期は⾮非同期に⽐比べてWAN上で劣っています
• Galera & group replication (plus MySQL NDBCLUSTER) provide read/write scale-out, thus more performance
• Galeraとグループの複製（MySQL NDBCLUSTERを含む）は、読み取り/書き込みのスケールアウトを提供します。

37. Handling failure
• How do we find out about failure? (失敗についてどうやって⾒見見つけますか？)
• Polling, monitoring, alerts… (ポーリング、監視、アラート…)
• Error returned to and handled in client side
• What should we do about it? (それについて何をすべきですか？)
• Direct requests to the spare nodes (or DCs)
• How to protect data integrity? (データの整合性を保護する⽅方法)
• Master-slave is unidirectional: Must ensure there is only one master at all times.
• DRBD and SAN have cold-standby: Must mount disks and start mysqld.
• In all cases must ensure that 2 disconnected replicas cannot both commit independently. (split
brain)
• すべてのケースで、2つの切断されたレプリカを両⽅方とも独⽴立してコミットできないようにする必
要があります。 （スプリットブレイン）

38. Frameworks to handle failure
• MySQL-MMM
• Severalnines ClusterControl
• Orchestrator
• MySQL MHA
• Percona Replication Manager
• Tungsten Replicator
• 5.6: mysqlfailover, mysqlrpladmin
• Replication Manager

39. Orchestrator
• Reads replication topologies, keeps state, continuous polling
• レプリケーショントポロジの読み取り、状態の保持、継続的な
ポーリング
• Modify your topology — move slaves around (トポロジを変更更する
- スレーブを移動する)
• Nice GUI, JSON API, CLI

40. MySQL MHA
• Developed by Yoshinori Matsunobu at DeNA
• Automated and manual failover options
• ⾃自動および⼿手動フェールオーバーオプション
• Topology: 1 master, many slaves (トポロジ：1マスター、多くのス
レーブ)
• Choose new master by comparing slave binlog positions
• スレーブbinlogの位置を⽐比較して新しいマスターを選択する
• http://code.google.com/p/mysql-master-ha/

41. Load Balancers for multi-master clusters
• Synchronous multi-master clusters like Galera require load
balancers
• Galeraなどの同期マルチマスタークラスタにはロードバランサが
必要です
• HAProxy
• Galera Load Balancer (GLB)
• MaxScale
• ProxySQL

42. MySQL Router
• Routing between applications and any backend MySQL servers
• アプリケーションと任意のバックエンドMySQLサーバ間のルー
ティング
• Failover (フェールオーバー)
• Load Balancing (ロードバランシング)
• Pluggable architecture (connection routing) (プラガブルアーキテク
チャ（接続ルーティング）)
• GPL license (GPLライセンス)

43. MariaDB MaxScale
• “Pluggable router” that offers connection & statement based load balancing
• 接続とステートメントに基づくロードバランシングを提供する「プラガブルルータ」
• Use it for logging, writing to other databases (besides MySQL), preventing SQL
injections via regex filtering, route via hints, query rewriting, have a binlog relay, etc.
• ロギング、他のデータベースへの書き込み（MySQL以外）、正規表現によるフィル
タリングによるSQLインジェクションの防⽌止、ヒント経由のルーティング、クエリの
再書き込み、バイナリログのリレーなどがあります。
• Load balance your Galera clusters (Galeraクラスタの負荷分散)
• Business Source License (so not actually OSI-certified open source)
• ビジネスソースライセンス（実際にはOSI認定のオープンソースではない）

44. ProxySQL
• High Performance MySQL proxy with a GPL license
• GPLライセンス付きの⾼高性能MySQLプロキシ
• Performance is a priority - the benchmarks prove it
• パフォーマンスは優先事項であり、ベンチマークはそれを証明します
• Can query rewrite (クエリー・リライト)
• Sharding by host/schema or both, with rule engine + modification to SQL
+ application logic
• ホスト/スキーマまたは両⽅方によるシャーディング、ルールエンジン+
SQL +アプリケーションロジックの変更更

45. JDBC/PHP drivers
• JDBC - multi-host failover feature (just specify master/slave hosts in the
properties)
• JDBC - マルチホスト・フェイルオーバー機能（プロパティーにマスター/ス
レーブ・ホストを指定するだけ）
• true for MariaDB Java Connector too
• MariaDB Java Connectorにも当てはまります
• PHP handles this - mysqlnd_ms (PHPがこれを処理理する - mysqlnd_ms)
• Can handle read-write splitting, round robin or random host selection, and more
• 読み書き分割、ラウンドロビンまたはランダムホスト選択などを処理理できます

46. Clustering: solution or part of problem?
• "Causes of Downtime in Production MySQL Servers" whitepaper, Baron Schwartz
VividCortex
• Human error (ヒューマンエラー)
• SAN
• Clustering framework + SAN = more problems
• クラスタリングフレームワーク+ SAN =その他の問題
• Galera is replication based, has no false positives as there’s no “failover” moment, you don’t
need a clustering framework (JDBC or PHP can load balance), and is relatively elegant
overall
• Galeraはレプリケーションベースであり、フェイルオーバの瞬間がなく、クラスタリング
フレームワーク（JDBCまたはPHPのロードバランスが不不要）が不不要であり、全体的に⽐比
較的エレガントです

47. SBR vs RBR? Async vs sync?
• row based: deterministic (⾏行行ベース：決定論的)
• statement based: dangerous (ステートメントベース：危険)
• GTID: easier setup & failover of complex topologies (GTID：複雑なト
ポロジのセットアップとフェイルオーバーが容易易)
• async: data loss in failover (async：フェイルオーバー時のデータ損
失)
• sync: best (同期：最⾼高)
• semi-sync: best compromise! (半同期：最良の妥協点！)

48. Conclusion
• MySQL replication is amazing if you know it (and monitor it) well enough
• あなたはそれを知っている（と、それを監視する）場合は、MySQLのレプリケー
ションは⼗十分素晴らしいです
• Large sites run just fine with semi-sync + tooling for automated failover
• ⼤大規模サイトは⾃自動フェイルオーバー⽤用のセミシンク+ツーリングでうまく動作しま
す
• Galera Cluster is great for virtually synchronous replication
• ガレラクラスタは、事実上、同期レプリケーションに最適です
• Don’t forget the need for a load balancer: ProxySQL is the best choice today
• ロードバランサの必要性を忘れないでください：今⽇日、ProxySQLが最良の選択です

49. At Percona, we care about your High
Availability
• Percona XtraDB Cluster 5.7 with support for ProxySQL and
Percona Monitoring & Management (PMM)
• Percona Monitoring & Management (PMM) with Orchestrator
• Percona Toolkit
• Percona Server for MySQL 5.7
• Percona XtraBackup

50. © 2017 Percona50
Percona Live Europe Call for Papers &
Registration are Open!
Championing Open Source Databases
▪MySQL, MongoDB, Open Source Databases
▪Time Series Databases, PostgreSQL, RocksDB
▪Developers, Business/Case Studies, Operations
▪September 25-27th, 2017
▪Radisson Blu Royal Hotel, Dublin, Ireland
Submit Your Proposal by July 17th!
www.percona.com/live/e17

51. Q&A / Thanks
Q＆A /ありがとう
colin.charles@percona.com / byte@bytebot.net
@bytebot on Twitter | http://bytebot.net/blog/
slides: slideshare.net/bytebot
51