Lixeira de tabelas - PolarDB: Central de Documentação do Alibaba Cloud

Instruções DDL como DROP TABLE e DROP DATABASE não podem ser revertidas. Portanto, a exclusão acidental de tabelas pode causar perda permanente de dados. A lixeira de tabelas intercepta essas operações e move as tabelas excluídas para uma área de retenção segura, o que permite recuperá-las antes da remoção definitiva.

Importante

A lixeira de tabelas consome capacidade de armazenamento do cluster, o que gera custos. Defina o período de retenção conforme suas necessidades de recuperação para evitar despesas desnecessárias.

Pré-requisitos

Antes de começar, verifique se o cluster executa uma das seguintes versões de mecanismo. Para consultar a versão, veja Versões do mecanismo.

PolarDB for MySQL 8.0.1 com versão de revisão 8.0.1.1.2 ou posterior
PolarDB for MySQL 8.0.2 com versão de revisão 8.0.2.1.0 ou posterior

Como funciona

Ao executar DROP TABLE ou DROP DATABASE, o PolarDB intercepta a operação e move os objetos da tabela para o banco de dados de sistema __recycle_bin__, em vez de excluí-los permanentemente. Esse processo segue o comportamento abaixo:

Triggers e chaves estrangeiras são excluídos e não reciclados.
Estatísticas de colunas são movidas para a lixeira junto com a tabela.
Objetos não relacionados à tabela excluída não são reciclados. A retenção depende da instrução específica executada.

Para evitar conflitos de nomes quando tabelas de diferentes bancos de dados são movidas para o mesmo banco de dados __recycle_bin__, o PolarDB renomeia cada tabela reciclada usando o seguinte formato:

"__" + <storage engine name> + <SE private ID>

No InnoDB, o SE private ID corresponde ao table_id. Por exemplo, uma tabela InnoDB reciclada pode receber o nome __innodb_1063.

A remoção definitiva ocorre automaticamente em segundo plano. Um thread em background remove de forma assíncrona as tabelas que permanecem na lixeira além do período definido por loose_recycle_bin_retention. Para tabelas grandes, um thread separado gerencia a limpeza para evitar o bloqueio de outras operações.

Reciclagem independente: nós primários e nós somente leitura mantêm lixeiras separadas, com períodos de retenção independentes. É possível configurar, por exemplo, 7 dias de retenção para o nó primário e 14 dias para os nós somente leitura.

Considerações

Na inicialização de um cluster PolarDB, um banco de dados chamado __recycle_bin__ é criado como banco de dados da lixeira. O banco de dados __recycle_bin__ é um banco de dados de sistema e não pode ser modificado ou excluído.
Não execute DROP TABLE diretamente nas tabelas da lixeira. Use call dbms_recycle.purge_table('table_name') para remover manualmente uma tabela específica.
Para remover tabelas definitivamente, sua conta precisa ter a permissão DROP tanto nas tabelas originais quanto nas tabelas da lixeira.
Se o banco de dados __recycle_bin__ e as tabelas a serem recicladas estiverem em sistemas de arquivos diferentes, a instrução DROP TABLE moverá arquivos entre tablespaces, o que pode consumir bastante tempo.
Caso as tabelas a reciclar estejam em um tablespace geral que armazena múltiplas tabelas, apenas os dados da tabela individual serão reciclados; os arquivos do tablespace não serão movidos.

Faturamento

A lixeira de tabelas utiliza a capacidade de armazenamento do cluster, gerando custos. Para detalhes sobre preços, consulte Regras de faturamento para armazenamento.

Ativar a lixeira de tabelas

Configure os parâmetros a seguir para ativar e ajustar a lixeira de tabelas.

Parâmetro	Escopo	Padrão	Valores válidos	Descrição
`loose_recycle_bin`	Global e sessão	OFF	ON, OFF	Ativa ou desativa a lixeira de tabelas.
`loose_recycle_scheduler`	Global	OFF	ON, OFF	Controla o thread em background responsável pela remoção automática de tabelas após o período de retenção. Quando definido como OFF, o parâmetro `loose_recycle_bin_retention` é ignorado e a limpeza automática de dados não ocorre.
`loose_recycle_bin_retention`	Global	604800 (7 dias)	86400–1209600 (segundos)	Período máximo de retenção dos dados na lixeira. 604800 equivale a 7 dias; 1209600 equivale a 14 dias. Este parâmetro só tem efeito quando `loose_recycle_scheduler` está definido como ON.

Ative tanto loose_recycle_bin quanto loose_recycle_scheduler para garantir a remoção automática das tabelas após o período de retenção. Sem a limpeza automática ativada, os dados reciclados se acumulam e geram custos contínuos de armazenamento.

Gerenciar tabelas na lixeira

O PolarDB oferece três stored procedures no pacote dbms_recycle para gerenciar tabelas recicladas.

Listar tabelas na lixeira

Execute a instrução abaixo para visualizar todas as tabelas presentes na lixeira:

call dbms_recycle.show_tables();

Exemplo de saída:

+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| SCHEMA          | TABLE         | ORIGIN_SCHEMA | ORIGIN_TABLE | RECYCLED_TIME       | PURGE_TIME          |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
| __recycle_bin__ | __innodb_1063 | product_db    | t1           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1064 | product_db    | t2           | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1065 | product_db    | parent       | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
| __recycle_bin__ | __innodb_1066 | product_db    | child        | 2019-08-08 11:01:46 | 2019-08-15 11:01:46 |
+-----------------+---------------+---------------+--------------+---------------------+---------------------+
4 rows in set (0.00 sec)

As colunas da saída são:

Coluna	Descrição
`SCHEMA`	Schema da lixeira (`__recycle_bin__`).
`TABLE`	Nome renomeado da tabela conforme aparece na lixeira.
`ORIGIN_SCHEMA`	Schema original ao qual a tabela pertencia antes da exclusão.
`ORIGIN_TABLE`	Nome original da tabela.
`RECYCLED_TIME`	Momento em que a tabela foi movida para a lixeira.
`PURGE_TIME`	Estimativa de quando a tabela será removida automaticamente.

Restaurar uma tabela da lixeira

Execute a instrução a seguir para restaurar uma tabela reciclada para um banco de dados e nome de tabela específicos:

call dbms_recycle.restore_table('RECYCLE_TABLE', 'DEST_DB', 'DEST_TABLE');

Parâmetro	Descrição
`RECYCLE_TABLE`	Nome da tabela na lixeira (por exemplo, `__innodb_1063`). Se apenas este parâmetro for especificado, os dados da tabela original serão restaurados.
`DEST_DB`	Banco de dados de destino.
`DEST_TABLE`	Novo nome para a tabela restaurada.

Exemplo: restaure __innodb_1063 no banco de dados testDB com o nome testTable:

call dbms_recycle.restore_table('__innodb_1063', 'testDB', 'testTable');

O procedimento restore_table tem suporte apenas no PolarDB for MySQL 8.0 Cluster Edition com versão de revisão 8.0.1.1.12 ou posterior. Para verificar sua versão, consulte Consultar a versão do mecanismo . Sua conta deve ter as permissões ALTER_ACL e DROP_ACL no banco de dados __recycle_bin__ , além das permissões CREATE_ACL e INSERT_ACL na tabela de destino.

Remover uma tabela da lixeira

Execute a instrução abaixo para excluir permanentemente uma tabela específica da lixeira antes do fim do período de retenção:

call dbms_recycle.purge_table('TABLE_NAME');

TABLE_NAME refere-se ao nome da tabela conforme exibido na lixeira (não ao nome original da tabela).

Exemplo: exclua permanentemente __innodb_1063:

call dbms_recycle.purge_table('__innodb_1063');

Sua conta precisa ter a permissão DROP tanto na tabela original quanto na tabela presente na lixeira.

Próximos passos

Em caso de dúvidas sobre operações DDL, entre em contato conosco.