fossasia 2015: mysql group replication

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | FOSSASIA 2015 | Singapore, 14 th March, 2015. | 1

MySQL Group Replication

Shivji Jha ([email protected])

Software Developer, MySQL Replication Team

2015

mailto:[email protected]

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.



Program Agenda

MySQL Group Replication Background

Zoom in: Major Building Blocks

Zoom in: The Complete Stack

Considerations

Summary

1

2

3

4

5


Program Agenda




Considerations

Summary

1

2

3

4

5

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | FOSSASIA 2015 | Singapore, 14 th March, 2015. |

MySQL Replication

MySQL Master server— Changes data.— Sends changes to Slave.

MySQL Slave server— Receives changes from master.— Applies received changes to database.

MASTER SLAVE


MySQL (Asynchronous) Replication

Native MySQL Replication: Asynchronous— Master executes transaction (T1), commits, ACKs to app, sends to slave.

Fast. Changes might be lost if master dies.

Master

Slave


MySQL Semi-synchronous Replication

Master

Slave

MySQL-5.5 introduced semi-synchronous replication as a plugin.— Extra synchronization step between master and slave.

Point of synchronization configurable on time axis.— Master executes, (slave receives, master commits), master ACKs to app.

Slower: Master waits for slave. Less risk for lost updates.



Recently: Labs preview of Group Replication based on MySQL-5.7— Multi-master update everywhere replication protocol.— A set of servers that interact via message passing.— (Virtually) synchronous architecture.

Master

Master

Master

9Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | FOSSASIA 2015 | Singapore, 14 th March, 2015. |


What is MySQL Group Replication ?

“Multi-master update everywhere replication plugin for MySQLwith built-in automatic distributed recovery, conflict detectionand group membership.”

What does the MySQL Group Replication plugin do for the user?— Enables update everywhere setup.— Provides fault tolerance.

Servers can leave (voluntary or involuntary) and join at any time. The group self adjusts without any human intervention.

— Automates group reconfiguration (handling of crashes, failures, re-connects).— Implements a replicated Database State Machine.


M M M M M

Write Clients

MySQL ReplicationEnvironment



M M M M M

Update ...

Application issues an update.

Group-Based Replication Plugin


M M M M M

ReplicationEvents


Master executes and multi/broadcasts the update to the other servers.



M M M M M



Servers receive same transaction in the same order and check for conflicts.



M M M M M




All servers, independently, decide to commit the transaction – no conflicts.






All servers, independently, decide to commit the transaction – no conflicts.

Originating master replies to the application.

M M M M M



MySQL Group Replication is...… built on top of proven technology!

— Shares a lot of MySQL Replication infrastructure.— Multi-Master approach to replication.

… very interesting, architecturally speaking!— The plugin registers as listener to server events.— Decoupled from the server core.— Provides further decoupling from the communication infrastructure.

… built on reusable components!— Layered implementation approach.— Interface driven development.


MySQL Group Replication Provides...… Automatic distributed server recovery!

— Server that joins the group will automatically synchronize with the others.— If a server leaves the group, the others will automatically be informed.

… Multi-master Update Everywhere!— Any two transactions on different servers can write to the same tuple. Conflicts

will be detected.

… MySQL/InnoDB look & feel!— Load the plugin and start replicating...— Monitor group replication stats through Performance Schema tables.


Program Agenda




Considerations

Summary

1

2

3

4

5


M M M M MCom. API

ReplicationPlugin

API

MySQLServer

Group Comm.System (Corosync)Group Comm.

System (Corosync)



Com. API

ReplicationPlugin

API

MySQLServer


Server calls into the plugin through a generic interface.

— Server is Starting Recovering Ready to accept connections About to commit a transaction etc..

Plugin interacts with the server through a generic interface.

— Instruct server to Commit or abort the ongoing transaction Queue transaction in relay log etc..Group Comm.

System (Corosync)Group Comm.

System (Corosync)


Com. API

ReplicationPlugin

API

MySQLServer


The plugin is responsible for — Maintaining distributed execution context.— Detecting conflicts.— Handling distributed recovery.

Detect membership changes. Donate state if needed. Collect state if needed.

— Receiving and handling transactions from other replicas.

— Sending transactions to other replicas.— Deciding the fate of on-going transactions.


System (Corosync)


Com. API

ReplicationPlugin

API

MySQLServer


The communication API is responsible for:— Decouples the underlaying communication

system from rest of the plugin.— Mapping the interface to a specific

communication toolkit. The Group Replication labs release uses a

corosync binding.


System (Corosync)


Program Agenda




Considerations

Summary

1

2

3

4

5


API

ReplicationPlugin

API

MySQLServer

Zoom in: The Complete StackPerformance Schema Tables: Monitoring

MySQL

APIs: Lifecycle / Capture / Applier

InnoDB

Replication Protocol

Group Comm. API

Corosync

Network

Plu

ginCapture Applier

ConflictsHandler


System (Corosync)

Group Comm. Binding

Recovery


Program Agenda




Considerations

Summary

1

2

3

4

5


Current MySQL Group Replication Limitations

Only supports transactional engines (InnoDB).

Limited DDL support. Don't execute concurrently with DML.

Primary Key required on every table.

Requires global transaction identifiers turned on.

Optimistic execution: transactions may abort on COMMIT due to conflicts with concurrent transactions on other sites.

Upper limit on transaction payload size (due to corosync).


Optimistic Multi-Master Update Everywhere Observations

Workload with hotspots => higher abort rates if executed concurrently at different replicas.— Any two transactions that have high probability to conflict should execute on

the same replica.

Better suited for low latency, high-bandwidth networks – LAN.— Communication latency adds up to the execution time.— If a replica is “far” away from the rest of the group (in terms of latency), it has

more chances that its transactions are aborted during the conflict detection phase.

Large transactions are more likely to exhibit higher conflict.— Smaller concurrent transactions may commit first thus rendering large

transactions write-sets obsoletes.


Program Agenda




Considerations

Summary

1

2

3

4

5


SummaryTrendy

— Great technology for deployments where elasticity is a requirement, such as cloud based infrastructures

Integrated— It is integrated with the server core through a well defined API.— It is integrated with GTIDs, row based replication.— It is integrated with performance schema tables.

Autonomic and Operations Friendly— It is self-healing: no admin overhead for handling server fail-overs.— Provides fault-tolerance, enables multi-master update everywhere and a

dependable MySQL service.


SummaryTrendy

— Great technology for deployments where elasticity is a requirement, such as cloud based infrastructures

Integrated— It is integrated with the server core through a well defined API.— It is integrated with GTIDs, row based replication.— It is integrated with performance schema tables.

Autonomic and Operations Friendly— It is self-healing: no admin overhead for handling server fail-overs.— Provides fault-tolerance, enables multi-master update everywhere and a

dependable MySQL service.

MySQL Group Replication is all that... and more! Give it a try and send us your feedback. You can be part of this story too with your suggestions and

feature requests!


Next Steps: Read about Group Replication

Stay tuned to our blogs from the developers themselves.http://mysqlhighavailability.com/tag/mysql-group-replication/

Try this out.http://labs.mysql.com/

Suggest features, find bugs and please do get back to us.http://bugs.mysql.com/

http://mysqlhighavailability.com/tag/mysql-group-replication/

http://labs.mysql.com/

http://bugs.mysql.com/

fossasia 2015: mysql group replication

Technology

mysql group replication

oracle andor

mysql group replicationwhat

mysql slave server

replication protocol

asynchronous master

master acks

master commits