<Insert Picture Here>
MySQL Cluster
Wagner Bianchi – LAD
Senior Principal Consulting
Disclaimer
The preceding 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.
Technology Specifications
• Virtualization with Oracle VM VirtualBox;
• MySQL Cluster 7.1.13.
NodeType MachineName IP
Management node1 192.168.0.101
Management node2 192.168.0.102
Data/Storage node3 192.168.0.103
Data/Storage node4 192.168.0.104
Data/Storage node5 192.168.0.105
Data/Storage node6 192.168.0.106
SQL/API node7 192.168.0.107
SQL/API node8 192.168.0.108
SQL/API node9 192.168.0.109
SQL/API node10 192.168.0.110
Agenda
• Cluster’s components;• Management Node• SQL/API Node• Data/Storage Node
• Configurations File;• Local• Global• Connect String
• Cluster Partitioning• Partitions• Fragments
• Disk Tables• In-Memory Tables
• Replication• Synchronous• Assynchronous• Replication Channels;
• Backup & Restore• Native Backup• Native Restore• mysqldump
• Performance Tuning• Condition Pushdown• Iptraf
- Part I - Part II
Management Node
• Management Node have processes that make possible
to manager the entire cluster at a high-level;
• There are two programs involved in the management of
the MySQL Cluster:
• ndb_mgm: this is a command-line tool or client used for
interacting with the cluster management daemon;
• ndb_mgmd: this is the daemon responsible for exchanging
status and other messages with cluster;
Management Node
• Management Node is used by a client to make possible online interactions with all cluster nodes such as starts, restarts, check consumed resources, check cluster logs and et cetera;
• Operations of native and online backup is done via management client, issuing the command START BACKUP, e.g.:
# executing na online native backup
shell> ndb_mgm –e “START BACKUP”
Management Node
• We can check a data node's used or consumed resources:
• Command ALL is used to report the actual node’s status and consumed resources. To check ALL STATUS, issue:
# executing na online native backup
shell> ndb_mgm –e “ALL REPORT memoryusage”
# checking data node’s status
shell> ndb_mgm –e “ALL STATUS”
Management Node
• When a local data node's files are used and the option “nostart” is mentioned in these files, you’ll be required to start data nodes manually, using ndb_mgm as:
• You can START or RESTART a node, issuing mentioned statement, preceding by the node ID. Observing that it will work only for data nodes, not for SQL/API nodes;
# start or restarting data nodes after its execution
shell> ndb_mgm –e “4 [ START | RESTART ]”
Management Node
• Important to note that at the first ndb_mgmd start, it will create a directory to store all cluster’s configuration cache files at /usr/mysql-cluster;
• To restart ndb_mgmd overwriting cache files, the following options can be used on command line (./ndb_mgmd):
• --initial• --skip-config-cache• or removing cache files with:
• rm –f /usr/mysql-cluster/*
Management Node
• Downloading and installing mgm node packages:
# creating directories -> BASEDIR and DATADIR
[ root@node1 ~ ] mkdir -p /usr/local/mysql-cluster[ root@node1 ~ ] mkdir -p /var/lib/mysql-cluster[ root@node1 ~ ] cd /usr/local/mysql-cluster
# downloading management node necessary packages
[ root@node1 ~ ] wget http://downloads.mysql...management.rpm
[ root@node1 ~ ] wget http://downloads.mysql...tools.rpm
# installing necessary packages
[ root@node1 mysql-cluster ] rpm -ivh MySQL-* Preparing... ############################################ [100%]1:MySQL-Cluster-gpl-management ########################### [100%]2:MySQL-Cluster-gpl-tools ################################ [100%]
Management Node
• Before to start ndb_mgmd, be sure that a configuration file, normally named config.ini has been created – you will be required to point this file using one of these options below:
• Or the short form:
# command-line management daemon execution
shell> ndb_mgmd --config-file=/path/to/file
# using short form to state cluster’s config file
shell> ndb_mgmd –f /path/to/file
Management Node
• You can verify that the management server process is running by viewing the output of a system command such this one:
• Now we can use ndb_mgm, the management client to retrieve information about the cluster using SHOW command:
[ root@node1 ]# ps aux | grep ndb_mgmd
root 103467 17.3 0.7 8398 2564 ? Ssl 3:20 3:55
ndb_mgmd –f /usr/local/mysql-cluster/config.ini
# SHOW command retrieves information about cluster
[ root@node1 ]# ndb_mgm –e “ SHOW”
Data/Storage Node
• The Data or Storage Node, which is implemented as ndbd or ndbmtd, handles data storage and retrieval for a specific subset of the cluster’s data;
• Usually a Data Node is part of a larger group of data nodes in a cluster that work together to handle data;
• The specific purpose of Data or Storage Nodes is simply to process and retrieve information, being the storage for the whole cluster;
Data/Storage Node
• The data node’s tasks include, but are not limited to, the following:• Storing and retrieving index and records data from memory
and disk (whenever uses disk storage tables);• Injecting data into the binary logs for external replication;• Participating in distributed transactions;• Monitoring other nodes in the cluster and notifying the
management server of any node failures;• Writing tables data to disk at checkpoints and performing
recovery on restart;• Sending information to and processing requests from the
management server;
Data/Storage Node
Data/Storage Node
• Data nodes store database tables and indexes in memory and conduct a significant portion of the SQL query processing of a working cluster;
• The single-threaded storage node process is called ndbd and either this or the multi-threaded version, ndbmtd must be installed and executed on each storage node;
• Necessary packages:• MySQL-Cluster-gpl-tools.rhel5.rpm• MySQL-Cluster-gpl-storage.rhel5.rpm
This is the same idea of multi-threaded
replication applied on slave server when
using MySQL 5.6 (milestone yet!!)
This is the same idea of multi-threaded
replication applied on slave server when
using MySQL 5.6 (milestone yet!!)
SQL/API Node
• The SQL Node, which runs as the mysqld program, provides application access to the cluster, receives all external interactions as queries and mysqldump backups;
• Necessary packages to install:
• MySQL-Cluster-gpl-server-7.1.13.rhel5.i386.rpm• MySQL-Cluster-client-7.1.13.rhel5.i386.rpm• MySQL-Cluster-shared-7.1.13.rhel5.i386.rpm
A good strategy for packages…
• Download all of the necessary installation pacakages for Cluster onto the Management Node and then later send them to the appropriate nodes:
Configuration Files
Configuration File
• To operate, the nodes that make up a MySQL Cluster, information about the cluster environment is needed and cluster's configuration file provides this;
• Configuration files can be used to set nearly all of parameters available, although a set of these parameters even can be used on the command line;
• A MySQL Cluster relies on two types of configuration files:• Local configuration file, residing on each node;• Global configuration file, kept on Management Node;
Local Configuration File
• Each data or API Node in a particular cluster needs to know how to connect to the cluster Management Node(s) – another way to provide necessary information is to use local configuration file;
• These types of files follow similar conventions to my.cnf, are located in the same place and have the same structure;
[ndbd] # local ndbd’s configuration file - /etc/my.cnf
ndb-connectstring=192.168.0.101:1186,192.168.0.102:1186
NoStart # ndbd do not start after be invoked
Global Configuration File
• The global configuration file is a central one that resides on one or more Management Node servers, and which provides information about the cluster as a whole
• Specific types of nodes can be configured globally within the sections of this file, e.g., [ndbd default];
• This file, commonly created as config.ini, is used by the Management Node to start cluster, receive nodes’ connections and start cluster’s operations;
Global Configuration File [ndb_mgmd]
NodeId=1
HostName=192.168.0.101
[ndbd default]
NoOfReplicas=2
DataDir=/var/lib/mysql-cluster
StopOnError=false # angel will restart failed nodes
[ndbd]
NodeId=2
HostName=192.168.0.102
[ndbd]
NodeId=3
HostName=192.168.0.103
[mysqld]
NodeIde=4
HostName=192.168.0.104
[mysqld]
# free reserved slot – e.g. ndb_restore, the native cli for database restore
The Cluster Connectstring
• One of the most important settings in the local configuration file is the cluster connectstring the provides connections between nodes;
• This parameter is referenced in any of the three ways, depending on the node that is using it:
• ndb-connectstring: Data Nodes & SQL Nodes;• connect-string: Data Nodes only;• connectstring: SQL Node only;
Cluster Partitioning
Cluster Partitioning
• A partition in simples terms is a portion or a set of table rows divided as a horizontal partition – in contrast we are familiar with the concept of vertical partition that divides tables by columns (this isn't supported by MySQL at this time);
• MySQL Cluster has an internal algorithm that will automatically implement a partitioning that will roughly have the same amount of table rows;
• This is done evenly balance the memory requirements that the ndbd/ndbmtd process make across all data nodes.
Cluster Partitioning
• It is also possible to specify the partitioning manually for NDB tables using PARTITION BY KEY and PARTITION BY LINEAR in a CREATE TABLE or ALTER TABLE;
• The number of cluster partitions is always equal to the number of data nodes in each of the cluster’s node groups – each node group must have the same number of nodes!
• The cluster can also, and usually does) store multiple copies of each partition among the data nodes – these copies are referred to as fragments;
Cluster Partitioning
Cluster Partitioning
• Partition P1 is stored on node group 0 – a primary replica (fragment) is stored on data node 1, and a secondary replica (backup of the fragment) is stored on data node 2;
• Partition P2 is stored on the cluster’s other node group (node group 1). This partition’s primary replica is on data node 3, and its backup is on the data node 4;
• Partition P3 is stored on node group 0. However, the placing of its two replicas is reserved from that of P1; for P3, the primary replica is stored on data node 2, and the backup on data node 3;
• Partition P4 is stored on node group 1, and the place of its two replicas is reserved from that of P2 – that is, this partition’s primary replica is located on data node 4, with the backup replica on data node 3.
Cluster Partitioning
Cluster Partitioning
• Even trusting in MySQL Cluster’s algorithms, it is a good practice to review automatically created partitions in order to improve databases’ responses;
• If MySQL Cluster package "tools" is installed, ndb_desc will be available and can be used with the “-p" flag:#some columns were omitted from the final result to better accommodate it
-- Per partition info –
Partition Row count Commit count Frag fixed memory Frag varsized memory
2 2 2 65536 327680 1 2 2 65536 327680 3
NDBT_ProgramExit: 0 - OK
Cluster Partitioning
• It is good practice following recovery from a MySQL Cluster backup to REORGANIZE PARTITIONS in order to force the algorithm to review what was done:
• In the case that a database has too many tables, use to combine INFORMATION_SCHEMA.TABLES columns and CONCAT() function in order to produce a ALTER TABLE for each database table;
# alter partitions in order to adjust and better accommodate data
# among all partitions, fragments and data nodes
mysql> ALTER ONLINE TABLE world.City
-> REORGANIZE PARTITION;
Query OK, 0 rows affected (1.52 sec)
Disk-based and In-memory Tables
Disk-based Tables
• To configure disk-based tables, data nodes should have spare space on a high-performance block device, e.g. 15k storage disks, SSD based disks, SCSI and et cetera;
• A set of two file types must be created on data nodes in order to accommodate data and logs on disk in manner that NDB Storage Engine can understand;
• TABLESPACES: disk-based tables stores their data in structures like this which made up of one or more files;
• LOGFILE GROUP: disk-based tables stores their “ndb” data in a logfile group made up of one or more UNDO logfiles. (TC)
Disk-based Tables
• First of all, create LOGFILE GROUP and an UNDOFILE;
• After that, create the TABLESPACE file that will use LOGFILE GROUP previously created;
Disk-based Tables
• A good test is to download world test database from the MySQL website, create database world into MySQL Cluster through the SQL, a LOGFILE GROUP, a TABLESPACE and finally, restore database from bkp file;
• You must remember that, even a table that has been set up on disk will have its indexes kept in memory…
# creating database world
mysql> CREATE DATABASE world;
Query OK, 0 rows affected (1.52 sec)
# creating logfile group world_log
mysql> CREATE LOGFILE GROUP world_log ADD UNDOFILE ‘world_log.dat’
-> UNDO_BUFFER_SIZE=16M INITIAL_SIZE=200M ENGINE=NDB;
Query OK, 0 rows affected (2.23 sec)
# creating tablespace world_tbs, where will reside table`s data
mysql> CREATE TABLESPACE world_tbs ADD DATAFILE ‘world_tbs.dat’
-> USE LOGFILE GROUP world_log INITIAL_SIZE=500M ENGINE=NDB;
Query OK, 0 rows affected (1.09 sec)
# restoring world database from world.sql file
shell> cat world.sql | sed –e ‘s/ENGINE=MyISAM/STORAGE DISK TABLESPACE world_tbs ENGINE = NDB/g’ | mysql world
Disk-based Tables
Disk-based Tables
• After those processes, it will be easier to check or confirm if tables are residing on right tablespace, using the right logfile group and they are controlled by NDB Cluster Storage Engine;
• By completing these tests and using the other client programs it will then be possible to build the entire MySQL Cluster;
# on data node (node3) I used ndb_show_tables filtering results
shell> ndb_show_tables –c 192.168.1.101 –d world | grep Tablespace
9 Tablespace Online - world_tbs
Disk-based Tables
• As you saw on the last command list we created LOGFILE GROUP with world_log name, TABLESPACE file with world_tbs name and used STORAGE DISK statement on CREATE TABLE;
• Linux command sed with flag “-e” was used to replace the string “ENGINE=MyISAM” by “STORAGE DISK ENGINE=NDB”;
Disk Storage Metadata
• The FILES table in INFORMATION_SCHEMA database contains information about files related to disk based storage – this is an extension of defaults metadata dictionary;
• Each row in the INFORMATION_SCHEMA.FILES table corresponds either to a data file or to an undo file, with exception of an additional row for log file groups, since free space is reported per group, not per undofile;
Disk Storage Metadata
• Am I running out of space?
# creating a simple view to check that main question
CREATE VIEW check_space AS
SELECT
FILE_NAME,
((TOTAL_EXTENTS * EXTENT_SIZE)/(1024 * 1024)) AS ‘Total MB’,
((FREE_EXTENTS * EXTENT_SIZE)/(1024*1024)) AS ‘Free MB’,
(
((FREE_EXTENTS * EXTENT_SIZE)*100)
/(TOTAL_EXTENTS * EXTENT_SIZE)
) AS ‘% Free’,
EXTRA
FROM INFORMATION_SCHEMA.FILES
WHERE ENGINE = ‘NDBCLUSTER’ AND FILE_TYPE = ‘DATAFILE’;
Disk Storage Metadata
• Now, I just need analyze results below and add more datafiles or resize those that already exist;
# results returned after the query’s execution
mysql> select * from check_space;
+---------------+----------+----------+---------+----------------+
| FILE_NAME | Total MB | Free MB | % Free | EXTRA |
+---------------+----------+----------+---------+----------------+
| world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=3 |
| world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=4 |
| world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=5 |
| world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=6 |
+---------------+----------+----------+---------+----------------+
4 rows in set (0.11 sec)
Disk Storage Metadata• Adding new datafile to TABLESPACE world_tbs:
• Executing our created view again:
# results returned after the query’s execution
mysql> ALTER TABLESPACE world_tbs
-> ADD DATAFILE ‘world_tbs-1.dat’ ENGINE=NDB;
Query OK, 0 rows affected (4.11 sec)
# results returned after the query’s execution mysql> select * from check_space;
+-----------------+----------+----------+----------+-----------------+| FILE_NAME | Total MB | Free MB | % Free | EXTRA |+-----------------+----------+----------+----------+----------------+| world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=3 || world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=4 || world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=5 || world_tbs.dat | 500.0000 | 494.0000 | 98.8000 | CLUSTER_NODE=6 || world_tbs-1.dat | 100.0000 | 100.0000 | 100.0000 | CLUSTER_NODE=3 || world_tbs-1.dat | 100.0000 | 100.0000 | 100.0000 | CLUSTER_NODE=4 || world_tbs-1.dat | 100.0000 | 100.0000 | 100.0000 | CLUSTER_NODE=5 || world_tbs-1.dat | 100.0000 | 100.0000 | 100.0000 | CLUSTER_NODE=6 |+-----------------+----------+----------+----------+----------------+8 rows in set (0.08 sec)
Disk Storage Metadata
• To DROP TABLESPACE world_tbs, you must drop LOGFILE GROUP world_log first, so that no errors are thrown by MySQL:
# trying to remove a tbs without remove logfile group used
mysql> DROP TABLESPACE world_tbs ENGINE=NDB;
ERROR 1529 (HY000): Failed to drop TABLESPACE
mysql> SHOW WARNINGS;
+-----------------------------------------------------------------+
Error | 1296 | Got error 768 'Cant drop filegroup, filegroup is used' from NDB |
Error | 1529 | Failed to drop TABLESPACE
+-----------------------------------------------------------------+
2 rows in set (0.01 sec)
Disk Storage Metadata
• It is possible to run out of space or get close to that with undofiles in LOGFILE GROUP and this simple query will show if this is happening:
# checking if logs are reach its max file size
mysql> SELECT CONCAT('CLUSTER NODE: ', node_id) AS NodeId, -> FORMAT(total/1024/1024,0) AS 'Total Space (MB)', -> FORMAT(used/1024/1024,0) AS 'Used Space (MB)' -> FROM logspaces -> GROUP BY NodeId;+-----------------+------------------+-----------------+| NodeId | Total Space (MB) | Used Space (MB) |+-----------------+------------------+-----------------+| CLUSTER NODE: 3 | 256 | 0 || CLUSTER NODE: 4 | 256 | 0 || CLUSTER NODE: 5 | 256 | 0 || CLUSTER NODE: 6 | 256 | 0 |+-----------------+------------------+-----------------+4 rows in set (0.26 sec)
In-memory Tables
• In order to store table data in-memory, no additional statements are required, instead some parameters must be configured to get the required data in main memory;
• Those parameters must be configured in the global configuration file (located on mgm node),l generally use the [ndbd default] section;
• it is not good to set up parameters individually for each Data Node;
In-memory Tables
• Most commonly used parameters in [ndbd] and [ndbd default]:• DataMemory: amount of memory space for storing database
records;• IndexMemory: amount of memory space to store hash indexes
(primary key and unique indexes);• MaxNoOfTables;• MaNoOfAttributes;• MaxNoOfOrderedIndexes;• MaxNoOfTriggers;• MaxNoOfConcurrentOperations;• MaxNoOfConcurrentIndexOperations;• MaxNoOfConcurrentScans;• MaxNoOfConcurrentTransactions “…”
Good strategy to place’s tables
• Normally, a good strategy is to define together with the customer those data and tables that are critical to the customer's business and those that are not;• Critical data will reside in-memory;• Non-critical data will reside on disk structures;
• In-memory tables require good parameter tuning in order to accommodate all data in memory: DataMemory, IndexMemory and MaxNoOf*;
• Disk-based tables will require structures to be created as LOGFILE GROUP and TABLESPACES, and will need faster disks such as SSD, SCSI or 15K disk storages;
Calculating DataMemory and IndexMemory
• MySQL Cluster comes with a set of utility programs that run on the command line with lots of helpful options for configuring your server;
• To calculate the amount of required memory that a specific database will need to work in a MySQL Cluster, the Perl script named ndb_size.pl may be used;
• Before you can use it, you will need the following Perl packages:• perl-DBI*;• perl-DBD;• perl-Class-MethodMaker;
Install epel repository
and use “yum install”
Install epel repository
and use “yum install”
Calculating DataMemory and IndexMemory
•ndb_size.pl has more conservative options with only long flags, as seeing below:
• --username• --password – can`t be empty one;• --hostname;• --database;• --format – it can be text or HTML• --excludetables;• --excludedbs;• --savequeries (file);• --loadqueries (previously recorded with --savequeries);
Calculating DataMemory and IndexMemory
• Executing ndb_size.pl against world database running into a non-cluster MySQL Server
# executing ndb_size.pl on command-line
shell> ndb_size.pl --user=wb --password=“123” --hostname=192.168.1.107
--database=world --format=text
# checking how much memory is required to put world database into a “MC”
Parameter Minimum Requirements (world database)
-----------------------------------------------
* indicates greater than default
Parameter Default 4.1 5.0 5.1
DataMemory (KB) 81920 480 480 512
NoOfOrderedIndexes 128 3 3 3
NoOfTables 128 3 3 3
IndexMemory (KB) 18432 192 88 88
NoOfUniqueHashIndexes 64 0 0 0
NoOfAttributes 1000 24 24 24
NoOfTriggers 768 15 15 15
Agenda
• Cluster’s components;• Management Node• SQL/API Node• Data/Storage Node
• Configurations File;• Local• Global• Connect String
• Cluster Partitioning• Partitions• Fragments
• Disk Tables• In-Memory Tables
• Replication• Synchronous• Assynchronous• Replication Channels;
• Backup & Restore• Native Backup• Native Restore• mysqldump
• Performance Tuning• Condition Pushdown• Iptraf
- Part I - Part II
Replication
MySQL Cluster Replication
• MySQL Replication is a feature of the MySQL Server that allows you to replicate data from one database server, called MASTER, to one or more, called SLAVE;
• Using MySQL Cluster has three replication modes:
• Synchronous replication happens only between Data Nodes and uses the Two Phase Commit Protocol that enables transactions to commit on all data nodes at the same time;
• Semi-synchronous and Asynchronous replication, to set up replication channels between two or more clusters;
MySQL Cluster Replication
• MySQL Cluster can be used across many sites for geographical replication - two sites connected as Active / Passive;
• This kind of configuration is done via MASTER/MASTER implementation with the application accessing;
MySQL Cluster Replication
• In our actual scenario, where we are using ten nodes, 4 sql, 4 ndbd, and 2 mgm, it can be easily divided into two cluster’s sites, connected by a MASTER/MASTER replication;
• Remember that a passive channel must be configured with a “write barrier”:
# read only will avoid write query execution from any user
# apart from root -- root will continue be able to do writes
mysql> SET GLOBAL read_only = 1;
Query OK, 0 rows affected (0.00 sec)
MySQL Cluster Replication
• Step-by-step to replication channel configuration:
• Config.ini file on Node1 and Node2 must be recreated;• Unique server-id for each SQL Node inside the schema;• A common user must be create individually on each server;
• GRANT REPLICATION SLAVE…;• Check if binary log is enabled – it must be enable;• CHANGE MASTER TO on servers involved, in order to create
two:• The first server from group A will MASTER/MASTER with
first server from group B;• The second server from group A will MASTER/MASTER
with second server from group B;
MySQL Cluster Replication
Backup & Restore
Backup & Restore
• Considering which method and tools will be used is a good way to begin the strategic planning for backup and recovery;
• MySQL Cluster has its own native tools that can be used to design better backup and restore plans for existing databases;
• Native backup is done by the START BACKUP command and the restored by the ndb_restore client program;
Backup – SINGLE USER MODE
• Single User Mode is a way to tell the cluster to process queries from a specific SQL/API Node only – It is good for situations when you need to avoid updates in the middle of a backup process: # entering single user mode – other SQL/API will be ignored
ndb_mgm> ENTER SINGLE USER MODE 4
Single user mode entered
Access is granted for API node 4 only
ndb_mgm> START BACKUP NOWAIT
ndb_mgm>
ndb_mgm> EXIT SINGLE USER MODE
Exiting single user mode in progress
Use ALL STATUS or SHOW to see when single user mode has been exited
Backup – START BACKUP
• A MySQL Cluster backup is a snapshot of all NDB databases stored by the cluster at a given time, and consists of three main parts:
• Metadata: the names and definitions of all MySQL Cluster databases and tables :• BACKUP-backup_id.node_id.ctl
• Table records: the data actually stored in the tables at the time that the backup was made:• BACKUP-backup_id.node_id.Data
• Transaction Log: a sequential record telling how and when data was stored in the database:• BACKUP-backup_id.node_id.log
Backup – START BACKUP
• The START BACKUP command execution is done through the ndb_mgm or Management Node Client and it has three interesting options:
• NOWAIT: present the prompt immediately to the user;• WAIT STARTED: wait until the backup process starts;• WAIT COMPLETE: wait until the backup process is finished;
• It is good practice to set up a new physical partition on Data Nodes to store all backups – this behavior can be configured using BackupDataDir variable under [ndbd default]
Backup – START BACKUP
• When using START BACKUP with NOWAIT option, monitor the backup with ALL REPORT: # using START BACKUP with NOWAIT and monitoring its process
ndb_mgm> START BACKUP NOWAIT
ndb_mgm> ALL REPORT BACKUPSTATUS
Node 3: Local backup status: backup 3 started from node 1 #Records: 0 #LogRecords: 0 Data: 0 bytes Log: 0 bytesNode 4: Local backup status: backup 3 started from node 1 #Records: 0 #LogRecords: 0 Data: 0 bytes Log: 0 bytes
ndb_mgm> Node 3: Backup 3 started from node 1
Node 3: Backup 3 started from node 1 completed StartGCP: 5444 StopGCP: 5447 #Records: 7370 #LogRecords: 0 Data: 497788 bytes Log: 0 bytes
Backup – START BACKUP
• Cluster backups are created by default in the BACKUP subdirectory of the DataDir on each Data Node as showed below:
• Listing files inside BACKUP-1:
# listing DataDir/BACKUP subdirectories
[root@node3]# ls –l
BACKUP-1
# listing files from BACKUP-1 directory
[root@node3 BACKUP]# ls -l BACKUP-1/total 276-rw-r--r-- 1 root root 253388 Jun 7 17:57 BACKUP-1-0.3.Data-rw-r--r-- 1 root root 17660 Jun 7 17:57 BACKUP-1.3.ctl-rw-r--r-- 1 root root 52 Jun 7 17:57 BACKUP-1.3.log
Restore - ndb_restore
• The cluster’s restoration program is implemented as a separate command-line utility – ndb_restore and there are a lot of options that can be used with it;
• -c is a connect string;• -b is a backup id;• -n is the node’s id;• -r is the path where backup is located
•ndb_restore acts as a node in the cluster and requires a configuration section in the global cluster configuration – a free slot to use every execution;
Restore - ndb_restore
[root@node3 ~]# ndb_restore -c 192.168.1.101 -b 1 -n 3 -r /backup-cluster/BACKUP/BACKUP-1Backup Id = 1Nodeid = 3backup path = /backup-cluster/BACKUP/BACKUP-1Opening file '/backup-cluster/BACKUP/BACKUP-1/BACKUP-1.3.ctl'File size 17660 bytesBackup version in files: ndb-6.3.11 ndb version: mysql-5.1.56 ndb-7.1.13Stop GCP of Backup: 4747Connected to ndb!!Opening file '/backup-cluster/BACKUP/BACKUP-1/BACKUP-1-0.3.Data'File size 253388 bytes_____________________________________________________Processing data in table: world/def/CountryLanguage(15) fragment 0_____________________________________________________Processing data in table: sys/def/NDB$EVENTS_0(3) fragment 0_____________________________________________________Processing data in table: mysql/def/ndb_apply_status(6) fragment 0_____________________________________________________Processing data in table: world/def/City(11) fragment 0_____________________________________________________Processing data in table: mysql/def/NDB$BLOB_4_3(5) fragment 0_____________________________________________________Processing data in table: sys/def/SYSTAB_0(2) fragment 0_____________________________________________________Processing data in table: mysql/def/ndb_schema(4) fragment 0_____________________________________________________Processing data in table: world/def/Country(13) fragment 0Opening file '/backup-cluster/BACKUP/BACKUP-1/BACKUP-1.3.log'File size 52 bytesRestored 2697 tuples and 0 log entries
NDBT_ProgramExit: 0 - OK
Performance Tuning
Engine Condition Pushdown
• This optimization improves the efficiency of direct comparison between a no indexed column and a constant. In such cases, the condition is “pushed down” to the storage engine for evaluation;
• For MySQL Cluster, this optimization can eliminate the need to send no matching rows over the network between the cluster's data nodes and the MySQL Server that issued the query, and can speed up queries where it is used by a factor of 5 to 10 times over cases where condition pushdown could be but is not used;
•WHERE condition processed in the SQL Node:
Engine Condition Pushdown
Data Nodes
Many Rows
MySQL
Few Rows
SQL Query
engine_condition_pushdown=0
Engine Condition Pushdown
mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10\G
************** 1. row **************************
id: 1
select_type: SIMPLE
table: t1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 10
Extra: Using where
Engine Condition Pushdown
• WHERE condition “pushed down” to the Data Nodes:
engine_condition_pushdown=1
Few Rows
MySQL
Few Rows
SQL Query
Engine Condition Pushdown
mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10\G
************** 1. row **************************
id: 1
select_type: SIMPLE
table: t1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 10
Extra: Using where with pushed condition
Iptraf
• IPTraf is a network monitoring utility for IP networks. It intercepts packets on the network and gives out various pieces of information about the current IP traffic over it;
• It is simple to install after the epel repository is installed:• shell> yum –y install iptraf
• To monitor the interface used by the cluster:• shell> iptraf –i eth0
Iptraf
MySQL Cluster’s Architecture
Thanks!
• Wagner Bianchi is:
• CMA 5.0/5.1/5.5;• CMDEV 5.0;• CMDBA 5.0;• CMCDBA 5.1;
@wagnerbianchijr