MySQL Cluster Basics

<Insert Picture Here>

MySQL Cluster

Wagner Bianchi – LAD

Senior Principal Consulting

[email protected]

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




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


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


• 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;


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


• 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


• 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;


# 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;


# 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;


# 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;


• 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• 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;


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


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


• 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”


•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);


• 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 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;


• 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;



• 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

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


• 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]


• 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


• 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:


Data Nodes

Many Rows

MySQL

Few Rows

SQL Query

engine_condition_pushdown=0


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


• WHERE condition “pushed down” to the Data Nodes:

engine_condition_pushdown=1

Few Rows

MySQL

Few Rows

SQL Query


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

MySQL Cluster Basics

Technology

Transcript of MySQL Cluster Basics