Tobia's questions

Estou usando uma replicação Galera e um MaxScale readwriterouter.

Estou enfrentando um problema porque o aplicativo foi desenvolvido com este fluxo:

1. iniciar transação
2. atualizar um registro
3. comprometer-se
4. leia esse registro

O resultado é que o registro é atualizado usando o servidor de gravação e a próxima leitura é feita no servidor de leitura. Ele não obtém os dados que acabaram de ser atualizados devido ao atraso de replicação.

Infelizmente, é um pouco difícil refatorar todo o aplicativo e estou procurando se existe alguma solução para forçar uma leitura no servidor de gravação para que eu possa ter certeza de obter os dados que acabaram de ser atualizados.

Eu tenho um aplicativo rodando em um sistema x86 com banco de dados MySQL InnoDB. Este aplicativo armazena muitas linhas por dia e ontem, devido a uma falha de energia, experimentei uma reversão de um dia inteiro de dados. Simplesmente tenho um buraco de dados do dia anterior à falha de energia e tenho certeza de que havia muitos dados antes da falha de energia porque verifiquei os dumps de backup.

Como pode uma falha de energia envolvendo dados comprometidos e tantas linhas? É por causa da estrutura de log do innodb? Posso fazer algo na configuração do MySQL (esperar evitar falhas de energia)?

Minha configuração é um padrão padrão do instalador mysql no ambiente Windows x64 7.

Encontrei uma reversão de 6 dias em uma instalação do servidor MySQL 5.6 community edition. Parece que alguns logs foram perdidos e não consigo entender o porquê.

2013-12-22 20:38:54 380 [Note] Plugin 'FEDERATED' is disabled.
2013-12-22 20:38:54 380 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2013-12-22 20:38:54 388 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-12-22 20:38:54 380 [Note] InnoDB: The InnoDB memory heap is disabled
2013-12-22 20:38:54 380 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-12-22 20:38:54 380 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-12-22 20:38:54 380 [Note] InnoDB: Not using CPU crc32 instructions
2013-12-22 20:38:54 380 [Note] InnoDB: Initializing buffer pool, size = 86.0M
2013-12-22 20:38:54 380 [Note] InnoDB: Completed initialization of buffer pool
2013-12-22 20:38:54 380 [Note] InnoDB: Highest supported file format is Barracuda.
2013-12-22 20:38:54 380 [Note] InnoDB: The log sequence numbers 5988825 and 5988825 in ibdata files do not match the log sequence number 6057379 in the ib_logfiles!
2013-12-22 20:38:54 380 [Note] InnoDB: Database was not shutdown normally!
2013-12-22 20:38:54 380 [Note] InnoDB: Starting crash recovery.
2013-12-22 20:38:54 380 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-12-22 20:38:57 380 [Note] InnoDB: Restoring possible half-written data pages 
2013-12-22 20:38:57 380 [Note] InnoDB: from the doublewrite buffer...
2013-12-22 20:39:07 380 [Note] InnoDB: 128 rollback segment(s) are active.
2013-12-22 20:39:07 380 [Note] InnoDB: Waiting for purge to start
2013-12-22 20:39:07 380 [Note] InnoDB: 5.6.13 started; log sequence number 6057379
2013-12-22 20:39:07 380 [Note] Server hostname (bind-address): '*'; port: 3306
2013-12-22 20:39:07 380 [Note] IPv6 is available.
2013-12-22 20:39:07 380 [Note]   - '::' resolves to '::';
2013-12-22 20:39:07 380 [Note] Server socket created on IP: '::'.
2013-12-22 20:39:12 380 [Note] Event Scheduler: Loaded 0 events
2013-12-22 20:39:12 380 [Note] C:/Program Files/MySQL/MySQL Server 5.6/bin\mysqld: ready for connections.

Você pode me dizer por que isso ocorre e como restaurar esses dados? É possível? Você acha que as tabelas MyISAM são mais seguras e um switch poderia resolver esse tipo de erro?

EDITAR

Mais informações sobre este puzzle.

• Esta máquina possui um volume RAID-1.

• O problema ocorreu após um desligamento em 22 de dezembro . Após esse desligamento, obtive o log anterior e meu banco de dados teve uma reversão de dados de muitos dias. Encontrei o banco de dados exatamente com dados de 14 de dezembro.

• De 14 a 21 de dezembro , houve muitos desligamentos graciosos de servidores (todas as noites) e encontrei um backup completo para todos os dias de 14 a 21 de dezembro. O backup de 22 de dezembro tem o intervalo de dados de 8 dias.

Eu acho isso muito estranho. Eu posso entender a perda de dados após um poweroff, mas não consigo entender essa reversão tão grande (8 dias) porque durante esses 8 dias houve muitos desligamentos do servidor e o backup do mysqldump confirma que todos os dados foram armazenados corretamente. Eu suponho que havia um problema de liberação de log do innodb, mas por que tão grande?

Obrigado