Новые возможности репликации MySQL 5.6

1,516 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,516
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Новые возможности репликации MySQL 5.6

  1. 1. Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 121Новые возможностирепликации MySQL 5.6Konstantin OsipovА также:Luís SoaresSven SandbergMoscowMySQL User Group
  2. 2. 2Содержание История репликации в MySQL Причины введения GTID Устройство и использование GTID Практика повышения отказоустойчивости
  3. 3. 3Введение MySQL Master сервер– Изменяет данные– Логирует изменения (Events) в файл (Binary Log) MySQL Slave сервер– Получает изменения с мастера– Проигрывает изменения на данных slave serverаКомпоненты репликации в MySQL
  4. 4. 4Введение The Binary Log– File based log that records the changes on the master.– Statement or Row based format (may be intermixed).– Split into transactional groups.BEGIN ...Ev1 Ev2 COMMITMySQL Replication Components: Binary LogBinary Log FileBinary Log FileBEGIN ...Ev1 Ev2 COMMITEvent Layout ona Binary Log File
  5. 5. 5ВведениеMySQL Replication Components: Binary LogBinary LogBinarylogfilesIndexUnder the HoodBinary log files: mysql-bin.000001, mysql-bin.000002, …- данные, events.Index: mysql-bin.index- Индекс по бинлогу – для быстрого поиска поLog coordinate:- binlog file name + event offset in the file (3.23.15+)- Global Transaction Identifiers (5.6+)
  6. 6. 6Session DumpBinary logI/O SQLRelay logSlaveMasterSessionSessionАрхитектура репликации в MySQLMySQL Replication ArchitectureMasterinfoRelayloginfo I/O и SQL Thread Replication Metadata хранится в файлах. В MySQL 5.6 метаданные могут храниться в InnoDB.
  7. 7. 7Background Asynchronous Replication (MySQL 3.23.15+)– Transactions are committed and externalized without interaction withthe replication layer.– Events are propagated after the commit operation is acknowledged.– Faster but vulnerable to lost updates on server crashes andinconsistency.– Built into the server. Semi-synchronous Replication (MySQL 5.5+)– Master commits transaction but waits until one slave acknowledgeshaving received and stored the event before replying to the client.Changes Propagation
  8. 8. 8Scaling OutReadsВведениеMasterSlaveMySQL Replication Use CasesMasterSlaveClientSlaveSlaveWritesReadsMasterRelaySlave NOne Master,One SlaveRelaySlave
  9. 9. 9GTID: мотивацияMotivation: Seamless Failover Сервера иногда крэшатся (сбой оборудования, баг, метеорит...) Slave должен быть “повышен” в мастера (promotion) Способ индексации событий в бинлоге является КЛЮЧЕВЫМ!– MySQL 3.23+: FILENAME+OFFSET●Локален для сервера, абсолютен– MySQL 5.6+: TRANSACTION IDENTIFIERS●Глобальный, логический id, генерируется автоматически
  10. 10. 10GTID: внутреннее устройствоGlobal Transaction Identifiers Generate a global transaction identifier on commit:– server_uuid:numbera61678ba­4889­4279­9e58­45ba840af334:1– server_uuid identifies the server; globally unique– number is incremented by 1 for each transaction on this server
  11. 11. 11A(master)B(slave)C(slave)GTID: автоматический failoverMotivation: Seamless Failover Процедура failover при выходе из строя мастера Пример 1: иерархия
  12. 12. 12A(master)B(slave)C(slave)Crash!GTID: автоматический failoverMotivation: Seamless Failover Enable fail-over if master crashes Пример 1: иерархия
  13. 13. 13A(crashed)BCGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия
  14. 14. 14A(crashed)B(new master)C(slave)fail-overGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия
  15. 15. 15A(master)B(masterand slave)C(slave)GTID: автоматический fail-overMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка
  16. 16. 16A(master)B(masterand slave)C(slave)Crash!GTID: автоматический failoverMotivation: Seamless Failover Enable fail-over if master crashes Пример 1: иерархия Пример 2: цепочка
  17. 17. 17A B(crashed)CGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка
  18. 18. 18A(new master)B(crashed)C(slave)fail-overGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка
  19. 19. 19B CA DGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка Пример 3: кольцо
  20. 20. 20B CA DCrash!GTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка Пример 3: кольцо
  21. 21. 21B CA DGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка Пример 3: кольцо
  22. 22. 22B CA Dfail-overGTID: автоматический failoverMotivation: Seamless FailoverПроцедура failover при выходе из строя мастера Пример 1: иерархия Пример 2: цепочка Пример 3: кольцо
  23. 23. 23GTID: автоматический failoverMotivation: Seamless FailoverABCDEF Enable fail-over if master crashes Пример 1: иерархия Пример 2: цепочка Пример 3: кольцо Пример 4: произвольнаятопология
  24. 24. 24GTID и binlogGlobal Transaction Identifiers global transaction identifier создаётся в момент commitа:– server_uuid:numbera61678ba­4889­4279­9e58­45ba840af334:1– server_uuid identifies the server; globally unique– number is incremented by 1 for each transaction on this server Write GTID to binary logGTID BEGIN ...Ev1 Ev2 COMMITTransaction 1GTID BEGIN ...Ev1 Ev2 COMMITTransaction 2
  25. 25. 25Global Transaction IdentifiersGlobal Transaction Identifiers Generate a global transaction identifier on commit:– server_uuid:numbera61678ba­4889­4279­9e58­45ba840af334:1– server_uuid identifies the server; globally unique– number is incremented by 1 for each transaction on this server Write GTID to binary log Preserve GTID when slave re-executes transaction
  26. 26. 26GTID: новый протокол репликацииNew protocol– Реплика посылает мастеру:диапазон транзакций, которые были выполнены на реплике– Мастер посылает реплике все остальные транзакции(slave)id1,trx1,id2,trx2(master)id1,trx1,id2,trx2,id3,trx3binlogA 2. id3, trx3, …1. id1…id2binlogB
  27. 27. 27GTID: новый протокол репликацииNew protocol used in failover Пример 1: иерархияA(crashed)(master)Aid1,trx1,id2,trx2,id3,trx3binlog(slave)Cid1,trx1binlogCrash! (slave)id1,trx1,id2,trx2Bbinlog
  28. 28. 28GTID: новый протокол репликацииNew protocol used in failover Пример 1: иерархия(slave)id1,trx1,id2,trx2BbinlogA(crashed)(master)Aid1,trx1,id2,trx2,id3,trx3binlog(slave)Cid1,trx1binlog
  29. 29. 29GTID: новый протокол репликацииNew protocol used in failover Пример 1: иерархияA(crashed)(crashed)Aid1,trx1,id2,trx2,id3,trx3binlogCid1,trx1binlogid1,trx1,id2,trx2Bbinlog
  30. 30. 30GTID: новый протокол репликацииNew protocol used in failover Пример 1: иерархия(new master)id1,trx1,id2,trx2BbinlogA(crashed)(crashed)Aid1,trx1,id2,trx2,id3,trx3binlog(slave)id1id2, trx2,...Cid1,trx1binlog
  31. 31. 31GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоBbinlogAbinlogCbinlogclient client
  32. 32. 32GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1BbinlogAbinlogCbinlogclient client trx1
  33. 33. 33GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1,id2,trx2Bbinlogid2,trx2AbinlogCbinlogclient clienttrx2 trx1
  34. 34. 34GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1,id2,trx2,id3,trx3Bbinlogid2,trx2AbinlogCbinlogclient clienttrx2 trx1, trx3
  35. 35. 35GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1,id2,trx2,id3,trx3Bbinlogid2,trx2AbinlogCbinlogclient clienttrx2 trx1, trx3Crash!
  36. 36. 36GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1,id2,trx2,id3,trx3Bbinlogid2,trx2AbinlogCbinlogclient clienttrx2 trx1, trx3
  37. 37. 37GTID: новый протокол репликацииNew protocol Пример 1: иерархия Пример 2: кольцоid1,trx1,id2,trx2,id3,trx3Bbinlogid2,trx2AbinlogCbinlogclient clienttrx2 trx1, trx3id2id1,trx1,id3,trx3,...
  38. 38. 38GTID: новый синтаксис CHANGE MASTERHow to use: New syntaxA(crashed)B(new master)C(slave)server_C> CHANGE MASTER TO MASTER_HOST = server_B,                           MASTER_AUTO_POSITION = 1;new syntaxfail-over
  39. 39. 39GTID: новый синтаксис CHANGE MASTERHow to use: New syntaxA(new master)B(crashed)C(slave)fail-over new syntaxserver_C> CHANGE MASTER TO MASTER_HOST = server_A,                           MASTER_AUTO_POSITION = 1;
  40. 40. 40GTID: мониторингMonitoring: gtid_donemaster> CREATE TABLE t1 (a INT);
  41. 41. 41GTID: мониторингMonitoring: gtid_donemaster> CREATE TABLE t1 (a INT);master> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1New variable:gtid_done
  42. 42. 42GTID: мониторингMonitoring: gtid_donemaster> CREATE TABLE t1 (a INT);master> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1master> INSERT INTO t1 VALUES (1);master> INSERT INTO t1 VALUES (2);New variable:gtid_done
  43. 43. 43GTID: мониторингMonitoring: gtid_donemaster> CREATE TABLE t1 (a INT);master> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1master> INSERT INTO t1 VALUES (1);master> INSERT INTO t1 VALUES (2);master> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1­3Note: intervalNew variable:gtid_done
  44. 44. 44GTID: мониторингMonitoring: gtid_donemaster> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1­10000 slave> SELECT @@global.gtid_done;a61678ba­4889­4279­9e58­45ba840af334:1­9999
  45. 45. 45GTID: итогиSummary Purpose: Fail-over (or change topology – crash not required) Basic usage is simple– CHANGE MASTER TO MASTER_AUTO_POSITION = 1– Failover has very small admin overhead Basic monitoring is simple– SELECT @@global.gtid_done
  46. 46. 46Автоматический failoverMySQL Utilities A collection of Python utilities for managing MySQL databases MySQL Workbench Plugin Available under the GPLv2 license Library to grow solutions for common administrative problems Download MySQL Workbench from:– http://www.mysql.com/downloads/workbench/ You can also download the latest development source code иерархия forthe MySQL Workbench Utilities from:– http://launchpad/net/mysql-utilities
  47. 47. 47Automatic Fail-OverMySQL Utilities Easily administer MySQL servers from the command цепочка– mysqldbcompare – compare databases– mysqldbcopy – copy databases between servers– mysqlfailover – Automatic fail-over– mysqlrpladmin – General replication administration utility– mysqlrplshow – show a graph of your topology– mysqlreplicate – setup replication– mysqlrplcheck – check replication configuration– ... Build your own tools on top of the core of the library, e.g., automate timeshare multi-sourcereplication setup or failing-over to a slave
  48. 48. 48 Check and report health at specific intervals in seconds. Automatic fail-over.Automatic Fail-Overmysqlfailover
  49. 49. 49 General replication administration utility: start, stop, topology health,elect, failover, switchover, gtid. On-demand failover or switchover.Automatic Fail-Overmysqlrpladmin
  50. 50. 50Enhanced Reliability --binlog-checksum = CRC32 | NONE– Turns on/off generation of CRCs on the master.– SET @@global.binlog_checksum●--master-verify-checksum=0 | 1– Dump thread and user sessions verify checksums.– SET @@global.master_verify_checksum●--slave-sql-verify-checksum=0 | 1– SQL thread verifies checksums.– SET @@global.slave_sql_verify_checksumsUser Interface for Controlling CRC.
  51. 51. 51Self-healing Slaves Backward compatible: one can still use files if one wants:– --master-info-repository= FILE | TABLE– --relay-log-info-repository= FILE | TABLE Tables are located in the mysql schema and are InnoDB by default.– mysql.slave_relay_log_info– mysql.slave_master_info Tables engine can be altered, e.g.:– ALTER TABLE mysql.slave_master_info ENGINE = ...;Hands-on
  52. 52. 52Self-healing Slaves slave_relay_log_info is updated after each relay log rotation, whenthe SQL thread is stopped, after a commit or rollback, after astatement executed without transactional context.– DDLs in mysql are not transactional, thus the table is updatedafter the event is processed.– --sync-relay-log-info has no effect on tables.Hands-on
  53. 53. 53Self-healing Slaves slave_master_info is updated when the relay log is rotated,CHANGE MASTER is executed, on STOP|START SLAVEIO_THREAD and when sync-master-info period has elapsed.– --sync-master-info = 0●updates only on the cases mentioned.●together with –relay-log-recovery=1 should providesufficient fault-tolerance.– --sync-master-info = N (N >0)●comes with a penalty, but table is updated more often.Hands-on
  54. 54. Copyright © 2012, Oracle and/or its affiliates. All rights reserved.54Summary MySQL 5.6 is the Foundation for building rock solid highly availableservices infrastructures. High Availability features: Global Transaction Identifiers, Crash-safeSlaves, Crash-safe Binary logs. Flexibility and usability enhancements. Reduced administration overhead. MySQL Utilities already provide automatic fail-over capabilities, off-loading the DBA.

×