Alguns bancos de dados (por exemplo, MySQL) exigem que a coluna de particionamento faça parte da restrição exclusiva da tabela. Portanto, para particionar a tabela auditlog
por tempo, a chave primária deve ser alterada de auditid
para uma chave composta auditid
+ clock
.
Esta seção fornece instruções para alterar a chave primária da tabela auditlog
.
As instruções fornecidas nesta página são destinadas a usuários avançados. Observe que essas instruções podem precisar ser ajustadas para sua configuração específica. Alterar a chave primária também pode ser incompatível com futuros patches de atualização, portanto, pode ser necessário lidar manualmente com futuras atualizações.
Alterar a chave primária pode ser uma operação que consome muitos recursos e leva muito tempo, dependendo do tamanho da tabela auditlog
. Recomenda-se parar o Zabbix server e colocar o Zabbix frontend em modo de manutenção durante a alteração. No entanto, se absolutamente necessário, existe uma maneira de alterar a chave primária sem tempo de inatividade (veja abaixo).
O particionamento da tabela auditlog
pode melhorar, por exemplo, a limpeza em ambientes grandes. Embora o housekeeping do Zabbix atualmente não possa tirar proveito de tabelas particionadas (exceto para TimescaleDB), você pode desabilitar o housekeeping do Zabbix e excluir partições usando scripts.
Desde o Zabbix 7.0, a tabela auditlog
para TimescaleDB foi convertida em uma hypertable, o que permite que o housekeeper exclua dados por chunks. Para atualizar a tabela auditlog
existente para uma hypertable, consulte Atualizando o schema do TimescaleDB.
O MySQL reconstrói automaticamente os índices para a chave primária durante a operação ALTER TABLE
. No entanto, é altamente recomendável também reconstruir manualmente os índices com a instrução OPTIMIZE TABLE
para garantir o desempenho ideal do banco de dados.
A reconstrução de índices pode exigir temporariamente tanto espaço em disco adicional quanto a própria tabela utiliza. Para obter o tamanho atual dos dados e dos índices, você pode executar as seguintes instruções:
Se o espaço disponível em disco for uma preocupação, siga as instruções de Alterando a chave primária sem tempo de inatividade. Outras opções também estão disponíveis:
sort_buffer_size
pode ajudar a reduzir o uso de espaço em disco ao reconstruir manualmente os índices. No entanto, modificar esta variável pode impactar o uso geral de memória do banco de dados.1. Remova a chave primária atual da tabela auditlog
e adicione a nova chave primária.
2. Reconstrua os índices (opcional, mas altamente recomendado, veja Notas importantes sobre reconstrução de índices).
O método manual de alteração da chave primária está descrito aqui. Como alternativa, você pode usar o pt-online-schema-change da Percona. Essa ferramenta executa as seguintes ações automaticamente, minimizando também o espaço utilizado para alterar a tabela auditlog
.
1. Crie uma nova tabela com a nova chave primária e crie os índices.
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. Troque as tabelas.
3. Copie os dados da tabela antiga para a nova tabela.
Isso pode ser feito em partes (várias instruções INSERT INTO
com cláusulas WHERE clock
conforme necessário) para evitar uso excessivo de recursos.
4. Exclua a tabela antiga.
O PostgreSQL reconstrói automaticamente os índices para a chave primária durante a operação ALTER TABLE
. No entanto, é altamente recomendável também reconstruir manualmente os índices com a instrução REINDEX TABLE CONCURRENTLY
para garantir o desempenho ideal do banco de dados.
A reconstrução de índices pode exigir temporariamente até três vezes o espaço em disco atualmente usado pelos índices. Para obter o tamanho atual dos índices, você pode executar a seguinte consulta:
Se o espaço disponível em disco for uma preocupação, siga as instruções de Alterando a chave primária sem tempo de inatividade. Outras opções também estão disponíveis:
maintenance_work_mem
pode ajudar a reduzir o uso de espaço em disco ao reconstruir manualmente os índices. No entanto, modificar esta variável pode impactar o uso geral de memória do banco de dados.temp_tablespaces
para especificar um tablespace diferente para objetos temporários.1. Remova a chave primária atual da tabela auditlog
e adicione a nova chave primária.
ALTER TABLE auditlog DROP CONSTRAINT auditlog_pkey;
ALTER TABLE auditlog ADD PRIMARY KEY (auditid,clock);
2. Reconstrua os índices (opcional, mas altamente recomendado, veja Notas importantes sobre a reconstrução de índices).
O método manual de alteração da chave primária é descrito aqui. Como alternativa, a extensão pg_repack
pode ser considerada para criar uma nova tabela, copiar os dados e trocar as tabelas.
1. Crie uma nova tabela com a nova chave primária e crie os índices.
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. Troque as tabelas.
3. Copie os dados da tabela antiga para a nova tabela.
Isso pode ser feito em partes (múltiplas instruções INSERT INTO
com cláusulas WHERE clock
conforme necessário) para evitar uso excessivo de recursos.
4. Exclua a tabela antiga.