PURGE BINARY LOGS'un yanı sıra FLUSH LOGS'u kullandım, ancak mysql dizini hala bu dosyaları içeriyor:

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

Komutları kullanmamanın bir nedeni var mı? Bu dosyalar çok yer kaplıyor. Onlardan güvenli bir şekilde kurtulmak istiyorum.

PURGE BINARY LOGSİfadesi öncesinde Belirtilen günlük dosyası adı veya zaman damgasına günlük dizin dosyasında listelenen tüm ikili günlük dosyalarını siler. Silinen günlük dosyaları, dizin dosyasında kaydedilen listeden de kaldırılır, böylece verilen günlük dosyası listede ilk olur.

Umarım ikili günlükleri mysql-bin.000019komutu kullanarak temizlediniz

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

Tüm günlükleri temizlemeniz gerekiyorsa

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

Böylece ikili günlükler kaldırılır mysql-bin.000025.

GÜNCELLEME

Deneyebilirsin

RESET MASTER;

RESET MASTER Dizin dosyasında listelenen tüm ikili günlük dosyalarını siler, ikili günlük dizin dosyasını boş olarak sıfırlar ve yeni bir ikili günlük dosyası oluşturur

RESET MASTERPURGE BINARY LOG'larından 2 farklı şekilde etkileri :

1. RESET MASTER dizin dosyasında listelenen tüm ikili günlük dosyalarını kaldırır ve yalnızca .000001 sayısal sonekine sahip tek, boş bir ikili günlük dosyası bırakırken, numaralandırma BURARY BINARY LOGS tarafından sıfırlanmaz.

2. RESET MASTERherhangi bir çoğaltma kölesi çalışırken kullanılmak üzere tasarlanmamıştır. RESET MASTERSlave'ler çalışırken ne zaman kullanıldığının davranışı tanımlanmamıştır (ve dolayısıyla desteklenmemektedir), oysa PURGE BINARY LOGSçoğaltma slave'leri çalışırken güvenle kullanılabilir.

CAVEAT RolandoMySQLDBA tarafından

Eğer çalıştırırsanız RESET MASTERKöleler bağlı ve çalışır, her Kölenin IO Konu derhal yerini kaybedecektir. Çoğaltma böylece bozulur ve tüm Slave'lerin verilerini tekrar senkronize etmek için zaman harcamanız gerekecektir. Çoğaltma bütünlüğünü bozmadan bir Master'dan ikili günlükleri güvenli bir şekilde silmek istiyorsanız, işte yapmanız gerekenler:

• SHOW SLAVE STATUS\GHer Slave'de koş .
• Dikkat edin Relay_Master_Log_File. Bu, son ifadesi Slave'de başarıyla çalıştırılan ikili günlüktür).
• Tüm görüntülerinden SHOW SLAVE STATUS\Ghangisinin Relay_Master_Log_Fileen eski olduğunu belirleyin (Örneğin, 'mysql-bin.00123').
• Kaçabilirsiniz PURGE BINARY LOGS TO 'mysql-bin.00123';yerini kaybedecek Köleler Hiçbiri.

Genel etki? Bu, henüz tüm Köleler üzerinde henüz ifadeleri yürütülmemiş olan Üstat'daki ikili günlükleri geride bırakacaktır.

Size ne olduğunu emin değilim ama benim durumumda MySQL "bisiklet" günlükleri durdurdu ve mysql-bin.index dosyası geçersiz binlog dosya girişleri ile "bozuk" olmuştu.

Özellikle, indeks dosyası mysql-bin.000001'de başlamış ve mysql-bin.000220'ye ulaşmış, ancak bir şekilde 001'den tekrar başlamıştı. Bunu sunucumdaki dosyalarla karşılaştırdığımda 001'den dosyalara sahip olduğumu görebiliyordum. 022.

İlk başta denedim PURGE LOGS TO 'mysql-bin.000022';ama bu işe yaramadı.

Sonunda MySQL'i durdurdum ve sunucumda bulunan dosyaları eşleştirene kadar dizin dosyasını el ile düzenledim. MySQL'i yeniden başlattığımda, expire_logs_daysayara göre binlog dosyalarını temizledi ve tekrar normal çalışmaya başladı.

Benim durumumda PURGE BINARYhiçbir şey silmiyordum.

% 100 kullanımda bölümüm vardı (yeniden başlatılmak için mysql için yeterli alan olması için benim slowqueries günlüğümü temizlemek zorunda kaldım), bu yüzden yaptığım ilk şey /etc/my.cnfsatır yorum yapmak log-bin=mysql-binoldu (gerekli değildi) artık bu sunucuda ve kaldırmayı unutmuştum) ve sonra mysql'yi yeniden başlattım (bu, PURGE BINARYyürütülmesi engellenen kuyruğa alınmış sorgular olduğu için gerekliydi ).

Ondan sonra koştum PURGE BINARYama hiçbir şey olmadı. Bu yüzden kılavuzu okudum ve öğrendim:

Sunucu ikili günlüğü etkinleştirmek için --log-bin seçeneğiyle başlatılmamışsa bu deyimin bir etkisi olmaz.

Ben reenabled Yani log-bin=mysql-binbenim de /etc/my.cnf(şimdi başarı ile), yeniden, tasfiye dosyaları yeniden ve daha sonra yeniden hattını yorumladı. Bundan sonra dosyalar kaldırıldı ve artık oluşturulmadı.

Bu benim için çalışıyor: (MySQL sunucusu sürümü: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Sistemimdeki tüm ikili günlükleri kaldırır.

TÜM günlükleri aşağıdakilerle kolayca silebilirsiniz :

PURGE BINARY LOGS BEFORE NOW();

Veya func NOW () ifadesini tırnak işaretleri içinde herhangi bir tarihle değiştirin:

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

Veya expire_logs_days = 10my.cnf dosyasında bu işlemi otomatikleştirebilirsiniz . Varsayılan olarak expire_logs_days olan 0 = hiçbir zaman silme günlükleri.

( kaynak )