High level description of schema management in MySQL Cluster from 2014. Describes MySQL Server and cluster aspects, locks, transactions, online and copying ALTERs, table versions etc.

1. Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 121
Insert Picture Here
MySQL Cluster schema
management
Frazer Clement
MySQL Cluster Technical lead
frazer.clement@oracle.com
messagepassing.blogspot.com
November 2014

2. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.2
MySQLD
●
Each MySQLD maintains independent schema information in Data
Directory structure, and on disk .frm files
●
MySQLD stores SQL level schema information, actual creation of
tables, indices, storage is delegated to the storage engine (SE).
●
ha_ndbcluster the Ndb 'storage engine' layer uses a 'Global Schema
Lock' (GSL) and 'Schema distribution' via the mysql.ndb_schema table to
synchronise schemas across all MySQLDs in a cluster.
●
MySQLD has the concept of certain schema operations (DDL) being
'online' or 'in place' as opposed to 'offline' or 'copying'.
●
Generally any schema change can be done offline/copying, and only a
(growing) subset can be done online / inplace.
Schema management Offline / copying schema changes commonly
require at least 2*table storage to complete

3. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.3
MySQLD
For offline / copying changes :
●
Much of the work is done by MySQLD :
Create table sql#xxx with new schema, Scan old table copying and
reformatting rows, Rename table name to sql#yyy, sql#xxx to table
name, drop table sql#yyy.
●
MySQLD will take protective table locks on the MySQLD where the
DDL is running, but these have no effect on queries or DML from NdbApi
clients or other MySQLDs.
●
The scan/copy part of offline schema change is not consistent w.r.t.
ongoing updates, so they must be stopped during the schema change.
Schema management Offline / copying schema changes can be
effectively 'online' if they are performed at a
backup site, and replication is used.

4. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.4
MySQLD
●
For online/inplace changes most of the work is delegated to the SE as
it is usually very implementation specific.
●
Sometimes MySQLD takes more conservative locks than necessary
(e.g. table locks) while online schema operations are running. These
can lock out concurrent access on the MySQLD where the DDL is
running. This is confusing and limiting, but it is still possible to run
queries and DML via NdbApi and other MySQLDs.
Schema management

5. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.5
Ndb
●
Ndb has its own Data dictionary (see ndb_show_tables, ndb_desc
etc)
●
Data dictionary is distributed, transactional etc, independent of
MySQLD view of schema
●
Transactions (since 7.0) ensure clean rollback if participants fail or
resources are exhausted during a schema operation.
●
Ndb schema objects are versioned with a Major and Minor version.
Compatible (online) changes only increment the Minor part of the
version.
●
For tables, the Ndb data dictionary contains the table's .frm content as
a Blob. This allows the SE to 'create' the tables on newly started / re-
initialised MySQLD nodes.
Schema management

6. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.6
Currently supported Ndb online schema operations
●
Add index
●
Drop index
●
Add column (at end of row)
●
Reorganise partitions
Add index uses an Ndb-internal 'live copy' mechanism (similar to the
node recovery) to build an index while the indexed data is changing.
Add column makes use of 'Dynamic columns' inside LDM to add a
column by only changing table metadata- no need to scan/modify every
row.
Reorg uses triggers and special row markers.
Schema management

7. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.7
Issues in online schema change
●
Handling ongoing write activity
●
Minimising transient storage increase.
●
Amount of data involved if every row must be touched
●
Re-optimising storage if data is removed.
●
Compatible and non-compatible changes for existing clients
●
Dependencies between schema and clients
●
Replication
●
Backup and Restore
Schema management

8. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.8
Schema object versions + NdbApi
●
Visible via ndb_show_tables (and ndbinfo in 7.4+)
●
Online change (e.g. add column) increments minor version
●
Offline change (e.g. drop column) increments major version (or
changes schema object id)
●
NdbApi clients have a schema object cache, where each object is
versioned.
●
NdbApi operations carry the schema object versions they were defined
against.
●
If the data node's version differs only in the minor version, the operation
can proceed. If it differs in major version, it is rejected.
●
On schema object version error, clients will invalidate their local objects
and re-fetch.
Schema management

9. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.9
Schema object versions + NdbApi
●
This mechanism allows online schema upgrades where clients can
lazily update their schema object caches.
MySQLD approach
MySQLD is involved in all schema changes via schema distribution.
Schema changes are logically made to occur on epoch boundaries.
MySQLD controls (its) schema object invalidation.
MySQLD controls the schema used for Binlogging at any point in time,
Schema management

10. Copyright © 2014, Oracle and/or its affiliates. All rights reserved.10
Replication
●
Replication supports a set of attribute (column) type promotions and
demotions, as well as different numbers of columns at Master + Slave.
●
This allows different schemas at Master and Slave
Backup + Restore
ndb_restore supports a set of column type promotions and demotions
designed to mirror those supported by replication. This allows B+R on a
slave with different cluster to be a schema change mechanism and
ensures that the worst-case recovery mechanism (B+R) works even
when schemas are misaligned between replicas.
Schema management