一部のデータベース(MySQL など)では、パーティション列をテーブルの一意制約の一部にする必要があります。 したがって、auditlog
テーブルを時間でパーティション分割するには、主キーを auditid
から複合キー auditid
+ clock
に変更する必要があります。
このセクションでは、auditlog
テーブルの主キーを変更する手順について説明します。
このページに記載されている手順は、上級ユーザー向けに設計されています。 これらの手順は、お客様の構成に合わせて調整する必要がある場合があります。 主キーの変更は、将来のアップグレードパッチと互換性がなくなる可能性があるため、手動でのアップグレードが必要になる場合があります。
主キーの変更は、auditlog
テーブルのサイズによっては、多くのリソースを消費し、多くの時間を要する操作となる場合があります。 変更中は、Zabbix サーバーを停止し、Zabbix フロントエンドを メンテナンスモード に切り替えることをお勧めします。 ただし、どうしても必要な場合は、ダウンタイムなしで主キーを変更する方法があります(下記参照)
auditlog
テーブルをパーティション分割すると、例えば大規模なシステムにおけるハウスキーピング機能の向上につながります。 Zabbix の housekeeping は現在、パーティション分割されたテーブルを利用できません(TimescaleDB を除く)が、スクリプトを使用して Zabbix ハウスキーピングを無効化し、パーティションを削除することができます。
Zabbix 7.0 以降、TimescaleDB の auditlog
テーブルはハイパーテーブルに変換され、ハウスキーパーがデータをチャンク単位で削除できるようになりました。 既存の auditlog
テーブルをハイパーテーブルにアップグレードするには、TimescaleDB スキーマのアップグレード を参照してください。
MySQL automatically rebuilds indexes for the primary key during the ALTER TABLE
operation. However, it is highly recommended to also manually rebuild indexes with the OPTIMIZE TABLE
statement to ensure optimal database performance.
Rebuilding indexes may temporarily require as much additional disk space as the table itself uses. To obtain the current size of data and indexes, you can execute the following statements:
If the available disk space is a concern, follow the Altering primary key without downtime instructions. Other options are also available:
sort_buffer_size
MySQL parameter may help to reduce disk space usage when manually rebuilding indexes. However, modifying this variable may impact overall memory usage of the database.1. 現在の auditlog
テーブルの主キーを削除し、新しい主キーを追加します。
2. インデックスを再構築します(オプション設定ですが、強く推奨します。インデックスの再構築に関する重要な注意事項を参照してください)
Manual method of altering the primary key is described here. Alternatively, you can use the pt-online-schema-change toolkit from Percona. This toolkit performs the following actions automatically, while also minimizing the space used for altering the auditlog
table.
1. Create a new table with the new primary key and create indexes.
CREATE TABLE `auditlog_new` (
`auditid` varchar(25) NOT NULL,
`userid` bigint unsigned NULL,
`username` varchar(100) DEFAULT '' NOT NULL,
`clock` integer DEFAULT '0' NOT NULL,
`ip` varchar(39) DEFAULT '' NOT NULL,
`action` integer DEFAULT '0' NOT NULL,
`resourcetype` integer DEFAULT '0' NOT NULL,
`resourceid` bigint unsigned NULL,
`resource_cuid` varchar(25) NULL,
`resourcename` varchar(255) DEFAULT '' NOT NULL,
`recordsetid` varchar(25) NOT NULL,
`details` longtext NOT NULL,
PRIMARY KEY (auditid,clock)
) ENGINE=InnoDB;
CREATE INDEX `auditlog_1` ON `auditlog_new` (`userid`,`clock`);
CREATE INDEX `auditlog_2` ON `auditlog_new` (`clock`);
CREATE INDEX `auditlog_3` ON `auditlog_new` (`resourcetype`,`resourceid`);
2. Swap tables.
3. Copy data from the old table to the new table.
This can be done in chunks (multiple INSERT INTO
statements with WHERE clock
clauses as needed) to avoid excessive resource usage.
4. Drop the old table.
PostgreSQL automatically rebuilds indexes for the primary key during the ALTER TABLE
operation. However, it is highly recommended to also manually rebuild indexes with the REINDEX TABLE CONCURRENTLY
statement to ensure optimal database performance.
Rebuilding indexes may temporarily require up to three times of disk space currently used by indexes. To obtain the current size of indexes, you can execute the following query:
If the available disk space is a concern, follow the Altering primary key without downtime instructions. Other options are also available:
maintenance_work_mem
PostgreSQL parameter may help to reduce disk space usage when manually rebuilding indexes. However, modifying this variable may impact overall memory usage of the database.temp_tablespaces
PostgreSQL parameter to specify a different tablespace for temporary objects.1. 現在の auditlog
テーブルの主キーを削除し、新しい主キーを追加します。
ALTER TABLE Auditlog DROP CONSTRAINT Auditlog_pkey;
ALTER TABLE Auditlog ADD PRIMARY KEY (auditid,clock);
2. インデックスを再構築します(オプション作業ですが、強く推奨します。インデックスの再構築に関する重要な注意事項を参照してください)
Manual method of altering the primary key is described here. Alternatively, the pg_repack
extension can be considered for creating a new table, copying data, and swapping tables.
1. Create a new table with the new primary key and create indexes.
CREATE TABLE auditlog_new (
auditid varchar(25) NOT NULL,
userid bigint NULL,
username varchar(100) DEFAULT '' NOT NULL,
clock integer DEFAULT '0' NOT NULL,
ip varchar(39) DEFAULT '' NOT NULL,
action integer DEFAULT '0' NOT NULL,
resourcetype integer DEFAULT '0' NOT NULL,
resourceid bigint NULL,
resource_cuid varchar(25) NULL,
resourcename varchar(255) DEFAULT '' NOT NULL,
recordsetid varchar(25) NOT NULL,
details text DEFAULT '' NOT NULL,
PRIMARY KEY (auditid,clock)
);
CREATE INDEX auditlog_new_1 ON auditlog_new (userid,clock);
CREATE INDEX auditlog_new_2 ON auditlog_new (clock);
CREATE INDEX auditlog_new_3 ON auditlog_new (resourcetype,resourceid);
2. Swap tables.
3. Copy data from the old table to the new table.
This can be done in chunks (multiple INSERT INTO
statements with WHERE clock
clauses as needed) to avoid excessive resource usage.
4. Drop the old table.