5.7.1 Lakehouse Limitations for all File Formats

• See Section 2.18.9, “Other Limitations” for all HeatWave query related limitations. Before MySQL 8.3.0, not all queries could be accelerated by HeatWave Lakehouse, and a warning or error message was displayed.

• Do not create Lakehouse tables on the source DB in a replicated MySQL DB System if any of the replicas are outside HeatWave on OCI or HeatWave on AWS. This will cause replication errors.

• Before MySQL 8.4.0-u2, a replication channel might fail if a HeatWave Cluster is added to a replica of a MySQL DB System, and later manually stopped.

• It is not possible to dump external tables using the MySQL Shell export utilities, such as dumpInstance(). External tables are not replicated to InnoDB storage and cannot be exported. To export InnoDB data from a Lakehouse enabled database, exclude the external tables with an excludeTables option.

• It is not possible to restore a backup from a Lakehouse enabled MySQL DB System to a standalone MySQL DB System.

• A Lakehouse enabled MySQL DB System can support a maximum of 512 nodes.

• Before MySQL 8.4.0, Lakehouse does not enforce any specified constraints. For example, Lakehouse does not enforce primary key uniqueness constraints. MySQL 8.4.0 removes this limitation.

• HeatWave Lakehouse does not support the following:

  • DML statements:

    • INSERT

    • UPDATE

    • DELETE

    • REPLACE

  • The CREATE TABLESPACE statement.

  • The following options for the CREATE TABLE statement:

    • AUTOEXTEND_SIZE

    • AVG_ROW_LENGTH

    • CHECKSUM

    • COMPRESS

    • CONNECTION

    • DATADIR

    • DELAY_KEY_WRITE

    • ENCRYPT

    • INDEXDIR

    • INSERT_METHOD

    • KEY_BLOCK_SIZE

    • MAX_ROWS

    • MIN_ROWS

    • PACK_KEYS

    • PASSWORD

    • ROW_FORMAT

    • STATS_AUTO_RECALC

    • STATS_PERSISTENT

    • STATS_SAMPLE_PAGES

    • UNION

  • The default expression for a column definition for the CREATE TABLE statement.

  • Creating temporary tables.

  • Creating AUTO_INCREMENT columns.

    Therefore, Lakehouse is not compatible with REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE.

  • Creating triggers.

  • Running ANALYZE TABLE.

  • Running ALTER TABLE statements that construct indexes, ADD or DROP columns, or add enforced check constraints.

  • SELECT statements without RAPID as the secondary engine.

  • Hidden columns.

  • Index construction.

  • Keys with column prefixes.

  • Running any statement with a STORAGE clause.

  • The use of CURRENT_TIMESTAMP(), CURRENT_TIMESTAMP or NOW() as a default value for a timestamp column. Also an UPDATE statement with CURRENT_TIMESTAMP(), CURRENT_TIMESTAMP or NOW(). Enable explicit_defaults_for_timestamp to use ALTER TABLE and CREATE TABLE statements with Lakehouse tables that have a timestamp column.

  • The following limitations only apply up to MySQL 8.3.0-u2. MySQL 8.3.0-u2 removes these limitations:

    • Point-in-time-recovery. A MySQL DB System is created with point-in-time-recovery enabled by default. To enable Lakehouse, disable point-in-time-recovery.

    • High Availability. To enable Lakehouse, disable High Availability or create a standalone MySQL DB System for use with Lakehouse.

    • Read Replication.

    • Outbound Replication.

    Note

    When disabling Read Replicas, High Availability, or Outbound Replication on a MySQL DB System to enable Lakehouse, it is recommended to wait several minutes before enabling Lakehouse. This allows replication processes to complete their tasks and for the binlog dump threads to stop.