MySQL 5.7 InnoDB Cluster (Jan 2018)

MySQL InnoDB Cluster
Olivier Dasini
MySQL Principal Solutions Architect EMEA
olivier.dasini@oracle.com
@freshdaz
Copyright 2017, Oracle and/or its affiliates. All rights reserved
A complete High Availability solution for MySQL

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Me, Myself & I
➢ MySQL Geek
✔ Addicted to MySQL for 15+ years!
✔ Playing with databases for 20+ years
➢ MySQL Writer, Blogger and Speaker
✔ Also former : DBA, Consultant, Architect, Trainer, ...
➢ MySQL Principal Solutions Architect EMEA at Oracle
➢ Stay tuned! :
✔ @freshdaz
✔ http://dasini.net/blog
3
Olivier DASINI

Copyright © 2017 Oracle and/or its affiliates. All rights reserved. |
Program Agenda
1
2
3
4
High Availability
Architectures and Best Practices
Demo : Deploying MySQL InnoDB Cluster
4

The world's most popular open source database

1. Google
2. Facebook
3. YouTube
4. Baidu
5. Yahoo!
6. Amazon
7. Wikipedia
8. QQ
9. Google.co.in
10. Twitter
11. Live.com
12. Taobao
13. Msn.com
14. Yahoo.co.jp
15. Sina
16. Linkedin.com
17. Google.co.jp
18. Weibo
19. Bing.com
20. Yandaz.ru
Global Top 20 Sites: Powered by MySQL
Source: Wikipedia 2016 6
Powers the Web

They Scale
with MySQL
Mobile Network Supporting
Over 800 Million
Subscribers
2+ Billion Active Users
100 TB of User Data for PayPal
IDs Processed for
1 Billion Citizens
850 Million Candy Crush Game
Plays/Day
2 Billion Events/Day for Booking.com
7

Powers Social

Powers eCommerce

Powers SaaS

Powers FinTech
11

Powers Unicorns

High Availability: Factors
• Environment
– Redundant servers in different datacenters and geographical areas will protect you against regional
issues—power grid failures, hurricanes, earthquakes, etc.
• Hardware
– Each part of your hardware stack—networking, storage, servers—should be redundant
• Software
– Every layer of the software stack needs to be duplicated and distributed across separate hardware and
environments
• Data
– Data loss and inconsistency/corruption must be prevented by having multiple copies of each piece of
data, with consistency checks and guarantees for each change
15

High Availability: The Causes of Downtime
16
40,00 %
40,00 %
20,00 %
Software/Application Human Error Hardware
* Source: Gartner Group 1998 survey
A study by the Gartner Group
projected that through 2015, 80% of
downtime will be due to people and
process issues

High Availability: The Business Cost of Downtime
• Calculate a cost per minute of downtime
– Average revenue generated per-minute over a year
– Cost of not meeting any customer SLAs
– Factor in costs that are harder to quantify
1. Revenue
2. Reputation
3. Customer sentiment
4. Stock price
5. Service’s success
6. Company’s very existence
17
THIS is why HA
matters!

Multiple copies of data with replication process

HA solutions with MySQL : Replication modes
• Asynchronous => MySQL Replication
— MySQL Default; In parallel: Master acks to app and sends transaction to slave
— Fast; Risk of lost changes if master dies
• Semi-Synchronous => MySQL Replication w/ semisynchronous plugin
— MySQL 5.5+ Enhanced in MySQL 5.7; Serially: Master waits for change to be received by slave then In parallel ack to app and apply changes on slave
— Intermediate latency; Lossless (MySQL 5.7)
• Virtual-Synchronous => MySQL InnoDB Cluster w/ MySQL Group Replication
— MySQL Group Replication; Multi-masters updates on nodes applied in parallel
— MySQL Plugin delivered by MySQL for MySQL :)
— Intermediate latency; Best suited to small transactions; Lossless
• Synchronous => MySQL NDB Cluster
— Only available with MySQL Cluster; Serially: Master waits for change to be applied on all slaves before ack to app
— Higher latency; If Active/Active, best suited to small transactions; Lossless

MySQL Database Replication: Some Notes
Coordination Between Servers

This talk is not about...

Replication
23
Off topicOff topic

Use MySQL Replication For HA
27
Redundancy: If master crashes, promote slave to master
B
C
CrashCrash
B is the
new master
Ouch!!! Whew!
https://dev.mysql.com/downloads/utilities/
B
C
A
C
B
Slave promotion managed by mysqlrpladmin or mysqlfailover

NDB Cluster
29
Off topicOff topic

• MySQL NDB Cluster
–In memory distributed database
–NDB storage engine
–Automatic sharding
–Native access via several API
–Read/write consistency
–Read/write scalability
–Management via MCM/mgm-tool
MySQL NDB Cluster
Rock Solid
Availability
In-Memory
Real-Time
Performance
Extreme
Read & Write
Scalability
Elasticity

Program Agenda
1
2
3
4
High Availability
33

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 34
Collection of products that work together to provide a complete High Availability solution for MySQL

InnoDB Cluster
35
App Servers with
MySQL Router
MySQL Group Replication
“High Availability becomes a core
first class feature of MySQL!”
MySQL Shell
Setup, Manage,
Orchestrate

A single product: MySQL
• All components created together
• Tested together
• Packaged together
Flexible and Modern
• C++ 11
• Protocol Buffers
• Developer friendly
MySQL InnoDB Cluster – Goals
Easy to use
• A single client: MySQL Shell
• Easy packaging
• Homogenous servers
Scale-out
• Sharded clusters
• Federated system of N replica sets
• Each replica set manages a shard

MySQL InnoDB Cluster: The Big Picture
P
App
S S
MySQL Shell and Orchestration Tooling
App
Simple Mapping,
State and Extra Metadata
Control, Coordinate,
Provision
Monitoring (MEM)
MySQL Router
MySQL Router

Native, built-in High Availability for your MySQL databases
38

Group Replication
39
App Servers with
MySQL Router
MySQL Shell
Setup, Manage,
Orchestrate

MySQL Group Replication: What Is It?
• Group Replication library
– Implementation of Replicated Database State Machine theory
• MySQL GCS is based on Paxos (variant of Mencius)
– Provides virtually synchronous replication for MySQL 5.7+
– Supported on all MySQL platforms
• Linux, Windows, Solaris, OSX, FreeBSD
“Single/Multi-master update everywhere replication plugin for MySQL with built-in automatic
distributed recovery, conflict detection and group membership.”
41
http://dasini.net/blog/2016/11/08/deployer-un-cluster-mysql-group-replication/

• A Highly Available distributed MySQL database service
– Clustering eliminates single points of failure (No SPOF)
• Allows for online maintenance
– Removes the need for handling server fail-over
– Provides fault tolerance
– Enables update everywhere setups
– Automates group reconfiguration (handling of crashes, failures, re-connects)
– Provides a highly available replicated database
– Automatically ensures data consistency ie no data loss
• Detects and handles conflicts
• Prevents data loss
• Prevents data corruption
42
MySQL Group Replication: What Does It Provide?

MySQL Group Replication: Use Cases
• Elastic Replication
– Environments that require a very fluid replication infrastructure, where the
number of servers has to grow or shrink dynamically and with little pain as possible.
• Highly Available Shards
– Sharding is a popular approach to achieve write scale-out. Users can use MySQL
Group Replication to implement highly available shards in a federated system.
Each shard can map into a Replication Group.
• Alternative to Master-Slave Replication
– Single-primary mode provides further automation on such setups
● Automatic PRIMARY/SECONDARY roles assignment
● Automatic new PRIMARY election on PRIMARY failures
● Automatic setup of read/write modes on PRIMARY and SECONDARIES
● Global consistent view of which server is the PRIMARY
43

MySQL Group Replication: What Sets It Apart?
• Built by the MySQL Engineering Team
– Natively integrated into Server: InnoDB, Replication, GTIDs, Performance Schema, SYS
– Built-in, no need for separate downloads
– Available on all platforms [Linux, Windows, Solaris, FreeBSD, etc]
• Better performance than similar offerings
– MySQL GCS has optimized network protocol that reduces the impact on latency
• Easier monitoring
– Simple Performance Schema tables for group and node status/stats
– Native support for Group Replication in MySQL Enterprise Monitor
• Modern full stack MySQL HA being built around it
44

MySQL Group Replication: Architecture
Node Types
R: Traffic routers/proxies: mysqlrouter, ProxySQL, HAProxy...
M: mysqld nodes participating in Group Replication
45

MySQL Group Replication: Performance
46

MySQL Group Replication: Performance Comparison
47

Full stack secure connections
• Following the industry standards, Group Replication supports secure connections along the
complete stack
– Client connections
– Distributed recovery connections
– Connections between members
• IP Whitelisting
– Restrict which hosts are allowed to connect to the group
– By default it is set to the values AUTOMATIC, which allow connections from private subnetworks active
on the host
48
http://mysqlhighavailability.com/mysql-group-replication-securing-the-perimeter/

Prioritize member for the Primary Member Election
• group_replication_member_weight
– allows users to influence primary member election
– takes integer value between 0 and 100
– default value = 50
• The first primary member is still the member which bootstrapped the group irrespective of
group_replication_member_weight value.
49
http://mysqlhighavailability.com/group-replication-prioritise-member-for-the-primary-member-election/
node1> SET GLOBAL group_replication_member_weight= 90;

Parallel applier support
• Group Replication now also takes full advantage of parallel binary log applier infrastructure
– Reduces applier lad and improves replication performance considerably
– Configured in the sale way as asynchronous replication
50
slave_parallel_workers=<NUMBER>
slave_parallel_type=logical_clock
slave_preserve_commit_order=ON
slave_parallel_workers=<NUMBER>
slave_parallel_type=logical_clock
slave_preserve_commit_order=ON

Single Primary Mode
• Configuration mode that makes a single member act as a writeable master (PRIMARY) and the rest of the members
act as hot-standbys (SECONDARIES)
– The group itself coordinates automatically to figure out which is the member that will act as the PRIMARY, through an
automatic primary election mechanism
– Secondaries are automatically set to read-only
• Single_primary mode is the default mode
– Closer to classic asynchronous replication setups, simpler to reason about the beginning
– Avoids some limitations of multi-primary mode by default
• The current PRIMARY member UUID can be know by executing the following SQL statement:
51
mysql> SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME='group_replication_primary_member'G
*************************** 1. row ***************************
VARIABLE_NAME: group_replication_primary_member
VARIABLE_VALUE: dcd3b36b-79c5-11e6-97b8-00212844d44e
mysql> SELECT * FROM performance_schema.global_status WHERE VARIABLE_NAME='group_replication_primary_member'G
*************************** 1. row ***************************
VARIABLE_NAME: group_replication_primary_member
VARIABLE_VALUE: dcd3b36b-79c5-11e6-97b8-00212844d44e

Multi-primary Mode
• Configuration mode that makes all members writeable
– Enabled by setting option --group_replication_single_primary_mode to OFF
• Any two transactions on different servers can write to the same tuple
• Conflicts will be detected and dealt with
– First committer wins rule
52

• Execute locally
– Group Replication starts replicating a transaction when it is ready to commit, just before being written to the binary log
• Send in-order to all members
– At that point, transactions are broadcast to the network using a group communication protocol (Paxos, similar to the
Mencius variant)
• Certify independently
– All members receive the transactions in order and execute a deterministic certification algorithms to check if the received
transaction can be applied safely
• Apply asynchronously
– On remote members successfully certified transactions are written to the relay log and asynchronously applied by the
members, just as happens for other replication methods.
– On local member, the prepared transactions is committed to the storage engine.
53
Transaction life cycle

Transaction life cycle
54

Synchronous Transaction Delivery
55

Full Transaction life cycle
56

Traditional vs Optimistic locking
57
Traditional locking Optimistic locking
Trx 2 waits
on Trx 1 commit
ERROR 1180 (HY000): Got error 149 during COMMIT

• Optimize the system as a whole
– Sometimes it is beneficial to delay some parts of a distributed system it to improve the throughput of the system as a whole
– In MySQL Group Replication, it is used to
● keep writers operating below the sustained capacity of the system;
● reduce buffering stress on the replication pipeline;
● protect the correct execution of the system.
• Designed as a safety measure
– Throttling will never be active while the system is operating below its sustained capacity.
• To better support unbalanced systems and unfriedly workloads
– Keep members closer for faster failover
– Keep members closer for reduced replication lag
– Reduce the number of transactions aborts in multi-master
• Make sure new members can always join write-intensive groups
– Nodes entering the group need to catch up previous work while also storing current work to apply later
– In case excess capacity is not available, the cluster will need to be put at lower throughput for new members to catch up
60
Flow Control

• MySQL 5.7 - Basic configuration options
– group-replicaton-fow-control-mode = QUOTA | DISABLED
– group-replicaton-fow-control-certfer-threshold = 0..n
– group-replicaton-fow-control-applier-threshold = 0..n
• Certifier/applier thresholds
– The thresholds are the point at which the flow-control system will delay the writes at the master
– The default is set to 25000 and should be kept larger then one second of sustained commit rate
– But some members will be up to 25000 transactions delayed, if, and only if, they are unable to keep up with the writer members
• MySQL 8.0.3 introduce additional options to fine-tune the heuristics
– group_replicaton_fow_control_min_quota = X commits/s
– group_replicaton_fow_control_min_recovery_quota = X commits/s
– group_replicaton_fow_control_max_commit_quota = X commits/s
– group_replicaton_fow_control_member_quota_percent = Y %
– group_replicaton_fow_control_period = Z seconds
– group_replicaton_fow_control_hold_percent = Y %
– group_replicaton_fow_control_release_percent = Y %
61
Flow Control options

MySQL Group Replication: Requirement
•InnoDB Storage Engine
– Data must be stored in the InnoDB transactional storage engine.
•Primary Keys
– Every table that is to be replicated by the group must have an explicit primary key
defined.
•IPv4 Network
– The group communication engine used by MySQL Group Replication only supports
IPv4.
•Network Performance
– Group Replication is designed to be deployed in a cluster environment where server
instances are very close to each other, and is impacted by both network latency as
well as network bandwidth.
62

Storage Engine InnoDB
Distributed Architecture Shared nothing
Network failure protection Quorum
NoSQL APIs MySQL Document Store / InnoDB Memcached
Replication mode Virtually Synchronous
Database Failover Automatic
OS Supported Linux, Windows, Solaris, OSX, FreeBSD
Operational Complexity Medium
Administration Standard (MySQL)
MySQL Group Replication overview

App Servers with
MySQL Router
MySQL Shell
Setup, Manage,
Orchestrate
Router 2.1

MySQL Router 2.1
• MySQL Router is lightweight middleware that provides transparent routing
between your application and back-end MySQL Servers.
• MySQL Router also provides High Availability and Scalability by effectively
routing database traffic to appropriate back-end MySQL Servers.
• The pluggable architecture also enables developers to extend MySQL Router
for custom use cases.
66

MySQL Router 2.1
• Native support for MySQL InnoDB clusters
– Understands Group Replication topology
– Utilizes metadata schema stored on each member
• Bootstraps itself and sets up client routing for the GR cluster
• Allows for intelligent client routing into the GR cluster
• Supports multi-master and single primary modes
• Core improvements
– Logging
– Monitoring
– Performance
– Security
67

Shell
App Servers with
MySQL Router
MySQL Shell
Setup, Manage,
Orchestrate

MySQL Shell
69
A single unified client for all administrative and operations tasks
• Advanced command-line client and code editor for the MySQL Server
– Supports development & administration for the MySQL Server
– Can be used to perform data queries/update & administration operations
• Interactive multi-language: JavaScript, Python, and SQL
– Naturally scriptable (with development & administrative APIs)
– Both interactive and batch operations
• Supports both Document (CRUD) and Relational models (SQL)
– Modern fluent API for the MySQL Document Store
– Supports the traditional Table results, as well as JSON or Tab separated output
• Exposes full Development and Admin API

MySQL Shell: Admin API
• Creation and Management of InnoDB Clusters
– Hide the complexity of Configuration, Provisioning, Orchestration
– mysql-js> dba.help()
• The global variable 'dba' is used to access the MySQL
AdminAPI
• Perform DBA operations
– Manage MySQL InnoDB clusters
• Create clusters
• Get cluster info
• Start/Stop MySQL Instances
• Validate MySQL instances
• …
Database Administration Interface
App Servers with
MySQL Router
MySQL Shell
Setup, Manage,
Orchestrate
70

InnoDB Cluster
71
App Servers with
MySQL Router
MySQL Shell
Setup, Manage,
Orchestrate

Program Agenda
1
2
3
4
High Availability
72

Hardware and Infrastructure Notes
• 3, 5, or 7 machines per group
– Isolate machine resources as much as possible
– Limit virtualization layers
– Machines configured for dedicated database server role
• Recommended configuration
– 32-64 vCPUs with fast CPU clock (2.5GHz+)
– SSDs (for data and replication logs)
– High quality network connection between each machine
• Low latency, high throughput, reliable
• Limit routers and hubs as much as possible
• Isolated and dedicated network when possible
74

Shared Nothing Cluster – Single Data Center
75
Application Servers
MySQL Router in Stack
MySQL Database Service
Group Replication

Shared Nothing Cluster Active / Passive – Cross Data Center
76
Group Replication
Active Data Center Backup Data Center
Clients

Shared Nothing Cluster – Cross Data Center
77
Group Replication
Data Center 1 Data Center 2
Clients

Geographically Redundant Cluster
78
Async Replication
Active Data Center Backup Data Center
Clients

Fail-soft mode
79
Async Replication
Active Data Center Data Center 2
Clients

Active/Active Multi-Data Center Setup
80
Async Replication
Regional Data Center Regional Data Center
Regional ClientsRegional Clients

Program Agenda
1
2
3
4
High Availability
81

in Single-Primary Mode
82

MySQL InnoDB Cluster: Architecture

Testing MySQL InnoDB Cluster in a sandbox – Demo 1/6
http://dasini.net/blog/2017/03/13/tester-mysql-innodb-cluster/
1/ Connect to MySQL Shell
$ mysqlsh
2/ Deploy 3 local MySQL instances on ports : 3310 - 3320 - 3330
mysql-js> dba.deploySandboxInstance(3310)
• Deploying local sandbox MySQL Instances
Now we have 3 MySQL server instances
running on ports 3310, 3320 and 3330.

Stop
mysql-js> dba.stopSandboxInstance(3310);
Start
mysql-js> dba.startSandboxInstance(3320);
Kill : simulate an unexpected halt while testing failover
mysql-js> dba.killSandboxInstance(3330);
Delete : Completely removes the sandbox instance from your file system
mysql-js> dba.deleteSandboxInstance(3330);
• Managing local sandbox MySQL Instances
Once a sandbox instance is running, it is possible to change its status at any time :

Check instance configuration before the deployment
mysql-js> dba.checkInstanceConfiguration('root@localhost:3310')
• Checking the configuration
Configuration issues could be fixed manually or with configureLocalInstance
e.g.
mysql-js> dba.configureLocalInstance('root@localhost:3310')

1/ Connect to instance 3310
mysql-js> c root@localhost:3310
2/ Create the cluster
mysql-js> var cluster=dba.createCluster('demoCluster');
3/ Check the transaction set and add node 3320 to the cluster
mysql-js> cluster.checkInstanceState('root@localhost:3320')
mysql-js> cluster.addInstance('root@localhost:3320')
4/ Check the transaction set and add node 3330 to the cluster
mysql-js> cluster.checkInstanceState('root@localhost:3330')
mysql-js> cluster.addInstance('root@localhost:3330')
5/ Check cluster status
mysql-js> cluster.status()
• Deploying the InnoDB Cluster

# Bootstrap MySQL Router
$ mysqlrouter --bootstrap root@localhost:3310 --directory /demoSandbox
# Start MySQL router
$ /demoSandbox/start.sh
• Deploying the Router
The following connection information can be used to connect to the cluster.
Classic MySQL protocol connections to cluster 'demoCluster':
- Read/Write Connections: localhost : 6446
- Read/Only Connections: localhost : 6447
X protocol connections to cluster 'demoCluster':
- Read/Write Connections: localhost : 64460
- Read/Only Connections: localhost : 64470

1/ Connect to MySQL Router (default port = 6446)
$ mysqlsh --uri=root@localhost:64466446
2/ Select primary node’s port
mysql-js> sql
mysql-sql>
SELECT @@port; -- display 3310
3/ Primary node crash!
mysql-sql> js
mysql-js>
dba.killSandboxInstance(3310)
• Failover
4/ Select primary node’s port
mysql-js> c root@localhost:6446
mysql-sql>
SELECT @@port; -- display 3320
5/ Member is back to the group
mysql-sql> js
mysql-js> dba.startSandboxInstance(3310)
var cluster =
dba.getCluster('demoCluster')
mysql-js>
cluster.rejoinInstance('root@localhost:3310')
mysql-js> cluster.status()

103
Administration - Monitoring

MySQL Enterprise Monitor 4.0
• Native holistic support for Group Replication clusters
– Intelligent monitoring and alerting
– Topology views
– Detailed metrics and graphs
– Best Practice advice
• Monitoring of MySQL Group Replication
104

MySQL Enterprise Monitor
105
• Group Replication with 3 online nodes
• Group Replication with 3 nodes :
– 2 online
– 1 unreachable

106
• Asynchronous replication between
– Group Replication cluster : master
– Standalone instances : slaves

107
• Asynchronous replication between
– Group Replication cluster 1 : master
– Group Replication cluster 2 : slave

Monitoring: replication_group_member_stats
• Useful to understand :
– how the applier queue is growing
– how many conflicts have been found
– how many transactions were checked
– which transactions are committed everywhere
● Important for monitoring the performance of the members connected in the group
node1> SELECT * FROM performance_schema.replication_group_member_statsG
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 14845735801161197:3
MEMBER_ID: 00014001-1111-1111-1111-111111111111
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 0
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 4e0f05b7-d9d0-11e6-87cf-002710cccc64:1-2
LAST_CONFLICT_FREE_TRANSACTION:
108

Monitoring: replication_group_members 1/2
• Used for monitoring the status of the different server instances that are tracked in the current view
node1> SELECT * FROM performance_schema.replication_group_membersG
*************************** 1. row ***************************
MEMBER_ID: 00014001-1111-1111-1111-111111111111
MEMBER_HOST: localhost
MEMBER_PORT: 14001
MEMBER_STATE: ONLINE
*************************** 2. row ***************************
MEMBER_ID: 00014002-2222-2222-2222-222222222222
MEMBER_PORT: 14002
*************************** 2. row ***************************
MEMBER_ID: 00014003-3333-3333-3333-333333333333
MEMBER_PORT: 14003
109

Monitoring: replication_group_members 2/2
• replication_group_members table is updated whenever there is a view change
• There are various states that a server instance can be in
• If servers are communicating properly, all report the same states for all servers
• If there is a network partition, or a server leaves the group, then different information may be reported,
depending on which server is queried
110
Field Description Group Synchronized
ONLINE
The member is ready to serve as a fully functional group member, meaning that the client can connect and
start executing transactions Yes
RECOVERING
The member is in the process of becoming an active member of the group and is currently going through
the recovery process, receiving state information from a donor No
OFFLINE The plugin is loaded but the member does not belong to any group No
ERROR
The state of the local node. Whenever there is an error on the recovery phase or while applying changes,
the server enters this state No
UNREACHABLE
Whenever the local failure detector suspects that a given server is not reachable, because maybe it has
crashed or was disconnected involuntarily, it shows that server's state as 'unreachable' No

Monitoring: replication_connection_status
• Show information regarding Group Replication :
– transactions that have been received from the group and queued in the applier queue (the relay log)
– Recovery
node1> SELECT * FROM performance_schema.replication_connection_statusG
*************************** 1. row ***************************
GROUP_NAME: 4e0f05b7-d9d0-11e6-87cf-002710cccc64
SOURCE_UUID: 4e0f05b7-d9d0-11e6-87cf-002710cccc64
THREAD_ID: NULL
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 0
LAST_HEARTBEAT_TIMESTAMP: 0000-00-00 00:00:00
RECEIVED_TRANSACTION_SET: 4e0f05b7-d9d0-11e6-87cf-002710cccc64:1-2
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00
111

Monitoring: replication_applier_status
• The state of the Group Replication related channels and thread
• If there are many different worker threads applying transactions then the worker tables can
also be used to monitor what each worker thread is doing
node1> SELECT * FROM
performance_schema.replication_applier_statusG
*************************** 1. row ***************************
SERVICE_STATE: ON
REMAINING_DELAY: NULL
COUNT_TRANSACTIONS_RETRIES: 0
112

Links
• Tutoriel – Configurer ProxySQL 1.4 pour MySQL 5.7 Group Replication
– http://dasini.net/blog/2018/01/09/configurer-proxysql-1-4-pour-mysql-5-7-group-replication/
• Tutoriel – Déployer MySQL InnoDB Cluster
– http://dasini.net/blog/2017/05/11/tutoriel-deployer-mysql-innodb-cluster/
• MySQL InnoDB Cluster Documentation
– https://dev.mysql.com/doc/refman/5.7/en/mysql-innodb-cluster-userguide.html
• Tester MySQL InnoDB Cluster
– http://dasini.net/blog/2017/03/13/tester-mysql-innodb-cluster/
• Adopte un… cluster MySQL Group Replication
– http://dasini.net/blog/2017/04/10/adopte-un-cluster-mysql-group-replication/
• MySQL Group Replication Documentation
– https://dev.mysql.com/doc/refman/5.7/en/group-replication.html
• Déployer un cluster MySQL Group Replication
– http://dasini.net/blog/2016/11/08/deployer-un-cluster-mysql-group-replication/
115

Thank you!

MySQL 5.7 InnoDB Cluster (Jan 2018)

MySQL 5.7 InnoDB Cluster (Jan 2018)

More Related Content

What's hot (20)

Similar to MySQL 5.7 InnoDB Cluster (Jan 2018) (20)

More from Olivier DASINI (20)

Recently uploaded (20)

MySQL 5.7 InnoDB Cluster (Jan 2018)