Mysqlと同様にmariadbでもpartitionを使えます(当たり前ですが)
設定の前に
パーティションはあらかじめ作成しておかないといけません。
また、ある程度決まった法則で消せるデータにしか有効ではありません。
私はommysqlでしか使い道がありませんでしたが、十分に有効な手立てでした。
1.作成
PARTITION BY RANGE COLUMNS(`ReceivedAt`)
Create(or Alter)Tableの際にこういう設定をしてこのカラムは範囲でパーティションを付けると宣言をしておきます。
なお、主キーに含まれてないカラムは指定できません。
詳しくは公式ドキュメントを見てもらったほうがいいです。
alter table Syslog.SystemEvents add partition (partition P202211 values less than ('2022/12/01 00:00'))
これはパーティション名がP202211というパーティションをSyslog.SystemEventsに追加するSQLです。
values less than ('2022/12/01 00:00')
となっているのはすでにP202210というパーティションがless than ('2022/11/01 00:00')を持っているからです。
2.削除
partitionはいきなり削除してもデータの不整合が起きないことがわかりました。
最後のdrop partitionを実行してください。
まずはパーティション内のデータをすべて削除します。
select count(ID) from Syslog.SystemEvents where ReceivedAt < '20211001'
delete from Syslog.SystemEvents where ReceivedAt < '20211001'
削除はまとめてやるとtemp領域を食い尽くしてディスクをめちゃめちゃつかうので、
件数によっては日付毎はおろか。。。
delete from Syslog.SystemEvents where ReceivedAt < str_to_date('20211001 01:00','%Y%m%d %H:%i');
commit;
delete from Syslog.SystemEvents where ReceivedAt < str_to_date('20211001 02:00','%Y%m%d %H:%i');
commit;
のような事態に陥ります。ので、毎月cronなどで動かすのは怖いといえば怖いのですが、
確実にpythonなどでsql分をスクリプト化しておくことをお勧めします。
そして原因はわからないのですが、
SELECT TABLE_SCHEMA, TABLE_NAME, PARTITION_NAME, PARTITION_ORDINAL_POSITION, TABLE_ROWS FROM INFORMATION_SCHEMA.PARTITIONS WHERE TABLE_NAME='SystemEvents';
これでパーティションにデータがないことを確認したかったのですが、データが残っているように見えました。
+--------------+--------------+----------------+----------------------------+------------+
| TABLE_SCHEMA | TABLE_NAME | PARTITION_NAME | PARTITION_ORDINAL_POSITION | TABLE_ROWS |
+--------------+--------------+----------------+----------------------------+------------+
| Syslog | SystemEvents | P202110 | 2 | 135124 |
+--------------+--------------+----------------+----------------------------+------------+
select * from Syslog.SystemEvents partition (P202110);
が、このようにパーティションを指定してselectを発行しても結果は0だったので、削除します。
alter table Syslog.SystemEvents drop partition P202110;
これでパーティションが削除され、ハードディスクの空き容量がそれなりに復活します。