MySQL Manchester TT - Replication Features

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. | Wednesday, September 23, 2015 Percona Live -‐ Amsterdam

The Latest and Greatest MySQL 5.7 ReplicaGon Features and More!

Mark Swarbrick Principal Presales Consultant UK&I

1

Copyright © 2015, Oracle and/or its affiliates. All rights reserved. |

Safe Harbor Statement The following is intended to outline our general product direcGon. It is intended for informaGon purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or funcGonality, and should not be relied upon in making purchasing decisions. The development, release, and Gming of any features or funcGonality described for Oracle’s products remains at the sole discreGon of Oracle.

Wednesday, September 23, 2015 Percona Live -‐ Amsterdam 2


Program Agenda

Wednesday, September 23, 2015 Percona Live -‐ Amsterdam


Program Agenda Background

ReplicaGon Features in MySQL 5.7

News From The Lab!

The Road Ahead!

Conclusion

1

2

3

4

5



Background 1



Background: ReplicaGon Components

Wednesday, September 23, 2015

Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log

Client Sender thread

Receiver thread

Applier Threads

Receiver Meta-‐data Update

Applier Meta-‐data Update

Network

Percona Live -‐ Amsterdam 6


Background: ReplicaGon Components • Binary Log

– File based logical log that records the changes on the master. – Statement or Row based format (may be intermixed). – Each transacGons is split into groups of events. – Control events: Rotate, Format DescripGon, GGd, ...


Layout of a Binary Log File

BEGIN ... E1 E2 COMMIT BEGIN ... E1 E2 COMMIT



M S

S

S

S

M

write clients read clients read clients

write clients

More reads? More slaves!

Read scale-‐out

Background: What is ReplicaGon Used For?



M M?

write clients write clients

More writes? More

Masters?

M?

M?

What about write scale-‐out?



C

B

A

C

B

A Crash

C

B

A

B is the new master

Uh Oh! Whew!

Redundancy: If master crashes, promote slave to master

Background: What is ReplicaGon Used For?



M

S

write clients

business intelligent client applicaGons reporGng client applicaGons big queries client applicaGons

On-‐line Backup and ReporPng Background: What is ReplicaGon Used For?



C B

B A A C

Image from www.ginkgomaps.com

Background: What is ReplicaPon Used For?



ReplicaGon Features in MySQL 5.7 2



ReplicaGon Features in MySQL 5.7 Usability / Online

2


2.1

Percona Live -‐ Amsterdam


Online ReconfiguraGon of Global TransacGon IdenGfiers


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Online ReconfiguraGon of Global TransacGon IdenGfiers •  The procedure is online.

– Both reads and writes are allowed while global transacGon idenGfiers are being turned on or off in the enGre replicaGon cluster.

• No need to synchronize servers, ever. • No need to restart servers. • No need to change replicaGon topology.

– Works in arbitrary topologies.

•  Should anything happen in the middle of the procedure, you can always roll back.



Online ReconfiguraGon of ReplicaGon Filters


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Online ReconfiguraGon of ReplicaGon Filters • Change Slave's ReplicaGon Filters dynamically.

– No need to stop and restart the slave server for sejng new replicaGon filtering rules. – All slave filters are supported. – Values can be input in various character sets.


mysql> CHANGE REPLICATION FILTER REPLICATE_DO_DB= (db1, db2)



Online Switch/Fail-‐over to a new Master


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Change master from A to B without stopping the applier threads.



C

B

A

C

B

A Crash

C

B

A

B is the new master

Uh Oh! Whew!



Change master from A to B without stopping the applier threads.



C

B

A

C

B

A Crash

C

B

A Uh Oh! Whew!

DBA did not need C to stop applying its relay log to change C's master from A to B.



Online Switch/Fail-‐over to a new Master •  Enables more online operaGons during fail-‐over:

•  Stopping, changing master and restarGng the receiver thread are all done while the applier thread is running.

• Change applier properGes while the receiver thread is working:


mysql> STOP SLAVE IO_THREAD; mysql> CHANGE MASTER TO MASTER_HOST='master2', …; mysql> START SLAVE IO_THREAD;

mysql> STOP SLAVE SQL_THREAD; mysql> CHANGE MASTER TO MASTER_DELAY=3600, …; mysql> START SLAVE SQL_THREAD;



Improved ReplicaGon Monitoring


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network


DBA



• Monitoring through SQL. •  Logically unrelated informaGon into different places. •  Extensible, can be adapted to new features. • More accurate and consistent idenGfier names. • Master-‐slave, MulG-‐source, Group ReplicaGon support.

Performance Schema ReplicaPon Tables





ConnecPon ConfiguraPon

ConnecPon Status

Applier ConfiguraPon

Applier Status

(Slave) Receiver and Applier Status

Applier / Coordinator Status

Workers Status



ReplicaGon Features in MySQL 5.7 Usability / Online Performance

2


2.1

2.2



Improved Applier Throughput – Locking-‐based Parallelism


S ingle Threaded Apply 8 Threads Applier 24 Threads Applier 48 Threads Applier 96 Threads Applier0%

50%

100%

150%

200%

250%

F as t and S c alable Multi-‐threaded Replic ation Applier

(s tatement-‐bas ed replication, durable s ettings , S S D s torage)

Slav

e ap

ply tim

e (S

ysbe

nch RW

on the mas

ter w

ith 96 thread

s = 10

0%)

10X



Improved Applier Throughput – Locking-‐based Parallelism •  Leverage parallelizaGon informaGon from master execuGon:

– Concurrent transacGons, which have not blocked each other on the master, are marked as non-‐contending in the binary log.

• Meanwhile, at the slave: – Non-‐contending transacGons are scheduled in parallel; – Concurrent transacGons commit independently, thus no waiPng involved.



Improved Applier Throughput – Locking-‐based Parallelism

•  T2 is scheduled to execute together with T1.

•  T3 is scheduled to execute as soon as T1 finishes.


T1

T2

T3

Time

Commit Finishes

Last Lock Acquired

Concurrent ExecuGon History on the Master

ExecuPon

Commit

T1 and T2 execute in parallel on the slave.

T2 and T3 execute in parallel on the slave.



Improved Applier Throughput – Locking-‐based Parallelism •  Supports statement-‐based or row-‐based formats. •  Scheduling policy controlled through:

– logical_clock -‐ means schedule based on the locking interval Gmestamps. – database -‐ the scheduling policy from 5.6 (concurrency control done per database).

• Work to improve slave scalability conGnues, does not stop here.


mysql> SET slave_parallel_type= [logical_clock|database]



Improved User Threads-‐Sender Threads SynchronizaGon


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Improved User Threads-‐Sender Threads SynchronizaGon • Concurrent reads by the sender thread with ongoing writes from user threads. – Sender thread does not block user sessions more than necessary. – Higher throughput for both sender threads and user sessions.


Sender Thread Reads Binary Log User Thread Writes to Binary Log

Sender Thread Reads Binary Log

User Thread Writes to Binary Log

pre 5.7.2

5.7.2+



Faster Sender Thread •  Ad hoc microbenchmark using mysqlslap

•  1M queries, concurrency=200, commit=1

•  N slaves aoached (fake slaves using remote mysqlbinlogs)

•  48 cores HT / 512 GB RAM / HDD


0 2000 4000 6000 8000

10000 12000 14000 16000

1 2 3 4 5 6 7 8 9

QpS

Number of Connected Sender Threads

Master’s Throughput

MySQL 5.6.16 MySQL 5.7.4



Faster Semi-‐sync ReplicaGon – ACK Receiver Thread


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log

Client

ACK Receiver thread

Receiver thread

Applier Threads



Network

Sender thread



Faster Semi-‐sync ReplicaGon – ACK Receiver Thread • ConsecuGve transacGons do not block each other while waiGng for ACKs

– TransacGon t1 and t2 are sent immediately to the slave by the sender thread – ACKs are received only by a special thread – TransacGon t2 does not include t1 round trip in its semi-‐sync overall latency

•  Thread starts when semi-‐sync is acGvated

•  Thread stops when semi-‐sync is deacGvated


mysql> SET GLOBAL rpl_semi_master_enabled= ON

mysql> SET GLOBAL rpl_semi_master_enabled= OFF



Faster Semi-‐sync: Durability over the Network



ReplicaGon Features in MySQL 5.7 Usability / Online Performance Dependability

2


2.1

2.2

2.3



Loss-‐less Semi-‐sync ReplicaGon


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Loss-‐less Semi-‐sync ReplicaGon


Master

Slave

T1: INSERT INTO t1 VALUES (1000)

ACK

Time

T2: SELECT * FROM t1; empty set

execute prepare binlog

relay log

commit execute



Loss-‐less Semi-‐sync ReplicaGon • Master waits for slave's ACK before commijng (as opposed to: master waits for slave's ACK aier commijng). – Therefore, concurrent transacGons do not see changes while this transacGon waits for ack.

•  Should a master fail, then any transacGon that it may have externalized is also persisted on a slave.

• User can choose between the original semi-‐sync behavior and the new one.


mysql> SET rpl_semi_sync_master_wait_point= [AFTER_SYNC|AFTER_COMMIT]



Semi-‐sync ReplicaGon – Wait for MulGple ACKs


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network



Semi-‐sync ReplicaGon – Wait for MulGple ACKs • Master does not commit transacGon unGl it receives N ACKs from N slaves. • Dynamically seoable:


mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N



Semi-‐sync ReplicaGon – Wait for MulGple ACKs • Master does not commit transacGon unGl it receives N ACKs from N slaves. • Dynamically seoable:


mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N

Master

Slave 2

T1: COMMIT

ACK Slave 1

ACK

T1: COMMIT succeeds

mysql> SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= 2

Slave 3 Time

relay log

relay log

relay log


ACK


ReplicaGon Features in MySQL 5.7 Usability / Online Performance Dependability Flexibility

2


2.1

2.2

2.3

2.4



Storing Global TransacGon IdenGfiers in a Table


Insert...

B Insert...

relay log

Insert...

A

binary log


Receiver thread

Applier Threads



Network




•  Slaves can use GTIDs with binary logs disabled. – Slaves that are never candidates to become a master can sGll use GTIDs for auto posiGoning.

Use Cases




• GTIDs are saved into a mysql system table (range-‐compressed).

• GTIDs are inserted into the table as transacGons commit. • A compression thread runs periodically and compresses the table into ranges. – New global variable controls the period: gGd_executed_compression_period.

Mechanics


CREATE TABLE gtid_executed( source_uuid CHAR(36) NOT NULL, interval_start BIGINT NOT NULL, interval_end BIGINT NOT NULL, PRIMARY KEY(source_uuid, interval_start) );

mysql> SET GLOBAL gtid_executed_compression_period= N;(N – number of transactions)




• Binary Log Enabled – Store GTID in binary log (transacGonally). – Copy GTID set to table on binary log rotaGon.

• Binary Log Disabled – Store GTID in table (transacGonally). – New transacGons are not assigned a GTID.

• Always store GTIDs transacGonally.

Mechanics



MulG-‐Source ReplicaGon


S

M M Slave can have more than one master. M M

The need for gathering data in a central server: •  Integrated backup; •  Complex queries for analyGcs purposes; •  Data HUB for inter-‐cluster replicaGon.



MulG-‐Source ReplicaGon •  Integrated with GTIDs. •  Integrated with crash-‐safe tables.

– Progress state is stored in these tables for recoverability purposes. • Virtually no limit on the number of sources (capped to 256, but can be changed if server binary is rebuilt).

• Able to manage each source separately.



ReplicaGon Features in MySQL 5.7 Usability / Online Performance Dependability Flexibility Misc

2


2.1

2.2

2.3

2.4

2.4



“Smaller”, yet interesPng, enhancements! • MulP-‐threaded applier is able to retry failed transacPons. •  OpGon to make the MulP-‐threaded applier preserve commit order.

•  SSL opGons for mysqlbinlog tool.

•  Rewrite DB rules for the mysqlbinlog tool.

•  FuncPon to wait for transacPons to be applied, regardless of the replicaGon stream they come from.

•  OpGons to track global transacPon idenPfiers in the return packet of the mysql protocol.

•  Support for XA transacPons when the binary log is enabled. •  Change in the defaults. E.g., binlog_format=ROW and sync_binlog=1.



News From The Lab! 3



MySQL Group ReplicaGon Plugin


M M M M M

ReplicaPon Group

•  MulG-‐master update everywhere •  AutomaPc group membership

management and failure detecPon.

•  No need for server fail-‐over. •  AutomaPc reconfiguraPon.

•  No single point of failure. •  Shared-‐nothing state machine

replicaGon.

•  InnoDB compliant. Off-‐the-‐shelf hardware friendly.



MySQL Group ReplicaGon Plugin • Great technology for deployments where elasGcity is a requirement, such as cloud based infrastructures. – Integrated with the server core through a well defined API. – It is integrated with GTIDs, row based replicaGon. – It is integrated with performance schema tables. – It is elasGc and self-‐healing: adding or removing servers does not need human intervenGon.



MySQL Router • MoGvaGon

– The need for transparent integraGon with Fabric. •  No need to upgrade exisGng connectors. •  Use Fabric with connectors that do not support it (e.g., PHP, Ruby, Perl, C).

– The need for read-‐write and read-‐only automaGc rouGng. •  Do not need to know which server is the master. •  Transparent fail-‐over support for a new master.

•  End Result – Generic and versaGle framework: MySQL Router.


NEW

M

Router

App

M M

Fabric

56


MySQL Router • Highlights

– High Performance – Plugin Driven Architecture – Simple to setup, configure and deploy.

•  Features – ConnecGon rouGng and simple load balancing. – Seamless fail-‐over based on Fabric HA Groups. – Fail-‐over without Fabric (needs 3rd party tool to handle fail-‐over itself).

– reducing conflicts when deployed together with Group ReplicaGon.


M

Router

App

M M

Fabric

NEW

57


The Road Ahead! 4



What is Next? • MySQL Group ReplicaPon

– Rapid releases. – Improve performance, stability and usability.

• MySQL ReplicaGon Usability – Instrument even more replicaGon and extend replicaGon P_S tables – Simpler administraGve commands

• MySQL ReplicaGon Performance – ConGnue to improve mulG-‐threaded (slave) applier – ConGnue to improve semi-‐sync

• MySQL Fabric and MySQL Router inter-‐operability Wednesday, September 23, 2015 Percona Live -‐ Amsterdam 59


Summary 7



Summary •  ReplicaGon feature set in MySQL 5.7 shows many improvements:

– Semi-‐sync is more flexible and faster. – Less contenGon on the binary log. – Slave is faster and provides an inter-‐transacGon parallelizaGon scheme. – More online reconfiguraGon: Global TransacGon IdenGfiers, filters, configuraGon. – Improved monitoring. – Even more flexible replicaGon with mulG-‐source enabling new deployment scenarios. – Enhancements all over: transacGon retries, sequenGal commits, XA support, new replicaGon funcGons, security.

•  Lab releases provide a sneak peek at what is coming -‐ a new replicaGon plugin and exciGng new infrastructure: MySQL Group ReplicaPon and MySQL Router.



Where to go from here? • Packages

– hop://dev.mysql.com – hop://labs.mysql.com

• Reference DocumentaGon – hop://dev.mysql.com/doc/#manual

• Blogs from the Engineers (news, quirks, technical informaGon and much more) – hop://mysqlhighavailability.com


MySQL Manchester TT - Replication Features

Technology

Transcript of MySQL Manchester TT - Replication Features