[comment]: # ({c4cea8a3-5b27abf6})
# 4 Vorbereitung der auditlog-Tabelle für die Partitionierung

[comment]: # ({/c4cea8a3-5b27abf6})

[comment]: # ({f697fbbd-9f4e8194})
#### Ü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`.

[comment]: # ({/f697fbbd-9f4e8194})

[comment]: # ({496f4662-399f6b3f})
::: noteimportant
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.
<br><br>
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](/manual/web_interface/maintenance_mode) zu versetzen.
Falls jedoch unbedingt erforderlich, gibt es eine Möglichkeit, den Primärschlüssel ohne Ausfallzeit zu ändern (siehe unten).
:::

[comment]: # ({/496f4662-399f6b3f})

[comment]: # ({388a49dd-762f2fc8})
Die Partitionierung der Tabelle `auditlog` kann beispielsweise das Housekeeping in großen Umgebungen verbessern.
Obwohl das Zabbix-[Housekeeping](/manual/web_interface/frontend_sections/administration/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](/manual/appendix/install/timescaledb#upgrading-timescaledb-schema).

[comment]: # ({/388a49dd-762f2fc8})

[comment]: # ({073b5bd5-271b9416})
#### MySQL

[comment]: # ({/073b5bd5-271b9416})

[comment]: # ({f576f708-e752da32})
##### Wichtige Hinweise zum Neuerstellen von Indizes {#important-notes-on-rebuilding-indexes-1}

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:

```sql
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](#altering-primary-key-without-downtime-1).
Es stehen auch weitere Optionen zur Verfügung:

-   Eine Erhöhung des MySQL-Parameters [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) 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](/manual/web_interface/frontend_sections/administration/housekeeping#overview) vor dem Ausführen des Housekeepers zu verringern.

[comment]: # ({/f576f708-e752da32})

[comment]: # ({de2a0c3b-e0cfde87})
##### Ändern des Primärschlüssels mit Ausfallzeit {#altering-primary-key-with-downtime-1}

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

```sql
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](#important-notes-on-rebuilding-indexes-1)).

```sql
OPTIMIZE TABLE auditlog;
```

[comment]: # ({/de2a0c3b-e0cfde87})

[comment]: # ({19b5a6ba-9fb9cdb0})
##### Ändern des Primärschlüssels ohne Ausfallzeit {#altering-primary-key-without-downtime-1}

Die manuelle Methode zum Ändern des Primärschlüssels wird hier beschrieben.
Alternativ können Sie das Toolkit [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) 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.

```sql
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.

```sql
RENAME TABLE auditlog TO auditlog_old, auditlog_new TO auditlog;
```

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

```sql
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.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/19b5a6ba-9fb9cdb0})

[comment]: # ({dc8ac96e-381b1eee})
#### PostgreSQL

[comment]: # ({/dc8ac96e-381b1eee})

[comment]: # ({64d2938a-30f863e9})
##### Wichtige Hinweise zum Neuerstellen von Indizes {#important-notes-on-rebuilding-indexes-2}

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:

```sql
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](#altering-primary-key-without-downtime-2).
Es sind auch andere Optionen verfügbar:

-   Eine Erhöhung des PostgreSQL-Parameters [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-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`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-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](/manual/web_interface/frontend_sections/administration/housekeeping#overview) vor der Ausführung des Housekeepers zu verringern.

[comment]: # ({/64d2938a-30f863e9})

[comment]: # ({18dc0642-915b5f5f})
##### Ändern des Primärschlüssels mit Ausfallzeit {#altering-primary-key-with-downtime-2}

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

```sql
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](#important-notes-on-rebuilding-indexes-2)).

```sql
REINDEX TABLE CONCURRENTLY auditlog;
```

[comment]: # ({/18dc0642-915b5f5f})

[comment]: # ({ab7f639c-998c6861})
##### Ändern des Primärschlüssels ohne Ausfallzeit {#altering-primary-key-without-downtime-2}

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.

```sql
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.

```sql
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.

```sql
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.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/ab7f639c-998c6861})

[comment]: # ({33200567-31083cb3})
#### Siehe auch

-   [Datenbank-Upgrade auf Primärschlüssel](/manual/appendix/install/db_primary_keys)

[comment]: # ({/33200567-31083cb3})