4.2.7 About Change Propagation

After tables are loaded into MySQL HeatWave, data changes are automatically propagated from DB System tables to their counterpart tables in the MySQL HeatWave Cluster.

DML operations, INSERT, UPDATE, and DELETE, on the DB System do not wait for changes to be propagated to the MySQL HeatWave Cluster; that is, DML operations on the DB System are not delayed by MySQL HeatWave change propagation.

Data changes on the DB System node are propagated to MySQL HeatWave in batch transactions. Change propagation is initiated as follows:

• Every 200ms.

• When the change propagation buffer reaches its 64MB capacity.

• When data updated by DML operations on the DB System are read by a subsequent MySQL HeatWave query.

Before You Begin

• Import Data into MySQL HeatWave DB System.

Verify Change Propagation

To check if change propagation is enabled globally, query the rapid_change_propagation_status variable:

mysql> SELECT VARIABLE_VALUE
        FROM performance_schema.global_status
        WHERE VARIABLE_NAME = 'rapid_change_propagation_status';
+----------------+
| VARIABLE_VALUE |
+----------------+
| ON             |
+----------------+

To check if change propagation is enabled for individual tables, query the POOL_TYPE data in MySQL HeatWave Performance Schema tables.

• As of MySQL 9.2.1, TRANSACTIONAL indicates that change propagation is enabled for the table. SNAPSHOT indicates that change propagation is disabled.

• In previous versions of MySQL, RAPID_LOAD_POOL_TRANSACTIONAL indicates that change propagation is enabled for the table. RAPID_LOAD_POOL_SNAPSHOT indicates that change propagation is disabled.

mysql> SELECT NAME, POOL_TYPE
          FROM rpd_tables,rpd_table_id 
          WHERE rpd_tables.ID = rpd_table_id.ID AND SCHEMA_NAME LIKE 'tpch';
+---------------+---------------+
| NAME          | POOL_TYPE     |
+---------------+---------------+
| tpch.orders   | TRANSACTIONAL |
| tpch.region   | TRANSACTIONAL |
| tpch.lineitem | TRANSACTIONAL |
| tpch.supplier | TRANSACTIONAL |
| tpch.partsupp | TRANSACTIONAL |
| tpch.part     | TRANSACTIONAL |
| tpch.customer | TRANSACTIONAL |
+---------------+---------------+

See Section 11.2.1.3, “Change Propagation Limitations”.

Change Propagation Failure

A change propagation failure can cause tables in MySQL HeatWave to become stale, and queries that access stale tables are not offloaded to MySQL HeatWave for processing.

Tables that have become stale due to change propagation failures resulting from out-of-code errors are automatically reloaded. A check for stale tables is performed periodically when the MySQL HeatWave Cluster is idle.

If change propagation failure has occurred for some other reason causing a table to become stale, you must unload and reload the table manually to restart change propagation for the table. See Section 4.4.2, “Unload Data Manually”, and Section 4.2, “Load Data from DB System into MySQL HeatWave Cluster”.

What's Next

• Learn how to reload tables.