Descobri que talvez haja uma maneira mais legal de resolver esse problema trabalhando em tabelas particionadas. Eu precisava descartar partições de alguns anos atrás e tive que adicionar algumas para 2014. Quase todas as partições relatam esse erro, também as antigas. Acidente muito desagradável.
Portanto, enquanto DROPPING antiga e usando REORGANIZE da partição MAXVALUE (a última), ela criará novos arquivos que estão bem, então recebo cada vez menos avisos. Enquanto isso, ajuda a incrementar o contador de sequência de log, portanto, não preciso inserir dados falsos. Eu tenho isso acontecendo em um servidor mestre btw ...
Então, é isso:
ALTER TABLE Events DROP PARTITION p1530 , p1535 , p1540 , p1545 ,
p1550, p1555 , p1560 , p1565 , p1570 , p1575 , p1580 , p1585 , p1590 ,
p1595 , p1600 , p1605 , p1610 , p1615 , p1620 , p1625 , p1630 , p1635 ,
p1640 , p1645 , p1650 , p1655 , p1660 , p1665 , p1670 , p1675 , p1680 ,
p1685 , p1690 , p1695 , p1700 , p1705 , p1710 , p1715 , p1720 , p1725 ,
p1730 , p1735 , p1740 , p1745 , p1750 , p1755 , p1760 , p1765 , p1770 ,
p1775 , p1780 , p1785 , p1790 , p1795 , p1800 , p1805 , p1810 , p1815 ,
p1820 , p1825 , p1830 , p1835 , p1840;
E isto:
ALTER table Events REORGANIZE PARTITION p3000 INTO (
PARTITION p3500 VALUES LESS THAN (TO_DAYS('2013-01-01')),
PARTITION p3510 VALUES LESS THAN (TO_DAYS('2013-01-04')),
PARTITION p3520 VALUES LESS THAN (TO_DAYS('2013-01-07')),
PARTITION p3530 VALUES LESS THAN (TO_DAYS('2013-01-10'))
...
PARTITION p4740 VALUES LESS THAN (TO_DAYS('2014-01-08')),
PARTITION p9000 VALUES LESS THAN MAXVALUE)
Isso eliminará efetivamente cada partição da mudança e a recriará com uma cópia temporária do conteúdo do que estava lá. Você pode fazer isso por tabela, se quiser, meu aplicativo permite que isso aconteça, portanto, não há necessidade de se preocupar com backups sincronizados, etc.
Agora, para o restante da tabela, como não toquei em todas as partições no processo, algumas serão deixadas com o aviso de sequência de log; para aquelas que estão quebradas, mas cobertas por essa ação de reorganização, provavelmente executarei o seguinte:
ALTER TABLE Events REBUILD PARTITION p0, p1;
ou aquilo
ALTER TABLE Events OPTIMIZE PARTITION p0, p1;
Então, isso me fez pensar: você poderia fazer isso com tabelas simples, adicionar partições temporariamente por hash e depois removê-lo (ou mantê-las, eu recomendo fortemente partições).
No entanto, estou usando o mariadb, não o mysql (portanto, o XtraDB)
Talvez isso ajude alguém. Eu ainda estou executando, até agora tudo bem. Mudar o MOTOR parece fazer o trabalho também, então eu o troco entre o MyIsam e eles de volta ao InnoDB.
É bastante lógico, se você mudar ENGINE, a tabela desaparecerá do innodb, portanto não será mais um problema.
ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;
parece funcionar aqui. Posso confirmar algumas coisas nas tabelas particionadas:
- ALTER TABLE xyz ENGINE = O InnoDB é muito lento, para Aria (mariadb) duas vezes mais rápido, mas em geral uma maneira lenta de incrementar o contador de sequência de log
- ALTER TABLE xyz REBUILD PARTITION ALL é a maneira mais rápida de 'consertar' as tabelas e ajudar a incrementar o contador
- ALTER TABLE xyz ANALYZE PARTITION ALL é lento em comparação com o anterior e não reescreve as partições que parecem estar ok. REBUILD garante uma reescrita para um esquema de tabela temporária.
Eu usei os últimos em várias mesas. Os avisos acontecem quando ele tenta abrir os arquivos e há um para cada definição de partição que é aberta com problemas de contador. Hoje quase rolou no balcão hoje para as últimas mesas. Acho que uma vez processado, é necessário liberar os logs binários.
atualização : posso concluir algumas coisas agora que consegui resolver esse problema.
- Minha falha foi causada pela reorganização de partições em uma tabela no formato Aria (MariaDB).
- (para mim) fazer uma reconstrução das partições funcionou melhor e mais rápido para obter o contador de sequências. Alterar o mecanismo é lento e você precisa fazer isso duas vezes para afetar o innodb. alterar para o innoDB é bastante lento vs. para MyIsam ou Aria.
- Atualizei para o MariaDB 5.3 e não para 5.5 (era: 5.2) e funciona bem. Eu acho que há muitos problemas com árias, partições no 5.5 (e erros confirmados) para usar essa combinação.
- Realmente deve haver uma maneira melhor de redefinir o contador de sequência de log.