Keyword AUTO enables partition auto-creation.
Or with explicit partitions:
Before executing history-generating DML command add N history
partitions, so that N would be sufficient for potentially generated
history. N > 1 may be required when history is rotated by INTERVAL and
timestamp was jumped to future further than interval value.
If last history partition exceeds LIMIT records before DML command
then new history partition is created and the history filling is
switched to the new partition. Thus LIMIT does not carry strict
limitation and the history partition size must be planned as LIMIT
records plus average number of history one DML generates.
Auto-creation is implemented by synchronous
fast_alter_partition_table() call from the thread of the executed DML
command before the command itself (by the fallback and retry mechanism
similar to Discovery feature, see Open_table_context).
The name for newly added partitions are generated like default
partition names with extension of
MDEV-22155 (which avoids name
clashes by extending assignment counter to next free-enough gap).
These DML commands trigger auto-creation:
- DELETE (including multi-delete, excluding DELETE HISTORY)
- UPDATE (including multi-update)
- REPLACE (including REPLACE .. SELECT)
- INSERT .. ON DUPLICATE KEY UPDATE
- LOAD DATA .. REPLACE
MDEV-23642 Locking timeout caused by auto-creation affects original DML
The reasons for this are:
- Do not disrupt main business process (the history is auxiliary
- Consequences are non-fatal (history is not lost, but comes into wrong
partition; fixed by partitioning rebuild);
- There is more freedom for application to fail in this case or
not: it may read warning info and find corresponding error number.
- While non-failing command is easy to handle by an application and
fail it, the opposite is hard to handle: there is no automatic
actions to fix failed command and retry, DBA intervention is
required and until then application is non-functioning.