Mam MM Replikacja w MySQL i chcę, aby wycisnąć trochę wolnego miejsca w skrzynce być usuwanie zbędnych plików, natknąłem tych mysql-binplików wewnątrz /var/db/mysql/Istnieją setki tych plików jak mysql-bin.000123, mysql-bin.000223itd. I zostały sprawdzone replikacji mysql wykonując show master statusi show slave statussą one używając niektórych plików mysql-bin w niektórych pozycjach, ale myślę, że wszystkie inne pliki bin to resztki, które nie będą już używane. Czy w takim przypadku można bezpiecznie usunąć wszystkie pliki mysql-bin oprócz tych, na które obecnie wskazuje replikacja?

Jeśli można bezpiecznie usunąć, czy mogę coś zrobić, aby automatycznie usunąć te pliki, gdy nie są one używane?

Nie usuwaj ich tylko w systemie operacyjnym.

Musisz pozwolić mysqld zrobić to za Ciebie. Oto jak mysqld zarządza tym:

Plik mysql-bin.[index]przechowuje listę wszystkich dzienników binarnych wygenerowanych i automatycznie obróconych przez mysqld. Mechanizmy czyszczenia binlogów w połączeniu z mysql-bin.[index]:

PURGE BINARY LOGS TO 'binlogname';
PURGE BINARY LOGS BEFORE 'datetimestamp';

Spowodują to wyczyszczenie wszystkich dzienników binarnych przed określonym właśnie plikiem binlog lub datownikiem.

Na przykład, jeśli uruchomisz

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

spowoduje to usunięcie wszystkich dzienników binarnych wcześniej mysql-bin.000223.

Jeśli uciekniesz

PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND;

spowoduje to usunięcie wszystkich dzienników binarnych przed północą 3 dni temu.

Jeśli chcesz, aby binlog został automatycznie obrócony i utrzymał 3 dni pracy, po prostu ustaw:

mysql> SET GLOBAL expire_logs_days = 3;

następnie dodaj to do /etc/my.cnf

[mysqld]
expire_logs_days=3

a mysqld usunie dla ciebie dzienniki

POKAŻ STATUS SLAVE \ G

To jest krytyczne. Po uruchomieniu SHOW SLAVE STATUS\Gzobaczysz dwa dzienniki binarne od Master:

• Master_Log_File
• Relay_Master_Log_File

Gdy replikacja ma niewielkie opóźnienie lub nie ma go wcale, są one zwykle tej samej wartości. Gdy występuje duże opóźnienie replikacji, wartości te są różne. Aby to ułatwić, wybierz cokolwiek Relay_Master_Log_Filejest i wróć do Mistrza i biegnij

PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is';

W ten sposób replikacja nie jest przerywana.

To naprawdę zależy od strategii tworzenia kopii zapasowych. Jednym z głównych powodów utrzymywania dzienników binarnych jest przywrócenie bazy danych do „punktu w czasie”. Jeśli baza danych ulega awarii i wymaga przywrócenia, należy przywrócić najnowszą pełną kopię zapasową, a następnie odtworzyć dzienniki binarne, zaczynając od pozycji pełnej kopii zapasowej.

Jeśli więc codziennie wykonujesz pełną kopię zapasową i masz dzienniki binarne o wartości 7 dni, prawdopodobnie możesz usunąć dzienniki binarne z ostatnich 4-6 dni. Za pomocą tego expire_logs_daysustawienia można kontrolować, ile dzienników binarnych ma być przechowywanych .

Możesz usunąć dzienniki binarne, których nie potrzebujesz, najpierw sprawdzając, jaki jest najstarszy dziennik, który chcesz zachować:

ls -lh /path/to/binary/logs/mysql-bin.0*

a następnie w mysql:

mysql> PURGE BINARY LOGS TO 'mysql-bin.XXXXX';

Spróbuj tego:

RESET MASTER;

jak napisano w dokumencie :

RESET MASTER umożliwia usunięcie wszelkich plików dziennika binarnego i powiązanego z nimi pliku indeksu dziennika binarnego, przywracając dane główne do stanu przed uruchomieniem rejestrowania binarnego.

Spowoduje to usunięcie wszystkich powiązanych plików dziennika binarnego, co może nie być tym, czego chcesz.