replic8 The Eighth Generation of MySQL Replication Sven Sandberg MySQL Replication Core Team Lead

Transcription

1 replic8 The Eighth Generation of MySQL Replication Sven Sandberg MySQL Replication Core Team Lead

2 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. 2

3 there s no deb8: it s never too l8 to replic8 with version 8 3

4 Overview Background: (Group) Replication 8.0: Performance 8.0: Monitoring 8.0: Operations More! 4

5 MySQL Group Replication clients Traditional database Many clients One 5

6 MySQL Group Replication clients Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members Message delivery State updates 6

7 MySQL Group Replication clients R R R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members Message delivery State updates 7

8 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members Limitations apply! Message delivery State updates 8

9 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members D Message delivery State updates 9

10 MySQL Group Replication clients A R D R R R B E C Group Replication Many clients Many s Read scalability rite everywhere* Elastic, Highly available Agreement on: Members Message delivery State updates 10

11 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members D E Message delivery State updates 11

12 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members D E Message delivery State updates 12

13 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members E Message delivery State updates 13

14 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members E Message delivery State updates 14

15 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members Message delivery State updates 15

16 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members e are 3: A, B, C! e are 3: A, B, C! e are 3: A, B, C! Message delivery State updates 16

17 MySQL Group Replication clients R R R R Group Replication Many clients Many s Read scalability rite everywhere* A B C Elastic, Highly available Agreement on: Members Message delivery State updates 17

18 MySQL Group Replication clients R R R R A B Group Replication Many clients Many s Read scalability rite everywhere* Elastic, Highly available Agreement on: Members You and me: A and B! You and me: A and B! Message delivery State updates 18

19 MySQL Group Replication clients R R R R A B A B All receive in same order Group Replication Many clients Many s Read scalability rite everywhere* Elastic, Highly available Agreement on: Members Message delivery State updates 19

20 MySQL Group Replication clients Queue insert row 3 insert row 4 R R R R A Table row 1 row 2 B Queue insert row 4 Table row 1 row 2 row 3 Group Replication Many clients Many s Read scalability rite everywhere* Elastic, Highly available Agreement on: Members Message delivery State updates 20

21 MySQL Group Replication Summary: GR in 8 is gr8 Group Replication Many clients Many s Read scalability rite everywhere* Elastic, Highly available Agreement on: Members Message delivery State updates 21

22 MySQL Async Replication 22

23 MySQL Async Replication 23 Example: Async replication between geo-distributed groups

24 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 24

25 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 25

26 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 26

27 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 27

28 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 28

29 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 29

30 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 30

31 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 31

32 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 32

33 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 33

34 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 34

35 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 35

36 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 36

37 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 37

38 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 38

39 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 39

40 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 40

41 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 41

42 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 42

43 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 43

44 Replication Architecture: Applier Pipeline Receiver Relay Log Coordinator orker Queues orker s network Replica 44

45 Overview Background: (Group) Replication 8.0: Performance 8.0: Monitoring 8.0: Operations More! 45

46 8.0 Performance: riteset Parallelization Replica can apply more transactions in parallel Able to keep worker threads busy Can now use the full potential of the applier pipeline 46

47 8.0 Performance: riteset Parallelization 5.6: parallelize transactions that modify different databases db1 db2 db3 db3 db3 db3 parallel isolated isolated isolated 5.7: parallelize transactions that committed together parallel parallel Typical parallelism: less than primary Typical parallelism: close to primary 8.0: parallelize transactions that modify disjoint sets of rows row 1 row 2,3 row 4 row 1,5 row 6 row 4 Typical parallelism: more than primary always >= 3 transactions applying in parallel in this example 47

48 8.0 Performance: riteset Parallelization To enable: primary> SET binlog_transaction_dependency_tracking = RITESET; replica> SET slave_parallel_workers = 4, slave_parallel_type = LOGICAL_CLOCK, slave_preserve_commit_order = 1; Note: slave_preserve_commit_order = 1: Apply in parallel, commit in order Preserves application constraints between transactions: w trx1, trx2 A Constraint: trx1 must commit before trx2 48

49 8.0 Performance: Applier Pipeline Parallelize reads and writes to relay log Receiver Relay Log Coordinator orker Queues orker s trx1 network trx1 Replica Performance for free 49

50 8.0 Performance: Efficient JSON Replication Document store / NOSQL is now efficient! UPDATE t SET j = JSON_REPLACE(j, $[0].x.y[8], 7); JSON document Replicate only the modified part Huge saving for small changes in big documents modified part 50

51 8.0 Performance: Efficient JSON Replication Enable: SET GLOBAL binlog_row_image = MINIMAL, binlog_row_value_options = PARTIAL_JSON; JSON_SET, JSON_REPLACE, JSON_REMOVE And also composition: JSON_SET(JSON_REMOVE(...)) 51

52 Overview Background: (Group) Replication 8.0: Performance 8.0: Monitoring 8.0: Operations More! 52

53 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier A B C D machine machine A machine machine B machine machine C machine machine D 53

54 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier A B C D machine machine A machine machine B machine machine C machine machine D 54

55 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier A B C D machine machine A machine machine B machine machine C machine machine D 55

56 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 56

57 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs primary: SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP FROM performance_schema. replication_applier_status_by_worker HERE LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP = MAX(LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP) A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 57

58 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs last hop: SELECT LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP - LAST_APPLIED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_applier_status_by_worker HERE LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP = MAX(LAST_APPLIED_TRANSACTION_END_APPLY_TIMESTAMP) A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 58

59 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier These transactions latencies vs last hop: SELECT APPLYING_TRANSACTION_START_APPLY_TIMESTAMP APPLYING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_applier_status_by_worker A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 59

60 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs last hop: SELECT LAST_PROCESSED_TRANSACTION_END_BUFFER_TIMESTAMP LAST_PROCESSED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_applier_status_by_coordinator A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 60

61 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs last hop: SELECT PROCESSING_TRANSACTION_END_BUFFER_TIMESTAMP PROCESSING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_applier_status_by_coordinator A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 61

62 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs last hop: SELECT LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_connection_status A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 62

63 8.0 Monitoring: Lag Difference in states, measured in microseconds between commits, between: Replica and primary Hops in topology Stages of applier This transaction s latency vs last hop: SELECT QUEUEING_TRANSACTION_END_QUEUE_TIMESTAMP QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP FROM performance_schema. replication_connection_status A original machine machine commita timestamp machine machine B B C D immediate machine machine commit C timestamp machine machine D 63

64 8.0 Monitoring: Group Members ho are in this group? _uuid, host, port, MySQL version ho is the primary? Online status of each node mysql> SELECT FROM performance_schema.replication_group_members MEMBER_ID MEMBER_HOST MEMBER_PORT MEMBER_STATE MEMBER_ROLE MEMBER_VERSION <uuid-a> murkla 3306 ONLINE PRIMARY <uuid-b> kremla 3306 ONLINE SECONDARY <uuid-c> kantarell 3306 UNREACHABLE SECONDARY A B C New in

65 8.0 Monitoring: Group Member Statistics Statistics used to diagnose group members Conflict ratio of the group Conflict ratio of each member (multi-primary) Is any member falling behind on certification or applying? Table performance_schema.replication_group_member_stats: counts of transactions, by member: Positively/negatively certified transactions of any origin Positively/negatively certified transactions from the node Transactions waiting to be certified Certified transactions waiting to be applied 65

66 Overview Background: (Group) Replication 8.0: Performance 8.0: Monitoring 8.0: Operations More! 66

67 8.0 Operations: Multi-source Filters only users Users No filter Different filters on two channels Aggregate users bio groups Posts users posts comments --replicate-ignoretable=db.users users bio groups posts comments 67

68 8.0 Operations: Set Next Primary R R R R R R R R R A w=15 B w=10 C D w=25 w=20 SET group_replication_member_weight = [0-100] 68

69 8.0 Operations: Set Next Primary R R R R R R R R R A w=15 B w=10 C w=25 D w=20 SET group_replication_member_weight = [0-100] 69

70 8.0 Operations: Set Next Primary R R R R R R R R R??? B C D w=10 w=25 w=20 SET group_replication_member_weight = [0-100] 70

71 8.0 Operations: Set Next Primary R R R R R R R R R??? B C D w=10 w=25 w=20 25 is the biggest C is new primary SET group_replication_member_weight = [0-100] 71

72 8.0 Operations: Set Next Primary R R R R R R R R R B C D w=10 w=25 w=20 SET group_replication_member_weight = [0-100] 72

73 8.0 Operations: No rites After Leaving Group A B C D 73

74 8.0 Operations: No rites After Leaving Group Locally on A: STOP GROUP REPLICATION A B C D 1. Disallow new writes 2. ait for ongoing writes 3. Leave group 74

75 8.0 Operations: No rites After Leaving Group Locally on A: STOP GROUP REPLICATION A B C D 1. Disallow new writes 2. ait for ongoing writes 3. Leave group 75

76 8.0 Operations: No rites After Leaving Group Locally on A: STOP GROUP REPLICATION A B C D 1. Disallow new writes 2. ait for ongoing writes 3. Leave group 76

77 Overview Background: (Group) Replication 8.0: Performance 8.0: Monitoring 8.0: Operations More! 77

78 More! Global performance: Flow control tuning (throttle writes to sustain replicas) Usability: Better default configuration Monitoring: Monitor replication even when disk full Monitoring: Currently applying query, even for row-based replication Recoverability: Recover DDL after crash Interoperability: Metadata in binary log (full type information for DML) Interoperability: Transaction byte-length in binary log Operations: GTID support for restoring backup on non-empty Operations: Specify binary log file number after RESET MASTER Operations: Specify how long binary log files are kept, with second precision Operations: Group Replication support for SAVEPOINT Debugging: Group Replication: message bus logging Maintenance: Removed 4.x/5.0 compatibility code 78

79 Contributions! Thank you: Davi * 2 Daniel Daniël * 2 Laurynas * 5 Ovais Tsubasa * 2 Yura 79

80 I can t w8 to replic8 with version 8 Evalu8 Educ Contempl8 Cooper8 80

81 Thank You! & cu l8r, m8s 81

82 82 Copyright 2012, Oracle and/or its affiliates. All rights reserved.