MySQL Cluster Schema management (2014)
- 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