Tôi đã sử dụng PURGE BINary LOGS cũng như FLUSH LOGS, nhưng thư mục mysql vẫn chứa các tệp này:

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

Có một lý do tại sao sử dụng các lệnh không hoạt động? Những tập tin này đang chiếm rất nhiều không gian. Tôi muốn thoát khỏi chúng một cách an toàn.

Câu PURGE BINARY LOGSlệnh xóa tất cả các tệp nhật ký nhị phân được liệt kê trong tệp chỉ mục nhật ký trước tên tệp dấu thời gian hoặc dấu thời gian được chỉ định. Các tệp nhật ký đã xóa cũng được xóa khỏi danh sách được ghi trong tệp chỉ mục, để tệp nhật ký đã cho trở thành đầu tiên trong danh sách.

Tôi hy vọng bạn đã xóa các bản ghi nhị phân mysql-bin.000019bằng cách sử dụng lệnh

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

Nếu bạn cần thanh lọc tất cả các bản ghi làm như

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

Điều này sẽ loại bỏ các bản ghi nhị phân tối đa mysql-bin.000025.

CẬP NHẬT

Bạn co thể thử

RESET MASTER;

RESET MASTER Xóa tất cả các tệp nhật ký nhị phân được liệt kê trong tệp chỉ mục, đặt lại tệp chỉ mục nhật ký nhị phân để trống và tạo tệp nhật ký nhị phân mới

Các tác động RESET MASTERkhác nhau từ những tác động của NHẬP NHẬP B BINNG PURGE theo 2 cách chính:

1. RESET MASTER xóa tất cả các tệp nhật ký nhị phân được liệt kê trong tệp chỉ mục, chỉ để lại một tệp nhật ký nhị phân trống, duy nhất có hậu tố số là 0,000001, trong khi việc đánh số không được đặt lại bởi PURGE BINARY LOGS.

2. RESET MASTERđã không được sử dụng trong khi bất kỳ nô lệ sao chép nào đang chạy. Hành vi RESET MASTERkhi được sử dụng trong khi nô lệ đang chạy không được xác định (và do đó không được hỗ trợ), trong khi PURGE BINARY LOGScó thể được sử dụng an toàn trong khi nô lệ sao chép đang chạy.

CAVEAT bởi RolandoMySQLDBA

Nếu bạn chạy RESET MASTERvới Slaves được kết nối và chạy, Chủ đề IO của mỗi Slave sẽ ngay lập tức mất vị trí. Sao chép bị hỏng và bạn sẽ phải mất thời gian để lấy lại dữ liệu trên tất cả các đồng bộ hóa nô lệ. Nếu bạn muốn xóa nhật ký nhị phân khỏi Master một cách an toàn mà không phá vỡ tính toàn vẹn của bản sao, đây là những gì bạn làm:

• Chạy SHOW SLAVE STATUS\Gtrên mỗi Slave.
• Hãy lưu ý Relay_Master_Log_File. Đây là nhật ký nhị phân có câu lệnh mới nhất được thực hiện thành công trong Slave).
• Từ tất cả các màn hình SHOW SLAVE STATUS\G, xác định cái nào Relay_Master_Log_Filelà cũ nhất (Ví dụ: 'mysql-bin.00123').
• Bạn có thể chạy PURGE BINARY LOGS TO 'mysql-bin.00123';Không ai trong số các nô lệ sẽ mất vị trí của nó.

Hiệu quả tổng thể? Điều này sẽ để lại các bản ghi nhị phân trên Master có các câu lệnh chưa được thực thi trên tất cả các nô lệ.

Tôi không chắc đây có phải là những gì đã xảy ra với bạn không nhưng trong trường hợp của tôi, MySQL đã dừng nhật ký "đi xe đạp" và tệp mysql-bin.index đã bị "hỏng" với các mục nhập tệp binlog không hợp lệ.

Cụ thể, tệp chỉ mục đã bắt đầu tại mysql-bin.000001 và đã chuyển sang mysql-bin.000220 nhưng sau đó bằng cách nào đó đã bắt đầu lại từ 001. Khi tôi so sánh tệp này với các tệp trên máy chủ của mình, tôi có thể thấy rằng tôi có các tệp từ 001 đến 022.

Lúc đầu tôi đã thử PURGE LOGS TO 'mysql-bin.000022';nhưng điều này không hiệu quả.

Cuối cùng, tôi đã dừng MySQL và chỉnh sửa thủ công tệp chỉ mục cho đến khi nó khớp với các tệp tôi có trên máy chủ của mình. Khi tôi khởi động lại MySQL, nó dọn sạch các tệp binlog để tôn trọng expire_logs_dayscài đặt và bắt đầu hoạt động bình thường trở lại.

Trong trường hợp của tôi PURGE BINARYchỉ đơn giản là không xóa bất cứ điều gì.

Tôi đã có phân vùng của mình với mức sử dụng 100% (tôi phải dọn sạch nhật ký truy vấn chậm của mình một chút để có đủ không gian để mysql được khởi động lại), vì vậy điều đầu tiên tôi làm là thay đổi /etc/my.cnfđể nhận xét dòng này log-bin=mysql-bin(không cần thiết trong máy chủ này nữa và tôi đã quên gỡ bỏ nó), và sau đó tôi khởi động lại mysql (điều này là cần thiết bởi vì có các truy vấn được xếp hàng chờ ngăn PURGE BINARYkhông được thực thi).

Sau đó, tôi chạy PURGE BINARYnhưng không có gì xảy ra. Vì vậy, tôi đọc hướng dẫn và phát hiện ra rằng:

Tuyên bố này không có hiệu lực nếu máy chủ không được khởi động với tùy chọn --log-bin để cho phép ghi nhật ký nhị phân.

Vì vậy, tôi reenabled log-bin=mysql-bintrong tôi /etc/my.cnf, khởi động lại, được tẩy các tập tin (với thành công bây giờ), nhận xét dòng một lần nữa và sau đó khởi động lại. Sau đó, các tập tin đã được gỡ bỏ và không còn được tạo ra.

Điều này hoạt động với tôi: (phiên bản máy chủ MySQL: 5.6.14)

PURGE BINARY LOGS BEFORE NOW();

Loại bỏ tất cả các bản ghi nhị phân trên hệ thống của tôi.

Bạn có thể dễ dàng xóa TẤT CẢ các bản ghi với:

PURGE BINARY LOGS BEFORE NOW();

Hoặc thay thế func NOW () bằng bất kỳ ngày nào trong dấu ngoặc kép:

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

Hoặc bạn có thể tự động hóa hành động này với expire_logs_days = 10trong my.cnf. Theo mặc định expire_logs_days là 0 = không bao giờ xóa nhật ký.

( nguồn )