Details
-
Bug
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
13.1, 13.2
-
None
Description
--source include/galera_cluster.inc
|
--source include/have_partition.inc
|
--source include/have_innodb.inc
|
|
|
--connection node_1
|
SET timestamp= UNIX_TIMESTAMP('2026-05-02 00:00:00'); |
--error 0,ER_PARSE_ERROR,ER_PARTITIONS_MUST_BE_DEFINED_ERROR
|
CREATE TABLE t1 (a INT, c DATE, PRIMARY KEY (a, c)) ENGINE=InnoDB PARTITION BY RANGE COLUMNS (c) INTERVAL 1 DAY (PARTITION p0 VALUES LESS THAN ('2026-04-30')); |
if ($mysql_errno) |
{
|
--skip Needs RANGE COLUMNS ... INTERVAL partitioning |
}
|
# The INSERT adds the partitions up to the current date on node 1 |
INSERT INTO t1 VALUES (1, '2026-05-01'); |
|
|
--connection node_2
|
# Wait for the row on node 2. Error 1242 means that it is not there yet |
--let $i= 100
|
while ($i)
|
{
|
--error 0,ER_SUBQUERY_NO_1_ROW,ER_UNKNOWN_COM_ERROR,ER_LOCK_WAIT_TIMEOUT,ER_LOCK_DEADLOCK,2006,2013 |
SELECT IF(COUNT(*) = 1, 1, (SELECT 1 UNION SELECT 2)) INTO @found FROM t1; |
--let $err= $mysql_errno |
if ($err != 1242) |
{
|
--let $i= 1 |
}
|
if ($err == 1242) |
{
|
--sleep 0.1 |
}
|
--dec $i |
}
|
if ($err == 1242) |
{
|
--die Node 2 does not have the row that node 1 inserted |
}
|
if ($err) |
{
|
--die Node 2 left the cluster: it could not apply a row that went into a partition added by INTERVAL partitioning on node 1 |
}
|
|
|
--connection node_1
|
DROP TABLE t1; |
Leads to:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Debug, Clang 22.1.8-20260622) Build 06/10/2026 |
mysqltest: At line 40: Node 2 left the cluster: it could not apply a row that went into a partition added by INTERVAL partitioning on node 1
|
The error log of node 2:
|
CS 13.1.2 87e62ca17270e163a6d41b3fc8d6f4d440f1bb88 (Debug, Clang 22.1.8-20260622) Build 06/10/2026 |
2026-10-07 10:00:45 2 [ERROR] Slave SQL: Could not execute Write_rows_v1 event on table test.t1; Table has no partition for value from column_list, Error_code: 1526; handler error HA_ERR_NO_PARTITION_FOUND; the event's master log FIRST, end_log_pos 0, Internal MariaDB error code: 1526
|
2026-10-07 10:00:45 2 [ERROR] WSREP: Inconsistency detected: Inconsistent by consensus on bee85299-c1d9-11f1-b197-b7970b3590a4:4
|
2026-10-07 10:00:45 0 [Note] WSREP: Received SELF-LEAVE. Closing connection.
|
2026-10-07 10:00:45 2 [ERROR] WSREP: Failed to apply write set: gtid: bee85299-c1d9-11f1-b197-b7970b3590a4:4 server_id: bee8184f-c1d9-11f1-b103-b7055afc0fd9 client_id: 12 trx_id: 60 flags: 3 (start_transaction | commit)
|
Node 1 adds the partitions up to the current date and inserts the row. Node 2 does not add the partitions, cannot apply the row and leaves the cluster. Optimized builds give the same result. When the current date is before the bound of p0, no partitions are added and the row reaches node 2.
With PARTITION BY SYSTEM_TIME ... AUTO, the history partitions that an UPDATE adds on node 1 are added on node 2 as well, and node 2 stays in the cluster.
From the code it seems that TABLE::range_interval_check_partition() in sql/sql_partition_auto_interval.cc adds partitions for row events only when THD::rgi_slave or THD::rgi_fake is set. The Galera applier applies the rows through THD::wsrep_rgi, so no partitions are added on node 2. TABLE::vers_switch_partition() in sql/sql_base.cc does not return early in that case.
Attachments
Issue Links
- is caused by
-
MDEV-15621 Implement interval partitioning similar to Oracle
-
- Closed
-
- relates to
-
MDEV-39808 MDEV-15621: ROW-binlog + INSERT: auto-creates an interval partition & logs the row, but not the implicit ADD PARTITION
-
- Closed
-
-
MDEV-41710 Replica stops with error 1526 on a row event for an INTERVAL partitioned table when the master session has another time zone
-
- In Progress
-