MySQL Cluster Basics

MySQL Cluster Wagner Bianchi – LAD Senior Principal Consulting [email_address]

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 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!!)

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 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 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 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 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…

Disk-based Tables # 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 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 ”

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

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;

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 bytes Node 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-1 Backup Id = 1 Nodeid = 3 backup path = /backup-cluster/BACKUP/BACKUP-1 Opening file '/backup-cluster/BACKUP/BACKUP-1/BACKUP-1.3.ctl' File size 17660 bytes Backup version in files: ndb-6.3.11 ndb version: mysql-5.1.56 ndb-7.1.13 Stop GCP of Backup: 4747 Connected 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 0 Opening file '/backup-cluster/BACKUP/BACKUP-1/BACKUP-1.3.log' File size 52 bytes Restored 2697 tuples and 0 log entries NDBT_ProgramExit: 0 - OK

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

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

MySQL Cluster Basics

In this document