multi source replication pdf

1 | Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | MySQL User Camp| Bangalore, India, October 17 th, 2014. |

MySQL Labs : Multi Source Replication

Venkatesh Duggirala MySQL Replication Team

2 | Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | MySQL User Camp| Bangalore, India, October 17th, 2014. |

Safe Harbour 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.


MySQL Labs features are not fit for production.

They are provided solely for testing purposes, to try the latest bug fixes and generally to keep up with the development.

Please, do not use these binaries in production.

Instead, install them on a spare server.

If you are looking for production ready binaries, please visit MySQL Downloads.

http://dev.mysql.com/downloads/


Agenda

Background: Why Use Replication?

Multi-source Replication

– Introduction

– Use cases

– Internals

– Monitoring

Reading More about Multi-source Replication


Redundancy: If master crashes, promote slave to master

C

B

A

Background: What is Replication Used For?

C

B

ACrash

C

B

A

B is thenew master

Uh Oh! Whew!


Read scale-out

M SS

S

S

M

write clients read clientsread clients

write clients

Morereads?More

slaves!



On-line Backup and Reporting


M

S

write clients

business intelligent client apps reporting client apps big queries client apps


M

S

Different types of Replication servers setup

1


M

S

M

S1 S2


1 2


M

S

M

S1 S2

M1

M2

S


1 2 3


M

S

M

S1 S2

M1

M2

S

M1 M2

S


1 2 3 4


M

M

M

M

MM

S

M

S1 S2

M1

M2

S

M1 M2

S


1 2 3 4 5


Agenda



– Introduction

– Use cases

– Internals

– Monitoring



Before Multi-source replication :● Time sharing replication, where a slave would connect to a master

for a particular time slice. ● Have a hierarchical replication, where a slave that is to receive

updates from the several masters is at the end of replication hierarchy. (Like, M1->M2->M3->Slave)

● Using several instances of mysqlbinlog + GTIDs.

Multi-source replication feature aims to:● Receive transactions (in the form of binary log events) from

several MySQL servers simultaneously via several communication channels.

● Apply these received transactions (will not do any conflict detection or resolution)


Multi-Source Replication: Introduction

A Slave can have more than one master.

S

M4

M1

M3

M2



M1db1db1db1




M1

M2

db1db1db1

db2




M4

M1

M3

M2

db1db1db1

db4

db3

db2




S db1db1db1 db4db3db2

M4

M1

M3

M2

db1db1db1

db4

db3

db2



Agenda



– Introduction

– Use cases

– Internals

– Monitoring



Business IntelligenceData analytics

Backupetc

SM2

M1

M3

Database 2

Database 3

Database 1, 2, 3

Database 1

Multi-Source Replication: Use CasesThe main use cases of Multi-source replication are related to data aggregation.


Multi-Source Replication: Use Cases

SM

M

M

Shard 2

Shard 3

Full table

Shard 1

The main use cases of Multi-source replication are related to data aggregation.


Agenda



– Introduction

– Use cases

– Internals

– Monitoring



Multi-Source Replication: More details..

S

M4

M1

M3

M2

Slave can have more than one master.

– Receive transactions from several MySQL servers simultaneously.

– Apply transactions from different masters simultaneously.

– No conflict detection or resolution.


Insert...

Insert...

B

binary log

Insert...

relay log

Insert...

A

binary log

Client

Network

Multi-Source Replication: What is a Channel?

Senderthread

Receiverthread Applier

thread

A channel is an an abstraction for a sender-receiver-applier path.

Channel


S

relay log1M1 binary log Network

Multi-Source Replication: How Many Channels?

Number of channels on slave = Number of sources.



binary log



Multi-Source Replication: Slave Appliers

Each channel has its own single-threaded slave applier.



binary logS


binary log

M1 binary log Network

Multi-Source Replication: Slave Appliers

Each channel can also have its own multi-threaded slave applier.

SM2

M3

Network relay log2

relay log3Network relay log3

binary log

binary log

relay log1


Adding / Configuring A Channel

Each channel can be configured individually.

To add or alter a channel configuration use:

CHANGE MASTER TO master_def …

FOR CHANNEL ”<channel_name>”

– Channel names are case insensitive

– Special chars are allowed

– maximum number of channels is 256


FOR CHANNEL ”<channel_name>” clause is added for:– start slave [thread_type] FOR CHANNEL ”<channel_name>"

– stop slave [thread_type] FOR CHANNEL ”<channel_name>”

– reset slave [all] FOR CHANNEL ”<channel_name>”

– flush relay logs FOR CHANNEL ”<channel_name>”

– show relay log events FOR CHANNEL ”<channel_name>”

An extra argument added for functions like– MASTER_POS_WAIT(<binlog_file>, <binlog_pos>, <time_out>,

<channel_name>);

– WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(<gtid_set>, <time_out>, <channel_name>);

Replication Commands on a Channel


To make commands work on ALL CHANNELS

– START SLAVE [thread_type]

– STOP SLAVE [thread_type]

– SHOW SLAVE STATUS

– FLUSH RELAY LOGS

ER_SLAVE_MULTIPLE_CHANNELS_CMD(1964)– SHOW RELAYLOG EVENTS;

– CHANGE MASTER

– MASTER_POS_WAIT()

– WAIT_FOR_SQL_THREAD_AFTER_GTIDS()

Working With All Channels


Compatibility With Other Replication Features

Multi-Threaded Slaves Yes

Global Transaction Identifiers Yes

Semi-Synchronous Replication Yes*

Slave Repositories Yes*

Filters Yes*


Multi threaded slaves: slave_parallel_workers=k and M channels will have (k+1)*M applier threads running.

GTIDs: A requirement as is the case with (normal master-slave replication), is that all the masters and the slave should have GTID_MODE=ON.

Semi-Synchronous Replication: all the masters and the slave should be in semi sync mode

Filters: replication filters are global in the labs release, ie. the applier threads of all channels will rely on a single global filter.

Compatibility continued 2...


Slave Repositories:

Only TABLE repository is supported (Crash safe slave) --mysqld= --master_info_repository= TABLE; --mysqld= --relay_log_info_repository= TABLE;

Convert FILE repository to TABLE repository dynamically STOP SLAVE; SET GLOBAL master_info_repository= 'TABLE'; SET GLOBAL relay_log_info_repository= 'TABLE';

Compatibility continued 3...


Simple Setup

✔ Start 3 servers


Simple Setup

S

M2M1

13000 13001

13002

13001

✔ Start 3 servers , M1 (13000), M2 (13001), S (13002)


Simple Setup

S

M2M1

13000 13001

13002

13001

✔ Start 3 servers , M1 (13000), M2 (13001), S (13002) ✔ On Slave(S), > CHANGE MASTER TO MASTER_PORT=13000,..., FOR CHANNEL 'CHANNEL_M1';

✔CHANNEL_M1 is created

channel_m1


Simple Setup

S

M2M1

13000 13001

13002

13001



> START SLAVE FOR CHANNEL 'CHANNEL_M1'✔ I/O thread for CHANNEL_M1 will be created✔ M1's binary log (table t1 changes) will be retrieved by I/O thread and written to slave-relay-bin-channel_m1.00001 relay log

✔ SQL thread will start reading it from relay log and will start applying the data.

channel_m1

insert into t1(..)

master1-bin.000001

insert into t1(..)

Slave-relay-bin-channel_m1.000001


Simple Setup

S

M2M1

13000 13001

13002

13001





> CHANGE MASTER TO MASTER_PORT=13001,..., FOR CHANNEL 'CHANNEL_M2'

✔ CHANNEL_M2 is created

channel_m1 channel_m2

insert into t1(..)

master1-bin.000001

insert into t1(..)



Simple Setup

S

M2M1

13000 13001

13002

13001










insert into t1(..)

master1-bin.000001

insert into t2(..)

master2-bin.000002

insert into t1(..) insert into t2(..)




Simple Setup

S

M2M1

13000 13001

13002

13001










insert into t1(..)insert into t1(..)

master1-bin.000001


master2-bin.000002


insert into t2(..)insert into t2(...)




Agenda



– Introduction

– Use cases

– Internals

– Monitoring



Replication Monitoring: P_S Replication Tables

Connection Configuration

Connection Status

Execution Configuration

Execution Status

Slave Status

Applier / CoordinatorStatus

WorkersStatus


We have six performance schema tables for replication

– replication_connection_configuration

– replication_connection_status

– replication_execute_configuration

– replication_execute_status

– replication_execute_status_by_coordinator

– replication_execute_status_by_worker

Consistent semantics across tables. Lets explore one of them.

Replication Monitoring: P_S Replication Tables

One row per CHANNEL

One row per CHANNEL per WORKER


mysql> select * from performance_schema.replication_connection_status\G

*************************** 1. row ***************************CHANNEL_NAME : channel1SOURCE_UUID : 7cff7406-23ca-11e3-ac3e-5c260a83b12bTHREAD_ID : 13SERVICE_STATE : ONRECEIVED_TRANSACTION_SET : 7cff7406-23ca-11e3-ac3e-5c260a83b12b:1-4LAST_ERROR_NUMBER : 0LAST_ERROR_MESSAGE :LAST_ERROR_TIMESTAMP : 0000-00-00 00:00:00*************************** 2. row ***************************CHANNEL_NAME : channel2...

Replication Monitoring: Connection Status

One row per CHANNEL





Receiver thread & its service state





Set of transactions receivedthrough this channel



*************************** 1. row ***************************CHANNEL_NAME : channel1SOURCE_UUID : 7cff7406-23ca-11e3-ac3e-5c260a83b12bTHREAD_ID : 13SERVICE_STATE : ONRECEIVED_TRANSACTION_SET : 7cff7406-23ca-11e3-ac3e-5c260a83b12b:1-4LAST_ERROR_NUMBER : 1045LAST_ERROR_MESSAGE : error connecting to master '[email protected]:13000' ...LAST_ERROR_TIMESTAMP : 2013-11-04 13:37:23*************************** 2. row ***************************CHANNEL_NAME : channel2...


Oops! There was an error in the receiver thread on this channel



*************************** 1. row ***************************CHANNEL_NAME : channel1SOURCE_UUID : 7cff7406-23ca-11e3-ac3e-5c260a83b12bTHREAD_ID : NULLSERVICE_STATE : OFFRECEIVED_TRANSACTION_SET : 7cff7406-23ca-11e3-ac3e-5c260a83b12b:1-4LAST_ERROR_NUMBER : 1045LAST_ERROR_MESSAGE : error connecting to master '[email protected]:13000' ...LAST_ERROR_TIMESTAMP : 2013-11-04 13:37:23*************************** 2. row ***************************CHANNEL_NAME : channel2...


Receiver thread on this channel stopped serving...


Agenda



– Introduction

– Use cases

– Internals

– Monitoring



Read More About Multi Source Replication

Read more about Multi-source replication on Rith's blog: http://mysqlhighavailability.com/5-7-5-labs-multi-source-replication/

Read more about replication P_S tables on Shiv's blogs:http://shivjijha.blogspot.com/2013/09/Monitoring-Replication-with-the-NEW-performance-schema-tables.html

http://mysqlhighavailability.com/global-variables-in-rpl-ps/

Official MySQL documentation for replication P_S tables:http://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-tables.html

Read a feature preview of Multi-source replication on Rith's blog:http://on-mysql-replication.blogspot.in/2013/09/feature-preview-mysql-multi-source-replication.html

http://shivjijha.blogspot.com/2013/09/Monitoring-Replication-with-the-NEW-performance-schema-tables.html

http://shivjijha.blogspot.com/2013/09/Monitoring-Replication-with-the-NEW-performance-schema-tables.html

http://mysqlhighavailability.com/global-variables-in-rpl-ps/

http://on-mysql-replication.blogspot.in/2013/09/feature-preview-mysql-multi-source-replication.html

http://on-mysql-replication.blogspot.in/2013/09/feature-preview-mysql-multi-source-replication.html

multi source replication pdf

Presentations & Public Speaking