[comment]: # ({c4cea8a3-5b27abf6})
# 4 Préparation de la table d'auditlog pour le partitionnement
[comment]: # ({/c4cea8a3-5b27abf6})
[comment]: # ({f697fbbd-9f4e8194})
#### Présentation
Certaines bases de données (par exemple, MySQL) nécessitent que la colonne de partitionnement fasse partie de la contrainte unique de la table.
Par conséquent, pour partitionner la table `auditlog` par heure, la clé primaire doit être modifiée de `auditid` à une clé composite `auditid` + `clock`.
Cette section fournit des instructions pour modifier la clé primaire de la table `auditlog`.
[comment]: # ({/f697fbbd-9f4e8194})
[comment]: # ({496f4662-399f6b3f})
::: noteimportant
Les instructions fournies sur cette page sont destinées aux utilisateurs avancés.
Notez que ces instructions peuvent devoir être ajustées en fonction de votre configuration spécifique.
La modification de la clé primaire peut également être incompatible avec les futurs correctifs de mise à niveau, il peut donc être nécessaire de gérer manuellement les futures mises à niveau.
La modification de la clé primaire peut être une opération gourmande en ressources qui prend beaucoup de temps en fonction de la taille de la table `auditlog`.
Il est recommandé d'arrêter le serveur Zabbix et de basculer l'interface Zabbix en [mode maintenance](/manual/web_interface/maintenance_mode) pendant la durée de la modification.
Cependant, si cela est absolument nécessaire, il existe un moyen de modifier la clé primaire sans interruption de service (voir ci-dessous).
:::
[comment]: # ({/496f4662-399f6b3f})
[comment]: # ({388a49dd-762f2fc8})
Le partitionnement de la table `auditlog` peut améliorer, par exemple, la gestion interne dans les grandes configurations.
Bien que Zabbix [gestion interne](/manual/web_interface/frontend_sections/administration/housekeeping) ne puisse actuellement pas tirer parti des tables partitionnées (à l'exception de TimescaleDB), vous pouvez désactiver la gestion interne Zabbix et supprimer des partitions à l'aide de scripts.
Depuis Zabbix 7.0, la table `auditlog` de TimescaleDB a été convertie en hypertable, ce qui permet au gestionnaire de supprimer des données par blocs.
Pour mettre à niveau la table `auditlog` existante vers une hypertable, voir [Mise à niveau du schéma TimescaleDB](/manual/appendix/install/timescaledb#upgrading-timescaledb-schema).
[comment]: # ({/388a49dd-762f2fc8})
[comment]: # ({073b5bd5-271b9416})
#### MySQL
[comment]: # ({/073b5bd5-271b9416})
[comment]: # ({f576f708-e752da32})
##### Notes importantes sur la reconstruction des index {#important-notes-on-rebuilding-indexes-1}
MySQL reconstruit automatiquement les index de la clé primaire lors de l'opération `ALTER TABLE`.
Cependant, il est fortement recommandé de reconstruire également manuellement les index avec l'instruction `OPTIMIZE TABLE` afin de garantir des performances optimales de la base de données.
La reconstruction des index peut nécessiter temporairement autant d'espace disque supplémentaire que celui utilisé par la table elle-même.
Pour obtenir la taille actuelle des données et des index, vous pouvez exécuter les instructions suivantes :
```sql
ANALYZE TABLE auditlog;
SHOW TABLE STATUS LIKE 'auditlog';
```
Si l'espace disque disponible est une préoccupation, suivez les instructions de [Modification de la clé primaire sans interruption](#altering-primary-key-without-downtime-1).
D'autres options sont également disponibles :
- Augmenter le paramètre MySQL [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) peut aider à réduire l'utilisation de l'espace disque lors de la reconstruction manuelle des index.
Cependant, la modification de cette variable peut avoir un impact sur l'utilisation globale de la mémoire de la base de données.
- Envisagez de libérer de l'espace en supprimant des données potentiellement inutiles.
- Envisagez de réduire le paramètre *Période de stockage des données* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) avant d'exécuter le housekeeper.
[comment]: # ({/f576f708-e752da32})
[comment]: # ({de2a0c3b-e0cfde87})
##### Modification de la clé primaire avec interruption {#altering-primary-key-with-downtime-1}
1\. Supprimez la clé primaire actuelle de la table `auditlog` et ajoutez la nouvelle clé primaire.
```sql
ALTER TABLE auditlog DROP PRIMARY KEY, ADD PRIMARY KEY (auditid, clock);
```
2\. Reconstruisez les index (facultatif, mais fortement recommandé, voir [Notes importantes sur la reconstruction des index](#important-notes-on-rebuilding-indexes-1)).
```sql
OPTIMIZE TABLE auditlog;
```
[comment]: # ({/de2a0c3b-e0cfde87})
[comment]: # ({19b5a6ba-9fb9cdb0})
##### Modification de la clé primaire sans interruption {#altering-primary-key-without-downtime-1}
La méthode manuelle de modification de la clé primaire est décrite ici.
Vous pouvez également utiliser la boîte à outils [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) de Percona.
Cette boîte à outils effectue automatiquement les actions suivantes, tout en minimisant l'espace utilisé pour modifier la table `auditlog`.
1\. Créez une nouvelle table avec la nouvelle clé primaire et créez les index.
```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\. Échangez les tables.
```sql
RENAME TABLE auditlog TO auditlog_old, auditlog_new TO auditlog;
```
3\. Copiez les données de l'ancienne table vers la nouvelle table.
```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```
Cela peut être fait par lots (plusieurs instructions `INSERT INTO` avec des clauses `WHERE clock` selon les besoins) afin d'éviter une consommation excessive de ressources.
4\. Supprimez l'ancienne table.
```sql
DROP TABLE auditlog_old;
```
[comment]: # ({/19b5a6ba-9fb9cdb0})
[comment]: # ({dc8ac96e-381b1eee})
#### PostgreSQL
[comment]: # ({/dc8ac96e-381b1eee})
[comment]: # ({64d2938a-30f863e9})
##### Notes importantes sur la reconstruction des index {#important-notes-on-rebuilding-indexes-2}
PostgreSQL reconstruit automatiquement les index de la clé primaire pendant l'opération `ALTER TABLE`.
Cependant, il est fortement recommandé de reconstruire également manuellement les index avec l'instruction `REINDEX TABLE CONCURRENTLY` afin de garantir des performances optimales de la base de données.
La reconstruction des index peut nécessiter temporairement jusqu'à trois fois l'espace disque actuellement utilisé par les index.
Pour obtenir la taille actuelle des index, vous pouvez exécuter la requête suivante :
```sql
SELECT pg_size_pretty(pg_indexes_size('auditlog'));
```
Si l'espace disque disponible est une préoccupation, suivez les instructions de [Modification de la clé primaire sans interruption](#altering-primary-key-without-downtime-2).
D'autres options sont également disponibles :
- Augmenter le paramètre PostgreSQL [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) peut aider à réduire l'utilisation de l'espace disque lors de la reconstruction manuelle des index.
Cependant, la modification de cette variable peut avoir un impact sur l'utilisation globale de la mémoire de la base de données.
- Si vous disposez d'un autre disque ou d'un tablespace avec davantage d'espace disponible, vous pouvez envisager de modifier l'emplacement de stockage temporaire pour la reconstruction de l'index.
Vous pouvez définir le paramètre PostgreSQL [`temp_tablespaces`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TEMP-TABLESPACES) pour spécifier un autre tablespace pour les objets temporaires.
- Envisagez de libérer de l'espace en supprimant des données potentiellement inutiles.
- Envisagez de réduire le paramètre *Période de stockage des données* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) avant d'exécuter le housekeeper.
[comment]: # ({/64d2938a-30f863e9})
[comment]: # ({18dc0642-915b5f5f})
##### Modification de la clé primaire avec interruption {#altering-primary-key-with-downtime-2}
1\. Supprimez la clé primaire actuelle de la table `auditlog` et ajoutez la nouvelle clé primaire.
```sql
ALTER TABLE auditlog DROP CONSTRAINT auditlog_pkey;
ALTER TABLE auditlog ADD PRIMARY KEY (auditid,clock);
```
2\. Reconstruisez les index (facultatif, mais fortement recommandé, voir [Notes importantes sur la reconstruction des index](#important-notes-on-rebuilding-indexes-2)).
```sql
REINDEX TABLE CONCURRENTLY auditlog;
```
[comment]: # ({/18dc0642-915b5f5f})
[comment]: # ({ab7f639c-998c6861})
##### Modification de la clé primaire sans interruption {#altering-primary-key-without-downtime-2}
La méthode manuelle de modification de la clé primaire est décrite ici.
Vous pouvez également envisager l'extension `pg_repack` pour créer une nouvelle table, copier les données et permuter les tables.
1\. Créez une nouvelle table avec la nouvelle clé primaire et créez les index.
```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\. Permutez les tables.
```sql
ALTER TABLE auditlog RENAME TO auditlog_old;
ALTER TABLE auditlog_new RENAME TO auditlog;
```
3\. Copiez les données de l'ancienne table vers la nouvelle table.
```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```
Cela peut être fait par lots (plusieurs instructions `INSERT INTO` avec des clauses `WHERE clock` selon les besoins) afin d'éviter une consommation excessive de ressources.
4\. Supprimez l'ancienne table.
```sql
DROP TABLE auditlog_old;
```
[comment]: # ({/ab7f639c-998c6861})
[comment]: # ({33200567-31083cb3})
#### Voir aussi
- [Mise à niveau de la base de données vers des clés primaires](/manual/appendix/install/db_primary_keys)
[comment]: # ({/33200567-31083cb3})