Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability

3,047 views

Published on

Rene Cannao's Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability. Rene, a Senior Operational DBA at PalominoDB.com, will guide attendees through a hands-on experience in the installation, configuration management and tuning of MySQL Cluster.

Agenda:
- MySQL Cluster Concepts and Architecture: we will review the principle of a fault-tolerant shared nothing architecture, and how this is implemented into NDB;
- MySQL Cluster processes : attendees will understand the various roles and interactions between Data Nodes, API Nodes and Management Nodes;
- Installation : we will install a minimal HA solution with MySQL Cluster on 3 virtual machines;
- Configuration of a basic system : upon describing the most important configuration parameters, Data/API/Management nodes will be configured and the Cluster launched;
- Loading data: the "world" schema will be imported into NDB using "in memory" and "disk based" storages; the attendees will experience how data changes are visible across API Nodes;
- Understand the NDB Storage Engine : internal implementation details will be explained, like synchronous replication, transaction coordinator, heartbeat, communication, failure detection and handling, checkpoint, etc;
- Query and schema design : attendees will understand the execution plan of queries with NDB, how SQL and Data Nodes communicate, how indexes and partitions are implemented, condition pushdown, join pushdown, query cache;
- Management and Administration: the attendees will test High Availability of NDB when a node become unavailable will learn how to read log file, how to stop/start any component of the Cluster to perform a rolling restart with no downtime, and how to handle a degraded setup;
- Backup and Recovery: attendees will be driven through the procedure of using NDB-native online backup and restore, and how this differs from mysqldump;
- Monitor and improve performance: attendee will learn how to boost performance tweaking variables according to hardware configuration and application workload

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

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

No notes for slide

Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability

  1. 1. René CannaòSenior DBA PalominoDBrene@palominodb.com@rene_cannaoMySQL Cluster(NDB)Tutorial
  2. 2. AgendaIntroduction - PresentationMySQL Cluster OverviewMySQL Cluster ComponentsPartitioningInternal BlocksGeneral ConfigurationTransactionsCheckpoints on diskHandling failureDisk dataStart Types and Start PhasesStorage RequirementsBackupsNDB and binlogNative NDB Online Backups
  3. 3. About myselfMy name is René CannaòWorking as DBA since 2005Starting my experience with NDB in 2007In 2008 I joined the MySQL Support EngineerTeam at Sun/OracleWorking as Senior DBA for PalominoDBWe have a booth: please come and visit us!
  4. 4. QuestionsIf you have questions stop me at any time!If the answer is short will be answeredimmediately.If the answer it long, we can discuss at the endof the tutorial
  5. 5. What this course is NotThis course doesnt cover advanced topics like:Advanced SetupPerformance TuningConfiguration of multi-threadsOnline add nodesNDBAPInoSQL accessGeographic ReplicationBLOB/TEXT fields
  6. 6. MySQL Cluster Overview
  7. 7. MySQL Cluster OverviewHigh Availability Storage Engine for MySQLProvides:● High Availability● Clustering● Horizontal Scalability● Shared Nothing Architecture● SQL and noSQL access
  8. 8. High Availability and ClusteringHigh Availability:● survives routine failures or maintenance○ hardware or network failure, software upgrade, etc● provides continuous services● no interruption of servicesClustering:● parallel processing● increase availability
  9. 9. ScalabilityAbility to handle increased number of requestsVertical:● replace HW with more powerful oneHorizontal:● add component to the system
  10. 10. Shared Nothing ArchitectureCharacterized by:● No single point of failure● Redundancy● Automatic Failover
  11. 11. MySQL Cluster SummaryShared Nothing ArchitectureNo Single Point Of Failure (SPOF)Synchronous replication between nodesAutomatic failover with no data lossACID transactionDurability with NumberOfReplica > 1READ COMMITTED transaction isolation levelRow level locking
  12. 12. MySQL ClusterComponents
  13. 13. Components Overviewmysql client MySQL C APIPHP Connector/JNDB APINDBManagementClientsNDBManagementServersmysqld mysqld mysqldndbdndbd ndbdndbd
  14. 14. Cluster Nodes3 Node Types are present in a MySQL Cluster:● Management Node● Data Node● Access Node
  15. 15. Management Nodendb_mgmd processAdministrative tasks:● configure the Cluster● start / stop other nodes● run backup● monitoring● coordinator
  16. 16. Data Nodendbd process ( or ndbmtd )Stores cluster data● mainly in memory● also on disk ( limitations apply )Coordinate transactions
  17. 17. Data Node ( ndbmtd )What is ndbmtd ?Multi-threaded equivalent of ndbdFile system compatible with ndbdBy default run in single thread modeConfigured via MaxNoOfExecutionThreads ofThreadConfig
  18. 18. API NodeProcess able to access data stored in DataNodes:● mysqld process with NDBCLUSTER support● application that connects to the clusterthrough NDB API (without mysqld)
  19. 19. Partitioning
  20. 20. Vertical Partitioning
  21. 21. Horizontal Partitioning
  22. 22. Partitions example (1/2)5681 Alfred 30 2010-11-108675 Lisa 34 1971-01-125645 Mark 21 1982-01-020965 Josh 36 2009-06-335843 Allan 22 2007-04-121297 Albert 40 2000-12-201875 Anne 34 1984-11-229346 Mary 22 1983-08-058234 Isaac 20 1977-07-068839 Leonardo 28 1999-11-087760 Donna 37 1997-03-043301 Ted 33 2005-05-23Table
  23. 23. Partitions example (2/2)5681 Alfred 30 2010-11-108675 Lisa 34 1971-01-125645 Mark 21 1982-01-020965 Josh 36 2009-06-335843 Allan 22 2007-04-121297 Albert 40 2000-12-201875 Anne 34 1984-11-229346 Mary 22 1983-08-058234 Isaac 20 1977-07-068839 Leonardo 28 1999-11-087760 Donna 37 1997-03-043301 Ted 33 2005-05-23P1P2P3P4Table
  24. 24. Partitioning in MySQL ClusterMySQL Cluster natively supports PartitioningDistribute portions of individual tables indifferent locationsPARTITION BY (LINEAR) KEY is the onlypartitioning type supported
  25. 25. Partitions, Node Groups & ReplicasPartition:portion of the data stored in the clusterNode Groups:set of data nodes that stores a set of partitionsReplicas:copies of a cluster partition
  26. 26. Partitions in NDBP2P1 P3 P4NDB1 NDB2 NDB3 NDB4
  27. 27. Partitions and ReplicasP2PP1SP1PP2SP3PP4SP4PP3SNDB1 NDB2 NDB3 NDB4
  28. 28. Node GroupsP2PP1SP1PP2SP3PP4SP4PP3SNDB1 NDB2 NDB3 NDB4Node Group 0 Node Group 1
  29. 29. Node GroupsP2PP1SP1PP2SP3PP4SP4PP3SNDB1 NDB2 NDB3 NDB4Node Group 0 Node Group 1
  30. 30. Node GroupsP2PP1SP1PP2SP3PP4SP4PP3SNDB1 NDB2 NDB3 NDB4Node Group 0 Node Group 1
  31. 31. Internal Blocks
  32. 32. Blocks in Data Node (1/2)A data node is internally structured in severalblocks/code with different functions:● Transaction Coordinator (TC) :○ coordinates transactions○ starts Two Phase Commit○ distributes requests to LQH● Local Query Handler (LQH)○ allocates local operation records○ manages the Redo Log
  33. 33. Blocks in Data Node (2/2)● ACC○ stores hash indexes○ manages records locking● TUP○ stores row data● TUX○ stores ordered indexes● BACKUP , CMVMI , DICT , DIH , SUMA , etcRef:http://dev.mysql.com/doc/ndbapi/en/ndb-internals-ndb-protocol.html
  34. 34. Blocks on ndbd (simplified)
  35. 35. Blocks on ndbmtd (simplified)
  36. 36. Where is data stored?In memory!TUP TUXLQHTCACCIndexMemoryprimary keysunique keysDataMemorydata rowsordered indexes
  37. 37. General Configuration
  38. 38. Global parametersNoOfReplicas (mandatory)Defines the number of replicas for each partition/tableDataDir:Location for log/trace files and pid fileFileSystemPath:location for of all files related to MySQL Cluster
  39. 39. Global boolean parametersLockPagesInMainMemory (0) :Lock all memory in RAM ( no swap )StopOnError (1) :Automatic restart of data node in case of failure
  40. 40. IndexMemory and DataMemoryIndexMemory: defines the amount of memoryfor hashes indexes ( PK and UNIQUE )DataMemory: defines the amount of memoryfor:dataordered indexesUNDO information
  41. 41. Metadata ObjectsMaxNoOfTablesMaxNoOfOrderedIndexesMaxNoOfUniqueHashIndexes
  42. 42. Transactions
  43. 43. Transactions OverviewTwo Phase CommitACID● Durability with multiple copies● Committed on memoryREAD_COMMITTED
  44. 44. Transaction implementation● The API node contacts a TC in one of the Data Node(round-robin fashion, or Distribution Awareness)● The TC starts the transaction and the Two PhaseCommit (2PC) protocol● The TC contacts the LQH of the Data Nodes involved inthe transaction● LQH handles row level locking:○ Exclusive lock○ Shared lock○ No lock
  45. 45. Two Phase Commit (1/2)Phase 1 , Prepare :Node groups get their information updatedPhase 2 , Commit :the change is committed
  46. 46. Two Phase Commit (2/2)
  47. 47. Rows operationsPrimary key operation ( read and write )Unique index operation ( read )Ordered index scans ( read only )Full-table scans (read only)
  48. 48. Primary Key Write (1/4)● API node connects to TC● TC connects to LQH of the data node with the primaryfragment● LQH queries ACC to get the row id● LQH performs the operation on TUP● LQH connects to the LQH of the data node with thesecondary fragment● LQH on secondary performs the same operation● LQH on secondary informs TC that the prepare phase iscompleted● TC starts the commit phase
  49. 49. Primary Key Write (2/4)
  50. 50. Primary Key Write (3/4)
  51. 51. Primary Key Write (4/4)
  52. 52. Primary Key ReadWithout distribution awareness
  53. 53. Primary Key ReadWith distribution awareness
  54. 54. Unique Index Read (1/2)Unique Index is internally implemented as ahidden table with two columns where the PK isthe Unique Key itself and the second column isthe PK of the main table.To read a Unique index:● A PK read is performed on hidden table toget the value of the PK of main table● A PK read is performed on main table
  55. 55. Unique Index Read (2/2)
  56. 56. Full Table Scan
  57. 57. Ordered Index Scan
  58. 58. Transaction Parameters (1/3)MaxNoOfConcurrentTransactions: number ofsimultaneous transactions that can run in a node(maximum number of tables accessed in anysingle transaction + 1)* number of cluster SQL nodes
  59. 59. Transaction Parameters (2/3)MaxNoOfConcurrentOperations:Total number of records that at any time can beupdated or locked in data node, and UNDO.Beside the data node, TC needs informationabout all the records involved in a transactionMaxNoOfLocalOperations: for not too largetransactions, it defaults toMaxNoOfConcurrentOperationsx1.1
  60. 60. Transaction Parameters (3/3)MaxDMLOperationsPerTransactionLimits the number of DML operationsCount is in # of records, not # of statementsTransactionInactiveTimeoutIdle transactions are rolled backTransactionDeadlockDetectionTimeoutTime based deadlock and lock wait detectionAlso possible that the data node is dead or overloaded
  61. 61. Checkpoints on disk
  62. 62. CheckpointsMySQL Cluster is a in-memory storage engine:● data is only in memory? WRONG!● data is regularly saved on diskWhen a data node writes on disk is performinga checkpointException:MySQL Cluster can also run in DiskLess mode, with"reduced durability" and unable to run Native NDB Backup
  63. 63. Checkpoint typesLocal Checkpoint (LCP):● specific to a single node;● all data in memory is saved to disk● can take minutes or hoursGlobal Checkpoint (GCP):● transactions across nodes are synchronized● redo log flushed on disk
  64. 64. Memory and disk checkpointsCoordinatorDataMemoryIndexMemoryRedoBufferLCP0LCP1LCP0DataMemoryIndexMemoryRedoBufferLCP1RedoLog Files RedoLog FilesLCP LCPGCP GCP
  65. 65. Undo and Redo ParametersUndoIndexBuffer and UndoDataBufferBuffers used during local checkpoint to perform consistentsnapshot without blocking writes.RedoBufferIn memory buffer for REDO log (on disk)
  66. 66. Checkpointing parametersTimeBetweenLocalCheckpointsDoesnt define a time interval, but the amount of writesoperations ( as a base-2 logarithm of 4-byte words) .Examples:20 ( default ) means 4 x 220= 4MB24 means 4 x 224= 64MBTimeBetweenGlobalCheckpointsDefines how often commits are flushed to REDO logs
  67. 67. Fragment Log FilesNoOfFragmentLogFiles ( default 16 )FragmentLogFileSize ( default 16 MB )REDO logs are organized in a ring, where head and tailnever meet. If checkpointing is slow, updating transactionsare aborted. Total REDO logs size is defined as:NoOfFragmentLogFiles set of 4 FragmentLogFileSizeDefault : 16 x 4 x 16MB = 1024MBInitFragmentLogFiles : SPARSE or FULL
  68. 68. Checkpoint write controlODirect: (off) O_DIRECT for LCP and GCPCompressedLCP: (off) equivalent of gzip --fastDiskCheckpointSpeed: speed of localcheckpoints to disk ( default 10MB/s )DiskCheckpointSpeedInRestart : during restart
  69. 69. Diskless modeDiskless :It is possible to configure the whole Cluster torun without using the disk.When Diskless is enabled ( disabled by default ):● LCP and GCP are not performed;● NDB Native Backup is not possible;● a complete cluster failure ( or shutdown ) =data lost
  70. 70. Handling Failure
  71. 71. Data node failure (1/2)Failures happen!HW failure, network issue, OS crash, SW bug, …MySQL Cluster is constantly monitoring itselfEach data node periodically checks other data nodes viaheartbeatEach data node periodically checks API nodes viaheartbeat
  72. 72. Data node failure (2/2)If a node fails to respond to heartbeats, the data node thatdetects the failure communicates it to other data nodesThe data nodes stop using the failed node and switch to thesecondary node for the same fragment
  73. 73. Timeouts ParametersTimeBetweenWatchDogCheckThe watchdog thread checks if the main thread got stuckHeartbeatIntervalDbDbHeartbeat interval between data nodesHeartbeatIntervalDbApiHeartbeat interval between data nodes and API nodes
  74. 74. Disk Data
  75. 75. Available since MySQL 5.1.6Store non-indexed columns on diskDoesnt support variable sized storageOn disk : tablespaces and undo logsIn memory : page buffer ( cache )Disk Data
  76. 76. Objects:● Undo log files: store information to rollback transactions● Undo log group: a collection of undo log files● Data files: store MySQL Cluster Disk Data table data● Tablespace : a named collection of data filesNotes:● Each tablespace needs an undo log group assigned● currently, only one undo log group can exist in the sameMySQL ClusterDisk Data Objects
  77. 77. Disk Data - data flowDisk Page BufferTablespace 1 Tablespace 2 Undo Log GroupThreadIOPoolMetadataShared MemoryUndo BufferPagesRequestsQueues
  78. 78. Disk Data Configuration ParametersDiskPageBufferMemory : cache for disk pagesSharedGlobalMemory : shared memory for● DataDisk UNDO buffer● DiskData metadata ( tablespace / undo / files )● Buffers for disk operationsDiskIOThreadPool : number of threads for I/O
  79. 79. Using SQL statement:CREATE LOGFILE GROUP logfile_groupADD UNDOFILE undo_file[INITIAL_SIZE [=] initial_size][UNDO_BUFFER_SIZE [=] undo_buffer_size]ENGINE [=] engine_nameCreate Undo Log Group
  80. 80. UNDOFILE : filename on diskINITIAL_SIZE : 128MB by defaultUNDO_BUFFER_SIZE : 8MB by defaultENGINE : { NDB | NDBCLUSTER }Create Undo Log Group
  81. 81. ALTER LOGFILE GROUP logfile_groupADD UNDOFILE undo_file[INITIAL_SIZE [=] initial_size]ENGINE [=] engine_nameAlter Undo Log Group
  82. 82. CREATE LOGFILE GROUP lg1ADD UNDOFILE undo1.logINITIAL_SIZE = 134217728UNDO_BUFFER_SIZE = 8388608ENGINE = NDBCLUSTERALTER LOGFILE GROUP lg1ADD UNDOFILE undo2.logINITIAL_SIZE = 134217728ENGINE = NDBCLUSTERCreate Undo Log Group : example
  83. 83. In [NDBD] definition:InitialLogFileGroup = [name=name;][undo_buffer_size=size;] file-specification-listExample:InitialLogFileGroup = name=lg1;undo_buffer_size=8M; undo1.log:128M;undo2.log:128MCreate Undo Log Group
  84. 84. Using SQL statement:CREATE TABLESPACE tablespace_nameADD DATAFILE file_nameUSE LOGFILE GROUP logfile_group[INITIAL_SIZE [=] initial_size]ENGINE [=] engine_nameCreate Tablespace
  85. 85. logfile_group : mandatory! The log file group must bespecifiedDATAFILE : filename on diskINITIAL_SIZE : 128MB by defaultENGINE : { NDB | NDBCLUSTER }Create Tablespace
  86. 86. Using SQL statement:ALTER TABLESPACE tablespace_name{ADD|DROP} DATAFILE file_name[INITIAL_SIZE [=] size]ENGINE [=] engine_nameAlter Tablespace
  87. 87. CREATE TABLESPACE ts1ADD DATAFILE datafile1.dataUSE LOGFILE GROUP lg1INITIAL_SIZE = 67108864ENGINE = NDBCLUSTER;ALTER TABLESPACE ts1ADD DATAFILE datafile2.dataINITIAL_SIZE = 134217728ENGINE = NDBCLUSTER;Create Tablespace : example
  88. 88. In [NDBD] definition:InitialTablespace = [name=name;] [extent_size=size;]file-specification-listExample:InitialTablespace = name=ts1;datafile1.data:64M; datafile2.data:128MNote: no need to specify the Undo Log GroupCreate Tablespace
  89. 89. Start TypesandStart Phases
  90. 90. Start Types● (IS) Initial start● (S) System restart● (N) Node restart● (IN) Initial node restart
  91. 91. Initial start (IS)All the data nodes start with clean filesystem.During the very first start, or when all datanodes are started with --initialNote:Disk Data files are not removed from thefilesystem when data node is started with --initial
  92. 92. System restart (S)The whole Cluster is restarted after it has beenshutdown .The Cluster resumes operations from where itwas left before shutdown. No data is lost.
  93. 93. Node restart (N)The Node is restarted while the Cluster isrunning.This is necessary during upgrade/downgrade,changing configuration, performing HW/SWmaintenance, etc
  94. 94. Initial node restart (IN)Similar to node restart (the Cluster is running) ,but the data node is started with a cleanfilesystem.Use --initial to clean the filesystem .Note: --initial doesnt delete DiskData files
  95. 95. Start Phases ( 1/4 )Phase -1 : setup and initializationPhase 0 : filesystem initializationPhase 1 : communication inter-blocks andbetween nodes is initializedPhase 2 : status of all nodes is checkedPhase 3 : DBLQH and DBTC setupcommunication between them
  96. 96. Start Phases ( 2/4 )Phase 4:● IS or IN : Redo Log Files are created● S : reads schemas, reads data from lastLocal Checkpoint, reads and apply all theGlobal Checkpoints from Redo Log● N : find the tail of the Redo Log
  97. 97. Start Phases ( 3/4 )Phase 5 : for IS or S, a LCP is performed,followed by GCPPhase 6 : node groups are createdPhase 7 : arbitrator is selected, data nodes aremarked as Started, and API/SQL nodes canconnectPhase 8 : for S , all indexes are rebuiltPhase 9 : internal variables are reset
  98. 98. Start Phases ( 4/4 )Phase 100 : ( obsolete )Phase 101 :● data node takes responsibility for delivery itsprimary data to subscribers● for IS or S : transaction handlers is enabled● for N or IN : new node can act as TC
  99. 99. Storage requirements
  100. 100. In general, storage requirements for MySQLCluster is the same as storage requirements forother storage engines.But a lot of extra factors need to be consideredwhen calculating storage requirements forMySQL Cluster tables.Storage requirements
  101. 101. Each individual column is 4-byte aligned.CREATE TABLE ndb1 (id INT NOT NULL PRIMARY KEY,type_id TINYINT, status TINYINT,name BINARY(14),KEY idx_status ( status ), KEY idx_name ( name )) ENGINE = ndbcluster;Bytes used per row: 4+4+4+16 = 28 ( storage )4-byte alignment
  102. 102. If table definition allows NULL for some columns, MySQLCluster reserves 4 bytes for 32 nullable columns ( or 8bytes for 64 columns)CREATE TABLE ndb1 (id INT NOT NULL PRIMARY KEY,type_id TINYINT, status TINYINT,name BINARY(14),KEY idx_status ( status ), KEY idx_name ( name )) ENGINE = ndbcluster;Bytes used per row: 4 ( NULL ) + 28 ( storage )NULL values
  103. 103. Each record has a 16 bytes overheadEach ordered index has a 10 bytes overheadper recordEach page is 32KB , and each record must bestored in just one pageEach page has a 128 byte page overheadDataMemory overhead
  104. 104. Each primary/unique key requires 25 bytes forthe hash index plus the size of the field8 more bytes are required if the size of the fieldis larger than 32 bytesIndexMemory overhead
  105. 105. Storage requirement for test tableCREATE TABLE ndb1 (id INT NOT NULL PRIMARY KEY,type_id TINYINT, status TINYINT,name BINARY(14),KEY idx_status ( status ), KEY idx_name ( name )) ENGINE = ndbcluster;Memory used per row = ~107 bytes● 4 bytes for NULL values● 28 bytes for storage● 16 bytes for record overhead● 30 bytes for ordered indexes (3)● 29 bytes for primary key index ( 25 bytes + 4 bytes )plus all the wasted memory in page overhead/alignment
  106. 106. Hidden Primary KeyIn MySQL Cluster every table requires aprimary key.A hidden primary key is create if PK is notexplicitly definedThe hidden PK uses 31-35 bytes per record
  107. 107. Backups
  108. 108. Why backup?● Isnt MySQL Cluster fully redundant?● Human mistakes● Application bugs● Point in time recovery● Deploy of development/testing envs● Deploy a DR site● ... others
  109. 109. Backup methodologiesmysqldumpNative Online NDB Backup
  110. 110. Backup with mysqldumpstorage engine agnosticdumps other objects like triggers, view, SPconnects to any API node
  111. 111. Backup with mysqldump ( cont. )Usage:mysqldump [options] db_name [tbl_name ...]mysqldump [options] --databases db_name ...mysqldump [options] --all-databasesshell> mysqldump world > world.sqlQuestion: What about --single-transaction ?
  112. 112. Backup with mysqldump ( cont. )Bad news:No write traffic to MySQL Cluster○ SINGLE USER MODE○ reduced availability
  113. 113. Backup with mysqldump ( cont. )Check the content of the dump for:● CREATE TABLE● INSERT INTO● CREATE LOGFILE● CREATE TABLESPACE
  114. 114. Restore from mysqldumpStandard recovery procedure:shell> mysql -e "DROP DATABASE world;"shell> mysqladmin create worldshell> cat world.sql | mysql world
  115. 115. Restore from mysqldump ( cont. )Point in time recovery?● shell> mysqldump --master-data ...● apply binlog : from which API node?
  116. 116. NDB and binlog
  117. 117. MySQL Cluster Overview ( reminder )mysql client MySQL C APIPHP Connector/JNDB APINDBManagementClientsNDBManagementServersmysqld mysqld mysqldndbdndbd ndbdndbd
  118. 118. MySQL Cluster and binlogndbdndbd ndbdndbdmysqldNDB Engine binlogmysqldNDB Engine binlogmysqldNDB Engine binlog
  119. 119. NDB binlog injector threadWhen connecting to the data nodes,NDBCluster storage engine subscribes to allthe tables in the Cluster.When any data changes in the Cluster, theNDB binlog injection thread gets notified of thechange, and writes to the local binlog.binlog_format=ROW
  120. 120. Asynchronous Replication tostandard MySQL ( ex: InnoDB )ndbdndbd ndbdndbdmysqldNDB EnginebinlogmysqldNDB Enginebinlogmysqldasynchronousreplication
  121. 121. Asynchronous Replicationto MySQL Clusterndbdndbd ndbdndbdmysqldNDB EnginebinlogmysqldNDB Enginebinlogmysqldasynchronousreplicationndbdndbd ndbdndbdndbdndbd ndbdndbdNDB Engine
  122. 122. Native OnlineNDB Backups
  123. 123. Native Online NDB BackupHot backupConsistent backupInitialized by a cluster management node
  124. 124. NDB Backup FilesThree main components:● Metadata : BACKUP-backup_id.node_id.ctl● Table records : BACKUP-backup_id-0.node_id.datadifferent nodes save different fragments during thebackup● Transactional log : BACKUP-backup_id-0.node_id.logdifferent nodes save different logs because they storedifferent fragmentsSaved on all data nodes: each data node performs thebackup of its own fragment
  125. 125. START BACKUPshell> ndb_mgmndb_mgm> START BACKUPWaiting for completed, this may take several minutesNode 1: Backup 4 started from node 12Node 1: Backup 4 started from node 12 completedStartGCP: 218537 StopGCP: 218575#Records: 2717875 #LogRecords: 167Data: 1698871988 bytes Log: 99056 bytes
  126. 126. START BACKUP (cont.)Waiting for completed, this may take several minutesNode Did: Backup Bid started from node MidNode Did: Backup Bid started from node Mid completedStartGCP: 218537 StopGCP: 218575#Records: 2717875 #LogRecords: 167Data: 1698871988 bytes Log: 99056 bytesDid : data node coordinating the backupBid : unique identifier for the current backupMid : management node that started the backupNumber of Global Checkpoints executed during backupNumber and size of records in backupNumber and size of records in log
  127. 127. START BACKUP (cont.)START BACKUP options:● NOWAIT● WAIT STARTED● WAIT COMPLETED ( default )
  128. 128. Backup ParametersBackupDataBufferSize:stores data before is written to diskBackupLogBufferSize:buffers log records before are written to diskBackupMemory:BackupDataBufferSize + BackupLogBufferSize
  129. 129. Backup Parameters (cont.)BackupWriteSize:default size of messages written to disk frombackup buffers ( data and log )BackupMaxWriteSize:maximum size of messages written to diskCompressedBackup:equivalent to gzip --fast
  130. 130. Restore from Online backupndb_restore: program that performs the restoreProcedure:● import the metadata from just one node● import the data from each node
  131. 131. ndb_restoreImportant options:-c string : specify the connect string-m : restore metadata-r : restore data-b # : backup ID-n # : node ID-p # : restore in parallel--no-binlog
  132. 132. ndb_restore (cont.)--include-databases = db_lists--exclude-databases = db_lists--include-tables = table_lists--exclude-tables = table_lists--rewrite-database = olddb,newdb... and more!
  133. 133. Q & A

×