LinuxTAG – day 2 – Lecture Notes – MySQL Clustering

Just some freeform notes I made during this lecture.

MySQL Cluster – Kai Voigt — 2006/05/04

Why
Redundancy
Scalability
– Vertical (bigger boxes)
– Horizontal (Clustering) !!

Architecture
– Connection
– SQL
– Storage
-> Future (all layers as plugins)

Repication
– Master -> Slave
– Write -> Readonly, delayed synchronisation

MySQL Cluster
– Storage on redundant ‘storage nodes’
– MySQL servers talk to storage nodes
– No communication among mysql-sql nodes, only between data-nodes
– Management system to control the cluster
– Using cluster-API, use storage-nodes without SQL
– Minimal 2 systems
– Server 1, mysql node + data node
– Server 2, mysql node + data node

– Table fragments (active) are stored on seperate data-nodes,
but also replicated to one other node (passive)
– Uses 2-phase-commit
– Heartbeat amount full-mesh mysql-nodes

Takeover
– When a heartbeat fails, the node that has the backup of a
segment, it takes over and becomes primary for this segment.
– When a failed node returns it resyncs with it’s backup nodes and
takes over the primary role again.

Network Partitioning (nodes can’t reach other node)
2 nodes – fiber – 2 nodes
There is no majority, so both sides shut-down.
Solution, add an arbitration node on one of the sides, so they get
majority.
Better solution… move arbitrator to a third location

Location A: Node 1+3 (Connected to B and C)
Location B: Node 2+4 (Connected to A and C)
Location C: Arbitration node (connections to A and B)

Additional features
– Management client
– Online Backup
– Online Restore
– Online Upgrade

Limitations
– All data needs to fit in memory !!! (add more nodes if more
space needed)
– No VARCHAR support (uses max size of the varchar)

MySQL 5.1 (Beta)
– Disk based data
– User definable partitioning
– VARCHAR support
– Replication from clusters
– Automatic table discovery
– Condition Push Down

Current developments
– 2 new (full-featured) storage engines (Falcon/Maria)
– Falcon expected Q3 2006

Be Sociable, Share!