Depois que meu servidor VM travou completamente, e não sei por que, o MariaDB neste Debian não pode ser iniciado novamente. Conteúdo de error.log
com arquivos de log:
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: The InnoDB memory heap is disabled
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Compressed tables use zlib 1.2.8
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using Linux native AIO
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Using SSE crc32 instructions
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Completed initialization of buffer pool
2019-04-15 0:40:43 139787712552320 [Note] InnoDB: Highest supported file format is Barracuda.
InnoDB: No valid checkpoint found.
InnoDB: A downgrade from MariaDB 10.2.2 or later is not supported.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/error-creating-innodb.html
2019-04-15 0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' init function returned error.
2019-04-15 0:40:43 139787712552320 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-04-15 0:40:43 139787712552320 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-15 0:40:43 139787712552320 [ERROR] Unknown/unsupported storage engine: InnoDB
2019-04-15 0:40:43 139787712552320 [ERROR] Aborting
Duvido que os ibdata1
, ib_logfile0
e ib_logfile1
estejam corrompidos porque encontrei outro thread
onde alguém queria transferir seus bancos de dados de um servidor para outro e a solução foi desligar corretamente o MySQL no servidor antes de transferir os arquivos.
Se eu remover os arquivos de log seguindo outros threads que afirmam que o MySQL / InnoDB pode restaurá-los, o servidor trava também, mas o InnoDB reclama que posso ter perdido a cópia dos arquivos de log. Veja o log aqui (log postado no GitHub, muito longo para o StackExchange)
Se eu também remover ibdata1
, o servidor inicia, mas não consigo acessar os bancos de dados porque "A tabela 'xyz' não existe no mecanismo".
Este tópico menciona que posso restaurar meus dados, mas não posso simplesmente seguir a solução, pois tenho que aplicá-la a mais de 200 tabelas.
Estou usando mysqld Ver 10.1.37-MariaDB-0+deb9u1 for debian-linux-gnu on x86_64 (Debian 9.6)
e usei a configuração padrão do MariaDB para Debian, exceto o seguinte:
[mysqld]
innodb_large_prefix=ON
innodb_file_format=barracuda
innodb_file_per_table=ON
Existe uma maneira de restaurar ou reparar os dados do banco de dados?
PS: Agora o servidor obterá um cron job usando a mysqldump
cada hora para evitar o problema de que o dump mais recente tenha mais de 2 meses ...
Consegui restaurar meus dados com o próprio MySQL, o truque era forçar o InnoDB a recuperar os bancos de dados/tabelas. Veja https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html . Eu precisava usar
innodb_force_recovery = 6
o MySQL para aceitar meus arquivos corrompidos.Apenas uma tabela parece não ser restaurável, parece que esta tabela causou a inconsistência.