Traduzido do 日本語 • Ver original Olá.
Desta vez, vou falar principalmente sobre a recuperação de banco de dados mysql (neste blog).
A pessoa responsável
"Parece que Myisam é mais rápido que o innodb em Waordpress, então
Antes de mudar, mexi nos parâmetros do my.cnf do innodb e tentei fazer benchmarks."
Os dados no banco de dados estavam quebrados.
Esqueça o MySQL 5.6, seria mais rápido se você pudesse modificá-lo para usar transações apenas de referência sem usar o MyIsam. (É 5.5)
Não consegui ler os dados do banco de dados e não consegui fazer login na tela de administração do WordPress.
---------------------------------------------------
130528 11:59:24 [ERRO] Tabela do sistema faltando mysql.proxies_priv; por favor, execute mysql_upgrade para criá-la
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_current' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_history' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_history_long' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' setup_consumers' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' setup_instruments' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' setup_timers' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' performance_timers' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' threads' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_summary_by_thread_by_event_name' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_summary_by_instance' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' events_waits_summary_global_by_event_name' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' arquivo_summary_by_event_name' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' arquivo_summary_by_instance' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' mutex_instances' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' rwlock_instances' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' cond_instances' tem a estrutura errada
130528 11:59:24 [ERRO] Tabela nativa 'performance_schema'.' arquivo_instances' tem a estrutura errada
130528 11:59:24 [Nota] Programador de eventos: Carregado 0 eventos
130528 11:59:24 [Nota] /usr/libexec/mysqld: pronto para conexões.
Versão: socket '5.5.30-log': '/var/lib/mysql/mysql.sock' porta: 3306 MySQL Community Server (GPL) por Remi
130528 11:59:50 [ERRO] Não é possível encontrar ou abrir a tabela xxxxxx_db/dl_options de
o dicionário de dados interno do InnoDB por meio do arquivo .frm para o
A tabela existe. Talvez você tenha excluído e recriado dados do InnoDB
mas esqueceram de deletar os arquivos .frm correspondentes
de tabelas InnoDB, ou você moveu arquivos .frm para outro banco de dados?
ou, a tabela contém índices que essa versão do motor
não suporta.
Veja http://dev.mysql.com/doc/refman/5.5/en/innodb-troubleshooting.html
como resolver o problema.);
---------------------------------------------------
Me disseram que havia apenas um arquivo .frm no diretório de dados, mas
O meu .cnf não tinha innodb_file_per_table, então talvez o ibdata1 ou algo assim contenha metadados.
Falando em inconsistências causadas por mexer nos parâmetros do innodb, parece possível mudar o innodb_log_file_size e assim por diante.
Você só vai saber os detalhes quando olhar bem para o tronco, como se fosse lambê-lo.
Situação:
・Há backups desde abril, e não há backups diários.
・As informações de atualização a partir de abril podem ser restauradas do cache e registros web adicionando 4 artigos e usuários.
・A quantidade de dados binários de log é pequena, e os timestamps são recém-cortados e desapareceram, então a recuperação roll-forward parece impossível.
・Todas as tabelas com dados faltantes são innodb e não myisam, então reparar tabela nome da tabela USE_FRM; Não posso fazer nada disso.
・Eu não consigo fazer mysqldump mesmo usando innodb_force_recovery = 6.
・Não tenho tempo para checar logs binários, analisar logs detalhadamente e responder a buscas de erro toda vez, o que é um desperdício de horas-homem.
Então apaguei a tabela, carreguei os dados de abril e, a partir daí, restaurei a mão de obra com o cache armazenado.
À política. (Não posso colocar a tela de administração, então adeus às duas coisas que estavam sendo editadas.) Vou fazer de novo. ）
Conseguiu: [php]ls -l /home/xxxxxx-op/xxxxxx_db.bak.sql.bz2 man bzip2 bunzip2 -c /home/xxxxxx-op/xxxxxx_db.bak.sql.bz2 > /root/xxxxxx_db.bak.sql vi /etc/my.cnf #innodb_force_recovery = 6 service mysqld reiniciar ps -ef|grep mysql netstat -lnpt mysql -u root -p drop banco de dados xxxxxx_db; eliminar desempenho do banco de dados_schema; criar banco de dados xxxxxx_db; mysql -u root -p xxxxxx_db < xxxxxx_db.bak.sql[/php] それからエラーログ大丈夫そうかとサイトの表示確認を。
あとはの更新はキャッシュから復旧しておいてね的な。
Lição desta vez:
Se você está fazendo algo com que não está acostumado, vai precisar fazer backup por enquanto.
Se você tem um blog com poucos usuários como este, a composição é obviamente única, então
É melhor fazer backups todos os dias porque eles podem ser feitos a qualquer momento.
(Se for para fins de serviço, consistência, códigos de caractere, etc., serão considerados de madrugada, etc., quando há poucas conexões.)
Se houver mais de duas unidades, é proibido usar a replicação apenas como backup como contramedida contra erros de operação.
(Porque a replicação também reflete erros.) Adiar intencionalmente a replicação é diferente, mas acho melhor ter um backup. ）
Referência: Nenhuma pessoa que excluiu os dados do banco de dados do cliente por engano