Erro de Chave Duplicada no WordPress: Como Recuperamos o Acesso ao Site de um Cliente
Imagine entrar no seu site WordPress e perceber que não consegue mais fazer login, mesmo tentando todos os caminhos que conhece. Foi exatamente isso que aconteceu com um dos nossos clientes aqui na Saldaris Consultoria. O site parou de aceitar o login dos administradores logo depois de uma mudança de endereço (URL), gerando muita preocupação. Afinal, quem não ficaria preocupado ao perder o acesso ao próprio site?
Se você já passou por uma situação parecida, sabe o quanto pode ser desesperador. Mas calma, há solução – e vamos explicar tudo neste post, passo a passo, de uma forma fácil de entender!
O que aconteceu com o site?
Ao tentar resolver o problema de acesso, o WordPress mostrava uma mensagem de erro estranha no banco de dados: “Entrada ‘0’ duplicada para a chave ‘PRIMARY'” (em inglês: Duplicate entry ‘0’ for key ‘PRIMARY’). Para a maioria das pessoas, esse tipo de mensagem parece um “bicho de sete cabeças”, mas basicamente quer dizer que havia algo errado com a parte interna do site responsável por guardar os dados dos usuários.
Esse problema costuma aparecer quando o site é migrado para outro servidor, ou quando o banco de dados sofre alguma alteração incorreta, corrompendo a estrutura de uma tabela importante chamada wp_usermeta. Essa tabela é fundamental porque armazena informações extras dos usuários, como permissões, preferências e dados de plugins.
Por que isso acontece?
Quando mudamos o site de endereço ou migramos para outro servidor, o WordPress precisa que todas as suas “pecinhas internas” estejam funcionando em harmonia. Se alguma coisa se perde, se corrompe ou é importada de maneira errada, certos recursos do site podem parar de funcionar. No caso do nosso cliente, a tabela do banco de dados que gerencia as informações dos usuários acabou ficando “bagunçada”, impedindo o login de qualquer administrador.
Posso resolver isso sozinho?
Se você não tem costume de lidar com bancos de dados ou não sabe o que são tabelas e colunas, o ideal é pedir ajuda a um especialista, porque o risco de piorar a situação é grande. Muitas vezes, tentar corrigir “no susto” pode gerar perda de dados importantes. Por isso, sempre recomendamos ter um backup do site antes de qualquer procedimento.
Agora, se você gosta de entender o que está acontecendo ou quer passar instruções detalhadas para o suporte técnico, veja a seguir como resolvemos esse caso na prática.
A partir daqui: explicação técnica para quem quer saber como resolvemos
O procedimento envolve acesso direto ao banco de dados do WordPress. Portanto, é indicado para quem tem conhecimento técnico ou trabalha com suporte. Se não é o seu caso, não se preocupe: basta acionar a equipe da Saldaris que resolvemos tudo para você, de forma segura.
Procedimento para resolução do problema:
- Fizemos backup completo da tabela wp_usermeta.Antes de qualquer alteração, exportamos a tabela
wp_usermetasem a colunaumeta_id. Isso pode ser feito pelo phpMyAdmin, Adminer ou via linha de comando MySQL:
SELECT user_id, meta_key, meta_value
FROM wp_usermeta
INTO OUTFILE '/tmp/usermeta_backup.csv'
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n';
(A sintaxe exata pode variar conforme o seu banco de dados, mas a ideia é salvar todos os dados, menos o campo com problema.) - Removemos a tabela antiga.Para garantir que nenhum resquício do erro permanecesse, a tabela foi excluída:
DROP TABLE wp_usermeta;
Importante: só faça isso se tiver certeza de que o backup está funcional! - Recriamos a tabela com a estrutura correta.O comando padrão do WordPress (pode variar o prefixo
wp_):
CREATE TABLE wp_usermeta (
umeta_id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
user_id bigint(20) unsigned NOT NULL DEFAULT '0',
meta_key varchar(255) DEFAULT NULL,
meta_value longtext,
PRIMARY KEY (umeta_id),
KEY user_id (user_id),
KEY meta_key (meta_key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
(Se sua instalação erautf8, pode ajustar no CHARSET.) ou aproveite e deixe atualizado para utf8mb4, saiba o por quê. - Importamos os dados de volta, sem o campo umeta_id.No phpMyAdmin, Adminer ou linha de comando, foi feita a importação dos dados salvos, deixando o banco criar novos valores únicos para o campo
umeta_id.Exemplos:- No phpMyAdmin: use a função “Importar” e selecione seu arquivo CSV, mapeando apenas
user_id, meta_key, meta_value. - No MySQL CLI, usando arquivo CSV:
LOAD DATA INFILE '/tmp/usermeta_backup.csv'
INTO TABLE wp_usermeta
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n'
(user_id, meta_key, meta_value);
- No phpMyAdmin: use a função “Importar” e selecione seu arquivo CSV, mapeando apenas
- Recriamos os índices da tabela.Caso algum índice extra usado por plugins fosse necessário, os comandos seriam, por exemplo:
ALTER TABLE wp_usermeta ADD KEY meta_key (meta_key);
ALTER TABLE wp_usermeta ADD KEY user_id (user_id);
(Na maioria dos casos, a estrutura padrão já é suficiente.)
Após esse processo, o site voltou a funcionar normalmente, inclusive permitindo o login dos administradores e mantendo todos os dados dos usuários intactos.
Evite dores de cabeça: como a Saldaris pode ajudar
Problemas com banco de dados podem acontecer a qualquer momento, seja por migração, atualizações ou até ações de terceiros. O importante é não entrar em pânico: quase sempre há solução! Na Saldaris Consultoria, trabalhamos diariamente com a recuperação de sites, ajustes de banco de dados e todo tipo de suporte para WordPress e outros sistemas web.
Se o seu site apresentou erros de acesso, mensagens estranhas ou simplesmente parou de funcionar depois de uma mudança, entre em contato conosco. Nossa equipe pode analisar seu caso sem compromisso e indicar a melhor solução.
Envie uma mensagem pelo formulário abaixo e saiba como podemos ajudar você a recuperar o acesso ao seu site!
Erro: Formulário de contato não encontrado.


