[comment]: # ({c4cea8a3-5b27abf6})
# 4 Припрема auditlog табеле за партиционисање

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

[comment]: # ({f697fbbd-9f4e8194})
#### Преглед

Неке базе података (на пример, MySQL) захтевају да колона за партиционисање буде део јединственог ограничења табеле.
Стога, да бисте поделили табелу `auditlog` по времену, примарни кључ мора да се промени из `auditid` у композитни кључ `auditid` + `clock`.

Ова секција пружа упутства за промену примарног кључа табеле `auditlog `.

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

[comment]: # ({496f4662-399f6b3f})
::: noteimportant
Упутства наведена на овој страници су намењена напредним корисникцима.
Имајте на уму да ће ова упутства можда морати да се прилагоде вашој специфичној конфигурацији.
Промена примарног кључа такође може бити некомпатибилна са будућим закрпама за надоградњу, тако да може бити потребно ручно руковање будућим надоградњама.
<br><br>
Промена примарног кључа може бити операција која захтева много ресурса и која захтева много времена у зависности од величине табеле `auditlog `.
Препоручује се заустављање Zabbix сервера и пребацивање Zabbix корисничког интерфејса на [режим одржавања](/manual/web_interface/maintenance_mode) за време промене.
Међутим, ако је апсолутно неопходно, постоји начин да се промени примарни кључ без прекида рада (погледајте доле).
:::

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

[comment]: # ({388a49dd-762f2fc8})
Партиционисање табеле `auditlog` може побољшати, на пример, одржавање система у великим подешавањима.
Иако Zabbix [housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping) тренутно не може да искористи предности партиционисаних табела (осим за TimescaleDB), можете онемогућити Zabbix одржавање система и обрисати партиције помоћу скрипти.

Од Zabbix-а 7.0, табела `auditlog` за TimescaleDB је конвертована у хипертабелу, што омогућава housekeeper-у да одбацује податке по деловима.
Да бисте надоградили постојећу табелу `auditlog` на хипертабелу, поново покрените скрипту `postgresql/timescaledb/schema.sql` пре покретања Zabbix сервера.
Zabbix сервер ће пријавити упозорење ако се покрене без претходног покретања ове скрипте.
Видите такође: [TimescaleDB подешавање](/manual/appendix/install/timescaledb#configuration).

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

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

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

[comment]: # ({4c0f4fb7-e752da32})
##### Важне напомене о реконструкцији индекса

MySQL аутоматски реконструкцира индексе за примарни кључ током операције `ALTER TABLE`. Међутим, топло се препоручује да се индекси ручно реконструкцирају помоћу наредбе `OPTIMIZE TABLE` како би се осигурале оптималне перформансе базе података.

Реконструкција индекса може привремено захтевати онолико додатног простора на диску колико сама табела користи. Да бисте добили тренутну величину података и индекса, можете извршити следеће наредбе:

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

Ако је расположиви простор на диску проблем, пратите упутства [Altering primary key without downtime](#altering-primary-key-without-downtime).
Доступне су и друге опције:

-   Повећање параметра [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) MySQL може помоћи у смањењу коришћења простора на диску приликом ручне реконструкције индекса.
   Међутим, модификовање ове променљиве може утицати на укупну меморију коришћење базе података.
   - Размислите о ослобађању простора брисањем потенцијално непотребних података.
-   Размислите о смањењу параметра *Период чувања података* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) пре него што извршите функцију housekeeper.

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

[comment]: # ({e102e75a-e0cfde87})
##### Измена примарног кључа уз застоје

1\. Обришите тренутни примарни кључ табеле `auditlog` и додајте нови примарни кључ.

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

2\. Поново изградите индексе (опционо, али се веома препоручује, погледајте [Важне напомене о поновној изградњи индекса](#important-notes-on-rebuilding-indexes)).

```sql
OPTIMIZE TABLE auditlog;
```

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

[comment]: # ({0bc984a8-9fb9cdb0})
##### Промена примарног кључа без застоја

Овде је описан ручни метод промене примарног кључа.
Алтернативно, можете користити комплет алата [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) од Перконе. Овај комплет алата аутоматски обавља следеће радње, а истовремено минимизира простор који се користи за промену табеле `auditlog`.

1\. Направите нову табелу са новим примарним кључем и креирајте индексе.

```sql
CREATE TABLE `auditlog_new` (
   `auditid`varchar(25)NOT NULL,
   `userid`bigint unsignedNULL,
   `username`varchar(100)DEFAULT ''NOT NULL,
   `clock`integerDEFAULT '0'NOT NULL,
   `ip`varchar(39)DEFAULT ''NOT NULL,
   `action`integerDEFAULT '0'NOT NULL,
   `resourcetype`integerDEFAULT '0'NOT NULL,
   `resourceid` bigint unsignedNULL,`
     resource_cuid`varchar(25)NULL,
   `resourcename`varchar(255)DEFAULT ''NOT NULL,
   `recordsetid`varchar(25)NOT NULL,
   `details`longtextNOT NULL,
   PRIMARY KEY (аудитид,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\. Замена табела.

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

3\. Копирање података из старе табеле у нову табелу.

```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```

Ово се може урадити у деловима (више `INSERT INTO` наредби са `WHERE clock` клаузулама по потреби) како би се избегла прекомерна употреба ресурса.

4\. Одбаците стару табелу.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/0bc984a8-9fb9cdb0})

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

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

[comment]: # ({397137db-30f863e9})
##### Важне напомене о поновном изградњи индекса

PostgreSQL аутоматски поново изграђује индексе за примарни кључ током операције `ALTER TABLE`. Међутим, топло се препоручује да се индекси ручно поново изграде помоћу наредбе `REINDEX TABLE CONCURRENTLY` како би се осигурале оптималне перформансе базе података.

Поновно изградња индекса може привремено захтевати до три пута више простора на диску од онога што тренутно користе индекси.
Да бисте добили тренутну величину индекса, можете извршити следећи упит:

```sql
SELECT pg_size_pretty(pg_indexes_size('auditlog'));
```

Ако је расположиви простор на диску проблем, пратите упутства [Измена примарног кључа без застоја](#altering-primary-key-without-downtime-1).
Доступне су и друге опције:

-   Повећање параметра [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) PostgreSQL може помоћи у смањењу коришћење простора на диску приликом ручног поновног изградње индекса.
   Међутим, измена ове променљиве може утицати на укупно коришћење меморије базе података.
-   Ако имате други диск или табеларни простор са више расположивог простора, можете размотрити промену привремене локације за складиштење за поновно изградњу индекса.
Можете подесити параметар [`temp_tablespaces`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TEMP-TABLESPACES) PostgreSQL-а да бисте навели други табеларни простор за привремене објекте.
- Размислите о ослобађању простора брисањем потенцијално непотребних података.
- Размислите о смањењу параметра *Период складиштења података* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) пре него што извршите housekeeper-а.

[comment]: # ({/397137db-30f863e9})

[comment]: # ({b08f85b7-915b5f5f})
##### Промена примарног кључа са застојем

1\. Уклоните тренутни примарни кључ табеле `auditlog ` и додајте нови примарни кључ.

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

2\. Поново изградите индексе (опционо, али се веомапрепоручује, погледајте [Важне напомене о поновној изградњи индекса](#important-notes-on-rebuilding-indexes-1)).

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

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

[comment]: # ({adcb7248-998c6861})
##### Промена примарног кључа без застоја

Овде је описан ручни метод промене примарног кључа.
Алтернативно, екстензија `pg_repack` може се размотрити за креирање нове табеле, копирање података и замену табела.

1\. Направите нову табелу са новим примарним кључем и креирајте индексе.

```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. Замена табела.

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

3. Копирање података из старе табеле у нову табелу.

```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```

Ово се може урадити у деловима (више `INSERT INTO` наредби са `WHERE clock` клаузулама по потреби) како би се избегла прекомерна употреба ресурса.

4. Одбацивање старе табеле.

```sql
DROP TABLE auditlog_old;
```

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

[comment]: # ({33200567-31083cb3})
#### Такође погледати

-   [Надоградња базе података на примарне кључеве](/manual/appendix/install/db_primary_keys)

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