4 Vorbereitung der auditlog-Tabelle für die Partitionierung

Überblick

Einige Datenbanken (zum Beispiel MySQL) erfordern, dass die Partitionierungsspalte Teil der eindeutigen Einschränkung der Tabelle ist. Daher muss zum Partitionieren der Tabelle auditlog nach Zeit der Primärschlüssel von auditid in einen zusammengesetzten Schlüssel auditid + clock geändert werden.

Dieser Abschnitt enthält Anweisungen zum Ändern des Primärschlüssels der Tabelle auditlog.

Die auf dieser Seite bereitgestellten Anweisungen sind für fortgeschrittene Benutzer gedacht. Beachten Sie, dass diese Anweisungen möglicherweise an Ihre spezifische Konfiguration angepasst werden müssen. Das Ändern des Primärschlüssels kann außerdem mit zukünftigen Upgrade-Patches inkompatibel sein, sodass zukünftige Upgrades möglicherweise manuell durchgeführt werden müssen.

Das Ändern des Primärschlüssels kann je nach Größe der Tabelle auditlog ein ressourcenintensiver und zeitaufwändiger Vorgang sein. Es wird empfohlen, den Zabbix Server anzuhalten und das Zabbix Frontend für die Dauer der Änderung in den Wartungsmodus zu versetzen. Falls jedoch unbedingt erforderlich, gibt es eine Möglichkeit, den Primärschlüssel ohne Ausfallzeit zu ändern (siehe unten).

Die Partitionierung der Tabelle auditlog kann beispielsweise das Housekeeping in großen Umgebungen verbessern. Obwohl das Zabbix-Housekeeping derzeit partitionierte Tabellen nicht nutzen kann (außer bei TimescaleDB), können Sie das Zabbix-Housekeeping deaktivieren und Partitionen mithilfe von Skripten löschen.

Seit Zabbix 7.0 wurde die Tabelle auditlog für TimescaleDB in eine Hypertabelle umgewandelt, wodurch der Housekeeper Daten in Chunks löschen kann. Informationen zum Upgrade der bestehenden Tabelle auditlog auf eine Hypertabelle finden Sie unter Upgrading TimescaleDB schema.

MySQL

Wichtige Hinweise zum Neuerstellen von Indizes

MySQL erstellt Indizes für den Primärschlüssel während der ALTER TABLE-Operation automatisch neu. Es wird jedoch dringend empfohlen, Indizes zusätzlich manuell mit der Anweisung OPTIMIZE TABLE neu zu erstellen, um eine optimale Datenbankleistung sicherzustellen.

Das Neuerstellen von Indizes kann vorübergehend zusätzlichen Speicherplatz auf der Festplatte in einer Größenordnung erfordern, die der von der Tabelle selbst belegten Größe entspricht. Um die aktuelle Größe von Daten und Indizes zu ermitteln, können Sie die folgenden Anweisungen ausführen:

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

Wenn der verfügbare Festplattenspeicher knapp ist, befolgen Sie die Anweisungen unter Primärschlüssel ohne Ausfallzeit ändern. Es stehen auch weitere Optionen zur Verfügung:

  • Eine Erhöhung des MySQL-Parameters sort_buffer_size kann dazu beitragen, den Speicherplatzverbrauch beim manuellen Neuerstellen von Indizes zu verringern. Allerdings kann die Änderung dieser Variable den gesamten Speicherverbrauch der Datenbank beeinflussen.
  • Erwägen Sie, Speicherplatz freizugeben, indem Sie möglicherweise unnötige Daten löschen.
  • Erwägen Sie, den Parameter Datenaufbewahrungszeitraum Housekeeper vor dem Ausführen des Housekeepers zu verringern.
Ändern des Primärschlüssels mit Ausfallzeit

1. Entfernen Sie den aktuellen Primärschlüssel der Tabelle auditlog und fügen Sie den neuen Primärschlüssel hinzu.

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

2. Erstellen Sie die Indizes neu (optional, aber dringend empfohlen, siehe Wichtige Hinweise zum Neuerstellen von Indizes).

OPTIMIZE TABLE auditlog;
Ändern des Primärschlüssels ohne Ausfallzeit

Die manuelle Methode zum Ändern des Primärschlüssels wird hier beschrieben. Alternativ können Sie das Toolkit pt-online-schema-change von Percona verwenden. Dieses Toolkit führt die folgenden Aktionen automatisch aus und minimiert dabei gleichzeitig den Speicherplatz, der für die Änderung der Tabelle auditlog verwendet wird.

1. Erstellen Sie eine neue Tabelle mit dem neuen Primärschlüssel und erstellen Sie Indizes.

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. Tauschen Sie die Tabellen aus.

RENAME TABLE auditlog TO auditlog_old, auditlog_new TO auditlog;

3. Kopieren Sie die Daten von der alten Tabelle in die neue Tabelle.

INSERT INTO auditlog SELECT * FROM auditlog_old;

Dies kann in Blöcken erfolgen (mehrere INSERT INTO-Anweisungen mit WHERE clock-Klauseln nach Bedarf), um eine übermäßige Ressourcennutzung zu vermeiden.

4. Löschen Sie die alte Tabelle.

DROP TABLE auditlog_old;

PostgreSQL

Wichtige Hinweise zum Neuerstellen von Indizes

PostgreSQL erstellt Indizes für den Primärschlüssel während der ALTER TABLE-Operation automatisch neu. Es wird jedoch dringend empfohlen, Indizes auch manuell mit der Anweisung REINDEX TABLE CONCURRENTLY neu zu erstellen, um eine optimale Datenbankleistung sicherzustellen.

Das Neuerstellen von Indizes kann vorübergehend bis zu dem Dreifachen des aktuell von Indizes belegten Speicherplatzes auf dem Datenträger erfordern. Um die aktuelle Größe der Indizes zu ermitteln, können Sie die folgende Abfrage ausführen:

SELECT pg_size_pretty(pg_indexes_size('auditlog'));

Wenn der verfügbare Speicherplatz knapp ist, befolgen Sie die Anweisungen unter Primärschlüssel ohne Ausfallzeit ändern. Es sind auch andere Optionen verfügbar:

  • Eine Erhöhung des PostgreSQL-Parameters maintenance_work_mem kann dazu beitragen, den Speicherplatzverbrauch beim manuellen Neuerstellen von Indizes zu verringern. Allerdings kann die Änderung dieser Variable die gesamte Speichernutzung der Datenbank beeinflussen.
  • Wenn Sie über eine weitere Festplatte oder einen Tablespace mit mehr verfügbarem Speicherplatz verfügen, können Sie den Speicherort für die temporäre Speicherung beim Neuerstellen des Index ändern. Sie können den PostgreSQL-Parameter temp_tablespaces festlegen, um einen anderen Tablespace für temporäre Objekte anzugeben.
  • Erwägen Sie, Speicherplatz freizugeben, indem Sie möglicherweise unnötige Daten löschen.
  • Erwägen Sie, den Parameter Datenaufbewahrungszeitraum Housekeeper vor der Ausführung des Housekeepers zu verringern.
Ändern des Primärschlüssels mit Ausfallzeit

1. Entfernen Sie den aktuellen Primärschlüssel der Tabelle auditlog und fügen Sie den neuen Primärschlüssel hinzu.

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

2. Indizes neu aufbauen (optional, aber dringend empfohlen, siehe Wichtige Hinweise zum Neuerstellen von Indizes).

REINDEX TABLE CONCURRENTLY auditlog;
Ändern des Primärschlüssels ohne Ausfallzeit

Die manuelle Methode zum Ändern des Primärschlüssels wird hier beschrieben. Alternativ kann die Erweiterung pg_repack in Betracht gezogen werden, um eine neue Tabelle zu erstellen, Daten zu kopieren und Tabellen zu tauschen.

1. Erstellen Sie eine neue Tabelle mit dem neuen Primärschlüssel und legen Sie Indizes an.

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. Tauschen Sie die Tabellen aus.

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

3. Kopieren Sie die Daten von der alten Tabelle in die neue Tabelle.

INSERT INTO auditlog SELECT * FROM auditlog_old;

Dies kann in Blöcken erfolgen (bei Bedarf mehrere INSERT INTO-Anweisungen mit WHERE clock-Klauseln), um eine übermäßige Ressourcennutzung zu vermeiden.

4. Löschen Sie die alte Tabelle.

DROP TABLE auditlog_old;

Siehe auch