MySQL Group Replication in a nutshell

Transcription

1 1 / 126

2 2 / 126 MySQL Group Replication in a nutshell the core of MySQL InnoDB Cluster Oracle Open World September 19th 2016 Frédéric Descamps MySQL Community Manager

3 3 / 126 Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purpose 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 up in making purchasing decisions. The development, release and timing of any features or functionality described for Oracle's product remains at the sole discretion of Oracle.

4 4 / 126 MySQL Community Oracle OpenWorld Celebrate, Have Fun and Mingle with Oracle s MySQL Engineers & Your Peers Tuesday, September 20, 7.00 pm Jillian s at Metreon: 175 Fourth Street, San Francisco At the corner of Howard and 4th st.; only 2-min walk from Moscone Center (same place as last year) Join us!

5 5 / 126 about.me/lefred Who am I?

6 6 / 126 Frédéric MySQL Evangelist Managing MySQL since 3.23 devops believer

7 7 / 126 get more at the conference MySQL Group Replication

8 8 / 126 Other sessions CON MySQL High Availability Matt Lord CON MySQL High Availability with Group Replication Nuno Gomes CON The State of the Art of MySQL Replication Luis Soares HOL Building a Highly Available MySQL Database Service with Group Replication Matt Lord

9 9 / 126 Agenda Group Replication concepts

10 10 / 126 Agenda Group Replication concepts Using new & cool tools

11 11 / 126 Agenda Group Replication concepts Using new & cool tools Application interaction

12 12 / 126 the magic explained Group Replication Concept

13 13 / 126 Group Replication : what is it?

14 14 / 126 Group Replication : what is it? MySQL is one of the major components of MySQL InnoDB Cluster

15 15 / 126 Group Replication : what is it? MySQL is one of the major components of MySQL InnoDB Cluster

16 16 / 126

17 17 / 126

18 18 / 126 Group replication is a plugin!

19 19 / 126 Group replication is a plugin! GR is a plugin for MySQL, made by MySQL and packaged with MySQL

20 20 / 126 Group replication is a plugin! GR is a plugin for MySQL, made by MySQL and packaged with MySQL GR is an implementation of Replicated Database State Machine theory MySQL Group Communication System (GCS) is based on Paxos

21 21 / 126 Group replication is a plugin! GR is a plugin for MySQL, made by MySQL and packaged with MySQL GR is an implementation of Replicated Database State Machine theory MySQL Group Communication System (GCS) is based on Paxos Provides virtually synchronous replication for MySQL 5.7+

22 22 / 126 Group replication is a plugin! GR is a plugin for MySQL, made by MySQL and packaged with MySQL GR is an implementation of Replicated Database State Machine theory MySQL Group Communication System (GCS) is based on Paxos Provides virtually synchronous replication for MySQL 5.7+ Supported on all MySQL platforms!! Linux, Windows, Solaris, OSX, FreeBSD

23 23 / 126 Multi-master update anywhere replication plugin for MySQL with built-in conflict detection and resolution, automatic distributed recovery, and group membership.

24 24 / 126 Group Replication : how does it work?

25 25 / 126 Group Replication : how does it work? A node (member of the group) send the changes (binlog events) made by a transaction to the group through the GCS.

26 26 / 126 Group Replication : how does it work? A node (member of the group) send the changes (binlog events) made by a transaction to the group through the GCS. All members consume the writeset and certify it

27 27 / 126 Group Replication : how does it work? A node (member of the group) send the changes (binlog events) made by a transaction to the group through the GCS. All members consume the writeset and certify it If passed it is applied, if failed, transaction is rolled back on originating server and discarded at other servers.

28 28 / 126 OK... but how does it work?!

29 29 / 126 OK... but how does it work?! It's just magic!

30 30 / 126 OK... but how does it work?! It's just magic!... no, in fact the writesets replication is synchronous and then certification and apply of the changes are local to each nodes and asynchronous.

31 31 / 126 OK... but how does it work?! It's just magic!... no, in fact the writesets replication is synchronous and then certification and apply of the changes are local to each nodes and asynchronous. not that easy to understand... right? Let's illustrate this...

32 32 / 126 MySQL Group Replication (autocommit)

33 33 / 126 MySQL Group Replication (autocommit)

34 34 / 126 MySQL Group Replication (autocommit)

35 35 / 126 MySQL Group Replication (autocommit)

36 36 / 126 MySQL Group Replication (autocommit)

37 37 / 126 MySQL Group Replication (autocommit)

38 38 / 126 MySQL Group Replication (autocommit)

39 39 / 126 MySQL Group Replication (full transaction)

40 40 / 126 MySQL Group Replication (full transaction)

41 41 / 126 MySQL Group Replication (full transaction)

42 42 / 126 MySQL Group Replication (full transaction)

43 43 / 126 MySQL Group Replication (full transaction)

44 44 / 126 MySQL Group Replication (full transaction)

45 45 / 126 MySQL Group Replication (full transaction)

46 46 / 126 MySQL Group Replication (full transaction)

47 47 / 126 MySQL Group Replication (full transaction)

48 48 / 126 Group Replication : Optimistic Locking With GR we use what we call optimistic locking, it means we consider a resource free and this will be confirmed or not during certification. Let's first have a look at the traditional locking to compare.

49 49 / 126 Traditional locking

50 50 / 126 Traditional locking

51 51 / 126 Traditional locking

52 52 / 126 Traditional locking

53 53 / 126 Traditional locking

54 54 / 126 Traditional locking

55 55 / 126 Optimistic Locking

56 56 / 126 Optimistic Locking

57 57 / 126 Optimistic Locking

58 58 / 126 Optimistic Locking

59 59 / 126 Optimistic Locking

60 60 / 126 Optimistic Locking

61 61 / 126 Optimistic Locking The system returns error 149 as certification failed: ERROR 1180 (HY000): Got error 149 during COMMIT

62 62 / 126 Group Replication : requirements exclusively use of InnoDB tables only

63 63 / 126 Group Replication : requirements exclusively use of InnoDB tables only every tables must have a PK defined

64 64 / 126 Group Replication : requirements exclusively use of InnoDB tables only every tables must have a PK defined only IPV4 is supported

65 65 / 126 Group Replication : requirements exclusively use of InnoDB tables only every tables must have a PK defined only IPV4 is supported a good network with low latency is important

66 66 / 126 Group Replication : requirements exclusively use of InnoDB tables only every tables must have a PK defined only IPV4 is supported a good network with low latency is important maximum of 9 members per group

67 67 / 126 Group Replication : requirements exclusively use of InnoDB tables only every tables must have a PK defined only IPV4 is supported a good network with low latency is important maximum of 9 members per group log-binmust be enabled and only ROW format is supported

68 68 / 126 Group Replication : requirements (2) enable GTIDs

69 69 / 126 Group Replication : requirements (2) enable GTIDs replication meta-data must be stored on system tables --master-info-repository=table --relay-log-info-repository=table

70 70 / 126 Group Replication : requirements (2) enable GTIDs replication meta-data must be stored on system tables --master-info-repository=table --relay-log-info-repository=table writesets extraction must be enabled --transaction-write-set-extraction=xxhash64

71 71 / 126 Group Replication : requirements (2) enable GTIDs replication meta-data must be stored on system tables --master-info-repository=table --relay-log-info-repository=table writesets extraction must be enabled --transaction-write-set-extraction=xxhash64 log-slave-updatesmust be enabled

72 72 / 126 Group Replication : limitations There are also some technical limitations:

73 73 / 126 Group Replication : limitations There are also some technical limitations: binlog checksum is not supported --binlog-checksum=none

74 74 / 126 Group Replication : limitations There are also some technical limitations: binlog checksum is not supported --binlog-checksum=none Savepoints are not supported

75 75 / 126 Group Replication : limitations There are also some technical limitations: binlog checksum is not supported --binlog-checksum=none Savepoints are not supported SERIALIZABLE is not supported as transaction isolation level

76 76 / 126 Group Replication : limitations There are also some technical limitations: binlog checksum is not supported --binlog-checksum=none Savepoints are not supported SERIALIZABLE is not supported as transaction isolation level an object cannot be changed concurrently at different servers by two operations, where one of them is a DDL and the other is either a DML or DDL.

77 77 / 126 are we compatible? Pre-study

78 78 / 126 Is my workload ready for Group Replication? Large transactions are more vulnerable because:

79 79 / 126 Is my workload ready for Group Replication? Large transactions are more vulnerable because: Large write set may increase the likelihood of certification conflicts

80 80 / 126 Is my workload ready for Group Replication? Large transactions are more vulnerable because: Large write set may increase the likelihood of certification conflicts Transaction taking longer to execute may be more vulnerable to be aborted by a certified transaction.

81 81 / 126 Is my workload ready for Group Replication? Large transactions are more vulnerable because: Large write set may increase the likelihood of certification conflicts Transaction taking longer to execute may be more vulnerable to be aborted by a certified transaction. Small transactions changing a very small set of data (hotspots):

82 82 / 126 Is my workload ready for Group Replication? Large transactions are more vulnerable because: Large write set may increase the likelihood of certification conflicts Transaction taking longer to execute may be more vulnerable to be aborted by a certified transaction. Small transactions changing a very small set of data (hotspots): Concurrently executing them at different sites will trade-off contention with roll backs due to the optimistic execution

83 83 / 126 Therefore, when using Group Replication, we should pay attention to these points: PK is mandatory (and a good one is better) avoid large transactions avoid hotspot

84 84 / 126 Scheme verification We will see now a list a queries that allows us to analyze our scheme. We will look for: non InnoDB tables tables without PK tables with a bad PK

85 85 / 126 Non InnoDB tables SELECT table_schema, table_name, engine, table_rows, (index_length+data_length)/1024/1024 AS sizemb FROM information_schema.tables WHERE engine!= 'innodb' AND table_schema NOT IN ('information_schema', 'mysql', 'performance_schema');

86 86 / 126 Tables Without Primary Key select tables.table_schema, tables.table_name, tables.engine, tables.table_rows from information_schema.tables left join ( select table_schema, table_name from information_schema.statistics group by table_schema, table_name, index_name having sum( case when non_unique = 0 and nullable!= 'YES' then 1 else 0 end ) = count(*) ) puks on tables.table_schema = puks.table_schema and tables.table_name = puks.table_name where puks.table_name is null and tables.table_type = 'BASE TABLE' and engine='innodb';

87 87 / 126 Tables with bad primarky keys set SQL_MODE=""; select a.table_schema,a.table_name, b.engine, a.column_name, a.data_type, a.column_type, a.column_key, b.table_rows from information_schema.columns as a join information_schema.tables as b on b.table_name=a.table_name and b.table_schema=a.table_schema where COLUMN_KEY='PRI' and ENGINE="InnoDB" and DATA_TYPE not like '%int' and DATA_TYPE not like 'enum%' and DATA_TYPE not like 'date%' and DATA_TYPE not like 'time%' and a.table_schema not in ('mysql','sys') group by table_schema, table_name;

88 88 / 126 Workload analysis Now it's time to play with Performance_Schema to analyze our workload. The goal is to identify: transactions with most statements (and most writes in particular) transactions with most rows affected largest statements by row affected queries updating most the same PK and therefore having to wait more)

89 89 / 126 Setup Performance_Schema We need to enable some consumers and instruments: update performance_schema.setup_consumers set enabled = 'yes' where name like 'events_statement%' or name like 'events_transaction%'; update performance_schema.setup_instruments set enabled = 'yes', timed = 'yes' where name = 'transaction';

90 90 / 126 Find the transactions with most statements select t.thread_id, t.event_id, count(*) statement_count, sum(s.rows_affected) rows_affected, length(replace(group_concat( case when s.event_name = "statement/sql/update" then 1 when s.event_name = "statement/sql/insert" then 1 when s.event_name = "statement/sql/delete" then 1 else null end),',','')) as "# write statements" from performance_schema.events_transactions_history_long t join performance_schema.events_statements_history_long s on t.thread_id = s.thread_id and t.event_id = s.nesting_event_id group by t.thread_id, t.event_id order by rows_affected desc limit 10;

91 91 / 126 Find the transactions with most statements It's possible to see what are all these statements in one transaction: set group_concat_max_len = ; select t.thread_id, t.event_id, count(*) statement_count, sum(s.rows_affected) rows_affected, group_concat(sql_text order by s.event_id separator '\n') statements from performance_schema.events_transactions_history_long t join performance_schema.events_statements_history_long s on t.thread_id = s.thread_id and t.event_id = s.nesting_event_id group by t.thread_id, t.event_id order by statement_count desc limit 1\G

92 92 / 126 Find the transactions with most rows affected select t.thread_id, t.event_id, count(*) statement_count, sum(s.rows_affected) rows_affected, length(replace(group_concat( case when s.event_name = "statement/sql/update" then 1 when s.event_name = "statement/sql/insert" then 1 when s.event_name = "statement/sql/delete" then 1 else null end),',','')) as "# write statements" from performance_schema.events_transactions_history_long t join performance_schema.events_statements_history_long s on t.thread_id = s.thread_id and t.event_id = s.nesting_event_id group by t.thread_id, t.event_id order by rows_affected desc limit 10;

93 93 / 126 Find the transactions with most rows affected It's again possible the see what are the statements: select t.thread_id, t.event_id, count(*) statement_count, sum(s.rows_affected) rows_affected, group_concat(sql_text order by s.event_id separator '\n') statements from performance_schema.events_transactions_history_long t join performance_schema.events_statements_history_long s on t.thread_id = s.thread_id and t.event_id = s.nesting_event_id group by t.thread_id, t.event_id order by rows_affected desc limit 1\G

94 94 / 126 Find the transactions with most rows affected It's again possible the see what are the statements: select t.thread_id, t.event_id, count(*) statement_count, sum(s.rows_affected) rows_affected, group_concat(sql_text order by s.event_id separator '\n') statements from performance_schema.events_transactions_history_long t join performance_schema.events_statements_history_long s on t.thread_id = s.thread_id and t.event_id = s.nesting_event_id group by t.thread_id, t.event_id order by rows_affected desc limit 1\G Don't forget to verify the auto_commit ones are they are not returned with the query above.

95 95 / 126 Find largest statements by row affected select query, db, rows_affected, rows_affected_avg from sys.statement_analysis order by rows_affected_avg desc limit 10;

96 96 / 126 Find queries that write the most. Looking for lots of updates/timer_wait to the same PKs. select * from performance_schema.events_statements_history_long where rows_affected > 1 order by timer_wait desc limit 20\G

97 97 / 126 help me to configure my InnoDB Cluster Using new cool tools

98 98 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language:

99 99 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language: JavaScript

100 100 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language: JavaScript Python

101 101 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language: JavaScript Python SQL

102 102 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language: JavaScript Python SQL Supports both Document and Relational models

103 103 / 126 MySQL Shell The MySQL Team extended MySQL Shell to use the new Admin API. Now MySQL Shell is a single unified client for all adminstrative and operatons tasks. Multi-Language: JavaScript Python SQL Supports both Document and Relational models Exposes full Development and Admin API

104 104 / 126 MySQL Shell: Admin API mysql-js>dba.help()

105 105 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API

106 106 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster:

107 107 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster: create cluster

108 108 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster: create cluster deploy MySQL instances (in sandbox only for the moment)

109 109 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster: create cluster deploy MySQL instances (in sandbox only for the moment) get cluster info

110 110 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster: create cluster deploy MySQL instances (in sandbox only for the moment) get cluster info start/stop MySQL instances

111 111 / 126 MySQL Shell: Admin API mysql-js>dba.help() the global variable dba is used to access the MySQL API perform DBA operations to manage MySQL InnoDB Cluster: create cluster deploy MySQL instances (in sandbox only for the moment) get cluster info start/stop MySQL instances validate MySQL instances

112 112 / 126 mysqlprovision The mysqlprovision utility is designed to facilitate the management of MySQL Group Replication, allowing users to start a replica set (a new replication group), to add/remove members to/from an existing group. It can also check if an instance meets all the requirements to successfully create a new group or to be added to an existing group. This utility is also capable of modifying MySQL option files of existing instances in order for them to meet the requirements of Group Replication.

113 113 / 126 let's create our first MySQL InnoDB Cluster Demo time!

114 114 / 126 MySQL InnoDB Cluster demo

115 115 / 126 full HA? Application interaction

116 116 / 126 MySQL InnoDB Cluster So MySQL InnoDB Cluster is composed by: MySQL Router MySQL Shell MySQL Group Replication MySQL Server

117 117 / 126 MySQL InnoDB Cluster So MySQL InnoDB Cluster is composed by: MySQL Router MySQL Shell MySQL Group Replication MySQL Server CON MySQL High Availability - Matt Lord - Wed 12:15

118 118 / 126 MySQL Router Transparent client connection routing (TCP level 4) load balancing connection failover Native support for InnoDB Clusters understands Group Replication topology utilizes metadata schema stored on each members bootstrap and auto-config supports multi-master and single primary modes

119 119 / 126 MySQL Router & Group Replication Quick demo!

120 120 / 126 MySQL Router & Group Replication demo

121 121 / 126 Any other alternatives?

122 122 / 126 Any other alternatives? It's possible to use MySQL Group Replication with other proxies/load-balancers

123 123 / 126 Any other alternatives? It's possible to use MySQL Group Replication with other proxies/load-balancers HAProxy :

124 124 / 126 ProxySQL :

125 125 / 126 Thank you! Questions?

126 126 / 126 MySQL Community Oracle OpenWorld Tuesday, September 20, 7.00 pm Jillian s at Metreon: 175 Fourth Street, San Francisco At the corner of Howard and 4th st.; only 2-min walk from Moscone Center (same place as last year) Join us! Register: