::: 重要このページに記載されている手順は、上級ユーザー向けに設計されています。これらの手順は、お客様の構成に合わせて調整する必要がある場合があります。主キーの変更は、将来のアップグレードパッチと互換性がなくなる可能性があるため、手動でのアップグレードが必要になる場合があります。

主キーの変更は、auditlog テーブルのサイズによっては、多くのリソースを消費し、多くの時間を要する操作となる場合があります。変更中は、Zabbix サーバーを停止し、Zabbix フロントエンドをメンテナンスモードに切り替えることをお勧めします。ただし、どうしても必要な場合は、ダウンタイムなしで主キーを変更する方法があります（下記参照） :::

auditlog テーブルをパーティション分割すると、例えば大規模なシステムにおけるハウスキーピング機能の向上につながります。 Zabbix の housekeeping は現在、パーティション分割されたテーブルを利用できません（TimescaleDB を除く）が、スクリプトを使用して Zabbix ハウスキーピングを無効化し、パーティションを削除することができます。

Zabbix 7.0 以降、TimescaleDB の auditlog テーブルはハイパーテーブルに変換され、ハウスキーパーがデータをチャンク単位で削除できるようになりました。既存の auditlog テーブルをハイパーテーブルにアップグレードするには、TimescaleDB スキーマのアップグレードを参照してください。

MySQL

インデックス再構築に関する重要な注意事項

MySQL は、ALTER TABLE 操作中に主キーのインデックスを自動的に再構築します。ただし、最適なデータベース性能を確保するため、OPTIMIZE TABLE ステートメントを使用してインデックスを手動でも再構築することを強く推奨します。

インデックスの再構築では、一時的にテーブル自体が使用しているのと同程度の追加ディスク領域が必要になる場合があります。データとインデックスの現在のサイズを確認するには、次のステートメントを実行できます。

ANALYZE TABLE auditlog;
SHOW TABLE STATUS LIKE 'auditlog';

利用可能なディスク容量に不安がある場合は、ダウンタイムなしで主キーを変更するの手順に従ってください。他の選択肢もあります。

sort_buffer_size MySQL パラメーターを増やすと、インデックスを手動で再構築する際のディスク使用量を削減できる場合があります。ただし、この変数を変更すると、データベース全体のメモリ使用量に影響する可能性があります。
不要と思われるデータを削除して、空き容量を確保することを検討してください。
housekeeper を実行する前に、データ保存期間 housekeeper パラメーターを短くすることを検討してください。

ダウンタイムを伴う主キーの変更

1. 現在の auditlog テーブルの主キーを削除し、新しい主キーを追加します。

ALTER TABLE auditlog DROP PRIMARY KEY, ADD PRIMARY KEY (auditid, clock);

2. インデックスを再構築します（任意ですが、非常に推奨されます。インデックス再構築に関する重要な注意事項を参照してください）。

OPTIMIZE TABLE auditlog;

ダウンタイムなしで主キーを変更する

主キーを手動で変更する方法については、ここで説明します。
または、Percona の pt-online-schema-change ツールキットを使用することもできます。
このツールキットは、auditlog テーブルの変更に使用する領域を最小限に抑えながら、以下の操作を自動的に実行します。

1. 新しい主キーを持つ新しいテーブルを作成し、インデックスを作成します。

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. テーブルを入れ替えます。

RENAME TABLE auditlog TO auditlog_old, auditlog_new TO auditlog;

3. 古いテーブルから新しいテーブルへデータをコピーします。

INSERT INTO auditlog SELECT * FROM auditlog_old;

必要に応じて clock の WHERE 句を使い、複数の INSERT INTO 文に分けてチャンク単位で実行することで、リソースの過剰な使用を避けることができます。

4. 古いテーブルを削除します。

DROP TABLE auditlog_old;

PostgreSQL

インデックス再構築に関する重要な注意事項

PostgreSQL は、ALTER TABLE 操作中に主キーのインデックスを自動的に再構築します。
ただし、データベースの最適なパフォーマンスを確保するため、REINDEX TABLE CONCURRENTLY ステートメントを使用してインデックスを手動でも再構築することを強く推奨します。

インデックスの再構築では、一時的に現在インデックスで使用されているディスク容量の最大 3 倍が必要になる場合があります。
現在のインデックスサイズを確認するには、次のクエリを実行します。

SELECT pg_size_pretty(pg_indexes_size('auditlog'));

利用可能なディスク容量が懸念される場合は、ダウンタイムなしで主キーを変更するの手順に従ってください。
他にも次の方法があります。

PostgreSQL パラメータ maintenance_work_mem を増やすと、インデックスを手動で再構築する際のディスク使用量を削減できる場合があります。
ただし、この変数を変更すると、データベース全体のメモリ使用量に影響する可能性があります。
より多くの空き容量がある別のディスクまたはテーブルスペースがある場合は、インデックス再構築時の一時ストレージの場所を変更することを検討してください。
PostgreSQL パラメータ temp_tablespaces を設定して、一時オブジェクト用の別のテーブルスペースを指定できます。
不要な可能性のあるデータを削除して、空き容量を確保することを検討してください。
housekeeper を実行する前に、Data storage period housekeeper パラメータを短くすることを検討してください。

ダウンタイムを伴う主キーの変更

1. 現在の auditlog テーブルの主キーを削除し、新しい主キーを追加します。

ALTER TABLE auditlog DROP CONSTRAINT auditlog_pkey;
ALTER TABLE auditlog ADD PRIMARY KEY (auditid,clock);

2. インデックスを再構築します（任意ですが、強く推奨します。インデックス再構築に関する重要な注意事項を参照してください）。

REINDEX TABLE CONCURRENTLY auditlog;

ダウンタイムなしで主キーを変更する

ここでは、主キーを手動で変更する方法を説明します。
代替案として、新しいテーブルの作成、データのコピー、テーブルの入れ替えを行うために pg_repack 拡張を検討できます。

1. 新しい主キーを持つ新しいテーブルを作成し、インデックスを作成します。

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. テーブルを入れ替えます。

ALTER TABLE auditlog RENAME TO auditlog_old;
ALTER TABLE auditlog_new RENAME TO auditlog;

3. 古いテーブルから新しいテーブルへデータをコピーします。

INSERT INTO auditlog SELECT * FROM auditlog_old;

これは、過剰なリソース使用を避けるために、必要に応じて WHERE clock 句を使った複数の INSERT INTO 文に分割して実行できます。

4. 古いテーブルを削除します。

DROP TABLE auditlog_old;

Oracle

インデックス再構築に関する重要な注意事項

Oracle は、ALTER TABLE 操作中に主キーのインデックスを自動的に再構築します。
ただし、最適なデータベース性能を確保するために、ALTER INDEX <index> REBUILD PARALLEL ステートメントを使用してインデックスを手動でも再構築することを強く推奨します。

インデックスの再構築では、一時的に大量のディスク容量が必要になる場合があります。

利用可能なディスク容量に懸念がある場合は、ダウンタイムなしで主キーを変更するの手順に従ってください。
他の選択肢もあります。

Oracle パラメータ SORT_AREA_SIZE を増やすと、インデックスを手動で再構築する際のディスク容量使用量を削減できる場合があります。
ただし、この変数を変更すると、データベース全体のメモリ使用量に影響します。
PARALLEL 句を使用して並列度を設定できます。例: ALTER INDEX auditlog_1 REBUILD PARALLEL 4
不要な可能性のあるデータを削除して、空き容量を確保することを検討してください。
housekeeper を実行する前に、データ保存期間 housekeeper パラメータを短くすることを検討してください。

ダウンタイムを伴う主キーの変更

1. 制約名を取得します。

SELECT CONSTRAINT_NAME FROM all_constraints WHERE TABLE_NAME = 'AUDITLOG' AND CONSTRAINT_TYPE = 'P';

2. 現在の auditlog テーブルの主キーを削除し、新しい主キーを追加します。

ALTER TABLE auditlog DROP CONSTRAINT <constraint_name>;
ALTER TABLE auditlog ADD CONSTRAINT auditlog_pk PRIMARY KEY (auditid, clock);

3. インデックスを再構築します（任意ですが、強く推奨します。インデックス再構築に関する重要な注意事項を参照してください）。

3.1. インデックス名を取得します。

SELECT index_name FROM user_indexes WHERE table_name='AUDITLOG';

3.2. 各インデックスを再構築します。

ALTER INDEX auditlog_pk REBUILD PARALLEL;
ALTER INDEX auditlog_1 REBUILD PARALLEL;
ALTER INDEX auditlog_2 REBUILD PARALLEL;
ALTER INDEX auditlog_3 REBUILD PARALLEL;

ダウンタイムなしで主キーを変更する

1. 新しい主キーを持つ新しいテーブルを作成し、インデックスを作成します。

CREATE TABLE auditlog_new (
  auditid              nvarchar2(25)                             ,
  userid               number(20)                                NULL,
  username             nvarchar2(100)  DEFAULT ''                ,
  clock                number(10)      DEFAULT '0'               NOT NULL,
  ip                   nvarchar2(39)   DEFAULT ''                ,
  action               number(10)      DEFAULT '0'               NOT NULL,
  resourcetype         number(10)      DEFAULT '0'               NOT NULL,
  resourceid           number(20)                                NULL,
  resource_cuid        nvarchar2(25)                             ,
  resourcename         nvarchar2(255)  DEFAULT ''                ,
  recordsetid          nvarchar2(25)                             ,
  details              nclob           DEFAULT ''                ,
  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. テーブルを入れ替えます。

ALTER TABLE auditlog RENAME TO auditlog_old;
ALTER TABLE auditlog_new RENAME TO auditlog;

3. 古いテーブルから新しいテーブルへデータをコピーします。

INSERT INTO auditlog SELECT * FROM auditlog_old;

必要に応じて WHERE clock 句を使い、複数の INSERT INTO 文に分割してチャンク単位で実行することで、リソースの過剰な使用を避けることができます。

4. 古いテーブルを削除します。

DROP TABLE auditlog_old;

What’s next?

5 データベースへの安全な接続

Docs

4 監査ログテーブルのパーティション化の準備

概要

MySQL

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

PostgreSQL

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

Oracle

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

関連項目

What’s next?

Docs

4 監査ログテーブルのパーティション化の準備

概要

MySQL

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

PostgreSQL

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

Oracle

インデックス再構築に関する重要な注意事項

ダウンタイムを伴う主キーの変更

ダウンタイムなしで主キーを変更する

関連項目

What’s next?

Suggest edit

Suggest an example

Thank you!