Saya menemukan mungkin ada cara yang lebih keren untuk menyelesaikan masalah ini dengan bekerja pada tabel yang dipartisi. Saya perlu menghapus partisi dari beberapa tahun yang lalu, dan harus menambahkan beberapa untuk 2014. Hampir semua partisi melaporkan kesalahan ini, begitu juga yang lama. Kecelakaan yang sangat buruk.
Jadi sementara DROPPING lama dan menggunakan REORGANISASI dari partisi MAXVALUE (yang terakhir), itu akan membuat file baru yang ok, jadi saya mendapatkan semakin sedikit peringatan. Sementara itu, ini membantu menambah penghitung urutan log, jadi saya tidak perlu memasukkan data palsu. Saya memiliki ini terjadi pada server master btw ...
Jadi ini:
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;
Dan ini:
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)
Itu akan secara efektif menjatuhkan setiap partisi dalam perubahan dan membuatnya kembali dengan salinan temporer dari konten yang ada di sana. Anda dapat melakukan ini per tabel jika Anda mau, aplikasi saya memungkinkan hal itu terjadi, jadi tidak perlu khawatir tentang cadangan yang disinkronkan dll.
Sekarang untuk sisa tabel, karena saya belum menyentuh semua partisi dalam proses beberapa akan dibiarkan dengan peringatan urutan log, untuk orang-orang yang rusak tapi dan ditutupi oleh tindakan reorganisasi ini saya mungkin akan menjalankan ini:
ALTER TABLE Events REBUILD PARTITION p0, p1;
atau itu
ALTER TABLE Events OPTIMIZE PARTITION p0, p1;
Jadi, itu membuat saya berpikir, Anda bisa melakukan ini dengan tabel vanilla biasa, menambahkan sementara partisi dengan hash dan kemudian menghapusnya (atau menyimpannya, saya sangat merekomendasikan partisi).
Saya menggunakan mariadb, bukan mysql (jadi XtraDB)
Mungkin ini membantu seseorang. Saya masih menjalankannya, sejauh ini sangat bagus. Mengubah ENGINE sepertinya melakukan pekerjaan itu juga, jadi saya membawanya kembali / maju antara MyIsam dan mereka kembali ke InnoDB.
Ini cukup logis, jika Anda mengubah ENGINE, tabel menghilang dari innodb, jadi itu tidak akan menjadi masalah lagi.
ALTER TABLE Events ENGINE=MyISAM;
ALTER TABLE Events ENGINE=InnoDB;
sepertinya bekerja di sini. Saya dapat mengkonfirmasi beberapa hal di tabel yang dipartisi:
- ALTER TABLE xyz ENGINE = InnoDB sangat lambat, untuk Aria (mariadb) dua kali lebih cepat, tetapi secara umum cara yang lambat untuk meningkatkan penghitung urutan log
- ALTER TABLE xyz REBUILD PARTITION ALL adalah cara tercepat untuk 'memperbaiki' tabel dan membantu menambah penghitung
- ALTER TABEL xYZ ANALYZE PARTITION ALL lambat dibandingkan dengan yang sebelumnya dan tidak menulis ulang partisi yang dianggap ok. REBUILD memastikan penulisan ulang skema tabel temp.
Saya menggunakan yang terakhir di beberapa tabel. Peringatan terjadi ketika mencoba membuka file dan ada satu untuk setiap definisi partisi yang dibuka dengan masalah counter. Hampir terguling meja hari ini untuk tabel terakhir. Saya pikir setelah itu semua diproses kita perlu membersihkan log biner.
pembaruan : Saya dapat menyimpulkan beberapa hal sekarang saya berhasil menyelesaikan masalah ini.
- Kecelakaan saya disebabkan oleh reorganisasi partisi di atas meja dalam format Aria (MariaDB).
- (Untuk saya) melakukan pembangunan kembali partisi bekerja yang terbaik dan tercepat untuk mendapatkan urutan counter. Mengubah mesin lambat dan Anda harus melakukannya dua kali untuk mempengaruhi innodb. mengubah ke innoDB cukup lambat vs. ke MyIsam atau Aria.
- Saya memutakhirkan ke MariaDB 5.3 dan tidak ke 5.5 (adalah: 5.2) dan berfungsi dengan baik. Saya pikir ada terlalu banyak masalah dengan aria, partisi di 5.5 (dan bug yang dikonfirmasi) untuk menggunakan kombinasi itu.
- Harus ada cara yang lebih baik untuk mengatur ulang penghitung urutan log.