Ho scoperto che esiste forse un modo migliore per risolvere questo problema lavorando su tabelle partizionate. Avevo bisogno di eliminare le partizioni da alcuni anni e ne ho aggiunte alcune per il 2014. Quasi tutte le partizioni riportano questo errore, quindi anche quelle vecchie. Incidente molto brutto.
Quindi, mentre DROPPING vecchio e usando REORGANIZE della partizione MAXVALUE (l'ultima), creerà nuovi file che sono ok, quindi ricevo sempre meno avvisi. Nel frattempo, aiuta ad aumentare il contatore della sequenza di log, quindi non ho bisogno di inserire dati fasulli. Ho questo che succede su un server master tra ...
Così questo:
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 questo:
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)
Ciò eliminerà effettivamente ogni partizione nella modifica e la ricrea con una copia temporanea del contenuto di ciò che era presente. Puoi farlo per tabella se vuoi, la mia applicazione lo consente, quindi non devi preoccuparti di backup sincronizzati ecc.
Ora per il resto della tabella, dal momento che non ho toccato tutte le partizioni nel processo alcune verranno lasciate con l'avvertimento della sequenza di registro, per quelle che sono rotte ma e coperte da questa azione di riorganizzazione probabilmente eseguirò questo:
ALTER TABLE Events REBUILD PARTITION p0, p1;
o quello
ALTER TABLE Events OPTIMIZE PARTITION p0, p1;
Quindi, questo mi ha fatto pensare, potresti farlo con semplici tabelle alla vaniglia, aggiungere temporaneamente partizioni per hash e successivamente rimuoverlo (o tenerle, posso consigliare vivamente le partizioni).
Sto usando mariadb comunque, non mysql (quindi XtraDB)
Forse questo aiuta qualcuno. Lo sto ancora eseguendo, finora tutto bene. Anche cambiare ENGINE sembra fare il lavoro, quindi lo porto avanti / indietro tra MyIsam e loro in InnoDB.
È abbastanza logico, se cambi ENGINE, la tabella scompare da innodb, quindi non sarà più un problema.
ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;
sembra funzionare qui. Posso confermare alcune cose su tabelle partizionate:
- ALTER TABLE xyz ENGINE = InnoDB è molto lento, per Aria (mariadb) due volte più veloce, ma in generale un modo lento per aumentare il contatore della sequenza di log
- ALTER TABLE xyz REBUILD PARTITION ALL è il modo più veloce per 'riparare' le tabelle e aiutare ad aumentare il contatore
- ALTER TABLE xyz ANALYZE PARTITION ALL è lentamente confrontato con il primo e non riscrive le partizioni che risultano ok. REBUILD assicura una riscrittura in uno schema di tabella temporanea.
Ho usato gli ultimi su diversi tavoli. Gli avvisi si verificano quando si tenta di aprire i file e ce n'è uno per ogni definizione di partizione che si apre con problemi di contatore. Oggi ho quasi rotolato sul bancone per gli ultimi tavoli. Penso che una volta elaborato sia necessario svuotare i registri binari.
aggiornamento : posso concludere alcune cose ora sono riuscito a risolvere questo problema.
- Il mio crash è stato causato dalla riorganizzazione delle partizioni su un tavolo nel formato Aria (MariaDB).
- (per me) fare una ricostruzione delle partizioni ha funzionato meglio e più velocemente per ottenere il contatore delle sequenze. Modificare il motore è lento e devi farlo due volte per influenzare innodb. la modifica a innoDB è piuttosto lenta rispetto a MyIsam o Aria.
- Ho aggiornato a MariaDB 5.3 e non a 5.5 (era: 5.2) e funziona benissimo. Penso che ci siano troppi problemi con aria, le partizioni in 5.5 (e i bug confermati) per usare quella combinazione.
- Dovrebbe esserci davvero un modo migliore per ripristinare il contatore della sequenza di registro.