Severalnines Self-Training: MySQL® Cluster - Part III

MySQL Cluster Training
presented by severalnines.com

Address:
Contact: SeveralninesAB
Jean-Jérôme Schmidt c/o SICS, Box 1263
Email: services@severalnines.com Isafjordsgatan22
SE-164-29 Kista

Copyright 2011 Severalnines AB Control your database infrastructure 1

Introduction

• At Severalnines, we believe in sharing information
and knowledge; we all come from an open source
background
• We know a lot of things about MySQL Cluster and
think that MySQL Cluster is a great technology
• These free MySQL Cluster Training slides are a
contribution of ours to the knowledge and information
sharing that‟s common practice in the open source
community
• If you have any questions on these slides or would
like to book an actual training class, please contact
us at: services@severalnines.com


Training Slides - Concept

• Over the coming weeks we will be chronologically
releasing slides for the different sections of our
MySQL Cluster Training program on our website.
• The full agenda of the training with all of its modules
is outlined in the next slides so that you can see what
topics will be covered over the coming weeks.
• Particularly specialised topics such as Cluster/J or
NDB API are not fully covered in the slides. We
recommend our instructor-led training classes for
such topics.
• Please contact us for more details:
services@severalnines.com


Full Training Agenda (1/4)

• MySQL Cluster Introduction
– MySQL eco system
– Scale up, scale out, and sharding
– MySQL Cluster Architecture
– Use cases
– Features
– Node types and Roles
• Detailed Concepts
– Data Distribution
– Verifying data distribution
– Access Methods
– Partitioning
– Node failures and failure detection
– Network Partitioning
– Transactions and Locking
– Consistency Model
– Redo logging and Checkpointing


Agenda (2/4)

• Installing MySQL Cluster
– Setting up MySQL Cluster
– Starting/stopping nodes
– Recovery and restarts
– Upgrading configuration
– Upgrading Cluster
• Performance Tuning (instructor-led only; contact us at services@severalnines.com)
– Differences compared to Innodb/MyISAM
– Designing efficient and fast applications
– Identifying bottlenecks
– Tweaking configuration (OS and MySQL Cluster)
– Query Tuning
– Schema Design
– Index Tuning


Agenda (3/4)

• Management and Administration
– Backup and Restore
– Geographical Replication
– Online and offline operations
– Ndbinfo tables
– Reporting
– Single user mode
– Scaling Cluster
• Disk Data
– Use cases
– Limitations
– Best practice configuration
• Designing a Cluster
– Capacity Planning and Dimensioning
– Hardware recommendations
– Best practice Configuration
– Storage calculations


Agenda (4/4)

• Resolving Issues
– Common problems
– Error logs and Tracefiles
– Recovery and Escalation procedures
• Connectivity Overview
– NDBAPI
– Cluster/J
– LDAP
• Severalnines Tools
– Monitoring and Management
– Benchmarking
– Sandboxes
– Configuration and capacity planning
• Conclusion


Agenda: Lab Exercises
(only applicable to instructor-led training classes)

• Lab Exercises
– Installing and Loading data into MySQL Cluster
– Starting/stopping nodes, recovery
– Query tuning
– Backup and Restore
– Configuration Upgrade

• Would you like to try something particular?
– This is possible too, speak with your instructor


Prerequisites
• Readers / Participants have understanding of SQL and basic database concepts.

• Laptops/PCs for hands-on exercises
• Linux: 1GB RAM
• Windows: 2GB RAM
• Approx. 20GB disk space and Virtualbox installed.
• Virtualbox can be downloaded for free at http://www.virtualbox.org/wiki/Downloads

• MySQL Cluster version 7.1 or later


3rd Installment of the Severalnines
Cluster Self-Training

Part 2 : Detailed Concepts (ctd…)
Section 3


Topics covered in Section 3

• Access Methods
• Redo Logging and Check-pointing


Access Methods


Access Methods

• The Data Nodes can handle the following primitive
types of requests:
– PRIMARY KEY
– INDEX SCAN
– UNIQUE INDEX
– (Note in 7.2.x a new “fast-join” interface exists as well).
• Any of the following queries will be translated and
execute a combination of the above.
– UPDATE t1 SET data=„abc‟ WHERE id=1;
– DELETE FROM t1 WHERE id>1;
– SELECT * FROM t1 WHERE t1.id=1
– SELECT * FROM t1, t2 WHERE t1.id=t2.id and t.id=1;


Primary Key

• The Primary Key request is the fastest primitive type
to access data in the data nodes.
• SELECT data FROM subscriber WHERE subid=1;

STORAGE LAYER

DATA DATA
NODE 0 NODE 1

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Primary Key – Calculate Hash on PK


1. MySQL Server (NDBAPI)
calculates md5sum(subid=1)  128-bit value
2. MySQL Server sends the request to the data node
having the Primary partition for the requested data

STORAGE LAYER

DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Primary Key – Determine Partition


PARTITION_HASH INDEX_HASH
calculates md5sum(subid=1)  128-bit value 64-bit 64-bit
2. PARTITION=(PARTITION_HASH MODULO #PARTTIONS )

STORAGE LAYER

DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Primary Key – Execute Request


PARTITION_HASH INDEX_HASH
calculates md5sum(subid=1)  128-bit value 64-bit 64-bit
2. PARTITION=(PARTITION_HASH MODULO #PARTTIONS )
3. Map PARTITTION to Data node and SEND REQUEST

STORAGE LAYER

DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Unique Indexes

• A Unique Index is used as a CONSTRAINT.
• The Unique Index is represented as a hidden separate table.
– Storage cost can be high.
• CREATE UNIQUE INDEX ix_unique ON
subscriber(data)

subid data data2 data subid
1 A AA A 1
Partition 0 Partition 0
3 B BB C 2

2 C CC B 3
4 D DD D 4

subscriber Ix_unique


Unique Index Lookup

• SELECT data2 from subscriber WHERE data=„B‟;
STORAGE LAYER

DATA DATA
NODE NODE

P0 P1

subid data data2 data subid
1 A AA A 1
3 B BB C 2

2 C CC B 3
4 D DD D 4

subscriber Ix_unique

Index Scans - Secondary Indexes

• The ordered index is stored in the DataMemory
– Each index cost 16B per record (no matter how many
columns are indexed)
• By default the PRIMARY KEY and UNIQUE KEY also
has an ordered index
– Avoid it by specifying USING HASH
• Saves 16B per record.

ACC TUP ACC TUP
P0 P0 P0 P0

IndexMemory DataMemory IndexMemory DataMemory
DATA NODE 1 DATA NODE 2


Index Scans - Secondary Indexes

• T-tree indexes are used for ordered secondary
indexes
– Optimized for In-memory data – does not carry any data
(space) .
– Each data node maintains a local ordered index of its data.

ACC TUP ACC TUP
P0 P0 P0 P0

IndexMemory DataMemory IndexMemory DataMemory
DATA NODE 1 DATA NODE 2


Index Scans - single table

• For Index Scans / Range scans all partitions needs to be
scanned.
– The MySQL Server will contact a TC on one of the data nodes.
– The TC will then start an index on each LQH in the Cluster.
• SELECT data FROM subscriber WHERE subid<4

STORAGE LAYER

DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber
Note – only the PRIMARY partitions are shown.

Index Scans – single table

• Each node will send back the records matching the search
criteria.

Data is sent back in batches of up to 32

1 A STORAGE LAYER
3 B
2 C
DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Index Scans – single table

• The NDBAPI performs a merge sort.

1 A
2 B
3 C

STORAGE LAYER

DATA DATA
NODE NODE

subid data
1 A Partition 0
3 B P0 P1

2 C Partition 1
4 D

subscriber

Redo Logging and Check-pointing


Redo Logging and Check-pointing

• MySQL Cluster writes a Redo Log and Checkpoints
data to disk
– Redo Logs and Checkpoints are essential for Recovery.
– Both components are needed.
• The redo log is periodically written to disk.
– Asynchronously written.
– Controlled by the Global Checkpoint Protoctol, GCP.
• Checkpoints
– The entire data set (DataMemory) is checkpointed to disk
– Controlled by the Local Checkpoint Protocol, LCP.


Redo Logging

• INSERT INTO subscriber(id, data) VALUES(1,’A’);

Data Node 0 PREPARE

LQH

ACC TUP

DataMemory
IM
subid data
P0
1 A
subid data
1 A Partition 0

1A REDOBUFFER
subscriber


Redo Logging


Data Node 0 COMMIT

LQH

ACC TUP

DataMemory
IM
subid data
P0
1 A
subid data
1 A Partition 0

1A C REDOBUFFER
subscriber


Redo Logging

• INSERT INTO subscriber(id, data) VALUES(2,’B’);

Data Node 0 PREPARE

LQH

ACC TUP

DataMemory
IM
subid data
P0
1 A
subid data
1 A Partition 0
2 B
1A C REDOBUFFER
2B
subscriber


Redo Logging


Data Node 0 COMMIT

LQH

ACC TUP

DataMemory
IM
subid data
P0
1 A
2 B subid data
1 A Partition 0
2 B
1A C REDOBUFFER
2B C
subscriber


Redo Logging
• GlobalCheckpoint happens – sync RedoBuffer to Disk
– TimeBetweenGlobalCheckpoints: 1000 (sync every 1000ms)
Data Node 0 GCP

LQH

ACC TUP

DataMemory
IM
subid data
P0
1 A
2 B subid data
1 A Partition 0
2 B
REDOBUFFER
subscriber

REDO LOG 1A C 2B C


Redo Logging

• The Redo log is actually split in for four segments.
• The segments are stored in
• /datadir/ndb_X_fs/D8..D11
– Each segment consists of a number of files.
• Do e.g
– ls –al /datadir/ndb_X_fs/D8
– How many files?
– What about the file size?


Problem

• To save all the changes made from time 0 the Redo
log could grow to infinitely large.
– This is not practical.
• The Redo Log must “re-cycled” after some time.
• Checkpoints takes care of this problem.


Local Checkpoints

• A Checkpoint (called Local Checkpoints) is a disk image
of the records stored in the DataMemory
– All data nodes starts a Local Checkpoint at the same time.
• Each data node checkpoints its own DataMemory.
– logical image of database of each data node (both Primary and
Secondary)
• Periodically, the records in the DataMemory is written out
to disk.
– TimeBetweenLocalCheckpoints
– DiskCheckpointSpeed
• An LCP starts after
TimeBetweenLocalCheckpoints=20 (by default)
ofword changes has happened to the cluster.
– 4*2^20 =4MB (by default), or if no changes every 57th
minute. Only one LCP is active at a time.

Local Checkpoints

• LCP 0 is being written.
DataMemory
DataMemory
subid data
LCP TIME = USED_DATAMEMORY / DiskCheckpointSpeed
1 A
Checkpointing 10000MB of used DataMemory at a speed of 10MB/s
2 B
takes 1000seconds.

LCP TIME

LCP start LCP end

REDOLOG 1A C 2B C REDO LOG

subid data
LCP 1 A
2 B


Local Checkpoints

• After 2 LCPs the Redo Log can be recycled (cut the tail of..)
DataMemory
DataMemory DataMemory
subid data subid data
1 A 1 A
2 B 2 B
3 C
4 D

TimebetweenLocalCheckpoints

LCP TIME LCP TIME

LCP start LCP end LCP start LCP end

REDOLOG 1A C 2B C 3C C 4D RC

subid data
1 A
subid data
LCP 2 B
1 A
3 C
2 B
4 D


Dimensioning (1)
• If the Redo log gets full before the 2nd LCP
– No writes can be performed on MySQL Cluster until 2nd LCP finishes
– There have been bugs in the area – a crashed cluster in this state could
lead to irrecoverable errors.


Dimensioning (1)

• The Size of Redo Log is the only disk size setting
specified at Cluster start.
– It is one of the most important parameters to set correctly.
• The size of the Redo Log should accommodate 3x
Local Chekpoints.
• If LCP1 starts immediately after LCP0 the redo log
must be able to store
– 3 x<bytes written/s to cluster> / #Nodes / #Replicas
xDataMemory /DiskCheckpointSpeed


Dimensioning (2)

• Size of the Redo Log is expressed in
NoOfFragmentLogFiles.
– Each FragmentLogFile is physically made up of 4 files each
FragmentLogFileSize.
– Size of each FragmentLogFileSize=256M
• Example:
– 2 data nodes, 2 replicas, write 10MB/s of data,
DiskCheckpointspeed=10MB/s, Datamemory=10GB
– Size of Redo in MB: 3 x 10MB/s / 2 / 2 *10000M/10MB/s = 30 /
1 * 1000 =30 000MB
– NoOfFragmentLogFiles= (30000MB) / 4 * 256MB = 30.
• Best Practice!
– NoOfFragmentLogFiles= [4-6 ] xDataMemory / 4
xFragmentLogFileSize
– 4x for read mostly, 6x for very write intensive applications or if
using BLOBs.

Other Buffers to Dimension

• RedoBuffer
– 32-64MB is a good size
• TotalSendBufferMemory/TotalReceiveBufferMemory
– Buffers for communication
– SendBufferMemory/ReceiveBufferMemory
• Set to 4-8M
• BackupDataBufferSize/BackupLogBufferSize
– BackupMemory=BackupDataBufferSize+BackupLogBufferSize
– Set to 16M and 4M resp.
• DiskPageBufferMemory and UndoBuffer – for disk data
only
• www.severalnines.com/config will set these buffers to
recommended values based on your configuration and
workload.


Coming next in Section 4:

Detailed Concepts (ctd …)

Recovery


We hope these training slides are
useful to you!

Please visit our website to view the
next section of this training.

For any questions, comments, feedback or to
book a training class, please contact us at:

services@severalnines.com

Thank you!


Disclaimer

© Copyright 2011 Severalnines AB. All rights reserved.

Severalnines& the Severalnineslogo(s) are trademarks of Severalnines AB.

MySQL is a registered trademark of Oracle and/or its affiliates.

Other names may be trademarks of their respective owners.


Severalnines Self-Training: MySQL® Cluster - Part III

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Severalnines

Mehr von Severalnines (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Severalnines Self-Training: MySQL® Cluster - Part III

Hinweis der Redaktion