Saya telah menggunakan PURGE BINARY LOGS dan juga FLUSH LOGS, tetapi direktori mysql masih berisi file-file ini:

mysql-bin.000025
mysql-bin.000024
mysql-bin.000023
mysql-bin.000022
mysql-bin.000021
mysql-bin.000020
mysql-bin.000019
mysql-bin.index

Apakah ada alasan mengapa menggunakan perintah tidak berfungsi? File-file ini memakan banyak ruang. Saya ingin menyingkirkan mereka dengan aman.

The PURGE BINARY LOGSpernyataan menghapus semua file log biner tercantum dalam file indeks log sebelum ditentukan nama file log atau timestamp. File log yang dihapus juga dihapus dari daftar yang direkam dalam file indeks, sehingga file log yang diberikan menjadi yang pertama dalam daftar.

Saya harap Anda telah membersihkan log biner hingga mysql-bin.000019menggunakan perintah

PURGE BINARY LOGS TO 'mysql-bin.000019';

Jika Anda perlu membersihkan semua log suka

PURGE BINARY LOGS TO 'mysql-bin.000025';

Ini akan menghapus log biner hingga mysql-bin.000025.

MEMPERBARUI

Anda dapat mencoba

RESET MASTER;

RESET MASTER Menghapus semua file log biner yang tercantum dalam file indeks, mengatur ulang file indeks log biner menjadi kosong, dan membuat file log biner baru

Efek RESET MASTERberbeda dari efek LOG BINARY PURGE dalam 2 cara utama:

1. RESET MASTER menghapus semua file log biner yang tercantum dalam file indeks, hanya menyisakan satu file log biner kosong dengan akhiran numerik 0,000001, sedangkan penomoran tidak diatur ulang oleh PURGE BINARY LOGS.

2. RESET MASTERtidak dimaksudkan untuk digunakan ketika budak replikasi sedang berjalan. Perilaku RESET MASTERketika digunakan saat budak sedang berjalan tidak ditentukan (dan karenanya tidak didukung), sedangkan PURGE BINARY LOGSdapat digunakan dengan aman saat budak replikasi sedang berjalan.

CAVEAT oleh RolandoMySQLDBA

Jika Anda menjalankan RESET MASTERdengan Budak terhubung dan berjalan, IO Thread dari masing-masing Budak akan segera kehilangan tempatnya. Replikasi dengan demikian rusak dan Anda harus menghabiskan waktu untuk mendapatkan data pada semua Slave disinkronkan lagi. Jika Anda ingin menghapus log biner dengan aman dari Master tanpa merusak integritas Replikasi, inilah yang Anda lakukan:

• Jalankan SHOW SLAVE STATUS\Gpada setiap Slave.
• Perhatikan Relay_Master_Log_File. Ini adalah log biner yang pernyataan terakhirnya berhasil dieksekusi di Slave).
• Dari semua tampilan SHOW SLAVE STATUS\G, tentukan mana Relay_Master_Log_Fileyang tertua (Misalnya, 'mysql-bin.00123').
• Anda dapat menjalankan PURGE BINARY LOGS TO 'mysql-bin.00123';Tidak ada Budak yang akan kehilangan tempatnya.

Efek keseluruhan? Ini akan meninggalkan log biner pada Master yang pernyataannya belum dieksekusi pada semua Slave sampai sekarang.

Saya tidak yakin apakah ini yang terjadi pada Anda, tetapi dalam kasus saya MySQL telah menghentikan log "bersepeda" dan file mysql-bin.index menjadi "rusak" dengan entri file binlog yang tidak valid.

Secara khusus, file indeks sudah mulai di mysql-bin.000001 dan sampai ke mysql-bin.000220 tetapi kemudian entah bagaimana mulai lagi dari 001. Ketika saya membandingkan ini dengan file di server saya, saya dapat melihat bahwa saya memiliki file dari 001 hingga 022.

Awalnya saya mencoba PURGE LOGS TO 'mysql-bin.000022';tetapi ini tidak berhasil.

Pada akhirnya saya menghentikan MySQL dan secara manual mengedit file indeks sampai cocok dengan file yang saya miliki di server saya. Ketika saya me-restart MySQL, itu membersihkan file-file binlog untuk menghormati expire_logs_dayspengaturan dan mulai bekerja secara normal lagi.

Dalam kasus saya PURGE BINARYsama sekali tidak menghapus apa pun.

Saya memiliki partisi saya pada penggunaan 100% (saya harus membersihkan log slowqueries saya sedikit sehingga ada cukup ruang untuk mysql untuk di-restart), jadi hal pertama yang saya lakukan adalah mengubah /etc/my.cnfkomentar baris log-bin=mysql-bin(itu tidak diperlukan di server ini lagi dan saya lupa untuk menghapusnya), dan kemudian saya me-restart mysql (ini diperlukan karena ada pertanyaan yang antri yang mencegah PURGE BINARYdieksekusi).

Setelah itu, saya berlari PURGE BINARYtetapi tidak terjadi apa-apa. Jadi saya membaca manual dan menemukan bahwa:

Pernyataan ini tidak berpengaruh jika server tidak dimulai dengan opsi --log-bin untuk mengaktifkan pencatatan biner.

Jadi saya mengaktifkan kembali log-bin=mysql-bindi saya /etc/my.cnf, restart, PURGED file (dengan sukses sekarang), berkomentar lagi dan kemudian restart. Setelah ini, file dihapus dan tidak lagi dibuat.

Ini berfungsi untuk saya: (versi server MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Menghapus semua log biner di sistem saya.

Anda dapat dengan mudah menghapus SEMUA log dengan:

PURGE BINARY LOGS BEFORE NOW();

Atau ganti func NOW () dengan tanggal apa pun dalam tanda kutip:

PURGE BINARY LOGS BEFORE '2018-02-15 00:00:00';

Atau Anda dapat mengotomatiskan tindakan ini dengan expire_logs_days = 10di my.cnf. Secara default expire_logs_days adalah 0 = tidak pernah menghapus log.

( sumber )