Xóa bảng MySQL với các giao dịch đang chờ xử lý

Có cách nào để xóa bảng InnoDB hoặc cơ sở dữ liệu với các giao dịch đang chờ xử lý trong MySQL (tốt nhất là ở cấp hệ thống tệp) không?

Chuyện gì đã xảy ra:

Tôi sử dụng MySQL 5.5.28 và chạy LOAD DATA INFILE…để nhập một tập dữ liệu khổng lồ (300M hàng) vào bảng InnoDB. Tôi đã không sử dụng set autocommit = 0;trước đây. Thật không may, mysqldđã dừng lại ngay giữa lúc nhập khẩu.

Khi tôi khởi động lại mysql, nó cố gắng khôi phục giao dịch điền vào nhật ký hệ thống với các thông báo như sau:

mysqld_safe [4433]: 121212 16:58:52 InnoDB: Chờ 1 giao dịch hoạt động kết thúc

Vấn đề là cuộn ngược đang chạy trong hơn 25 giờ mà mysqldkhông chấp nhận bất kỳ kết nối ổ cắm nào.

Tôi không thể xóa /var/lib/mysql/*và bắt đầu lại từ đầu vì có một số cơ sở dữ liệu / bảng InnoDB khác trên máy này. Tuy nhiên, bảng có vấn đề là bảng duy nhất trong một cơ sở dữ liệu riêng biệt. Xóa toàn bộ bảng hoặc toàn bộ cơ sở dữ liệu không phải là vấn đề vì tôi có thể nhập lại tất cả dữ liệu sau đó.

Không có gì bạn thực sự có thể làm được vì việc khôi phục lại đang được thực hiện thông qua không gian bảng UNDO bên trong ibdata1 , vốn đã phát triển vô cùng.

Nếu bạn giết tiến trình mysqld và khởi động lại mysql, nó sẽ chỉ chọn nơi nó rời đi như một phần của chu kỳ khôi phục sự cố.

TUYÊN BỐ TỪ CHỐI: Không chịu trách nhiệm về mất dữ liệu

Những gì bạn có thể làm có thể dẫn đến mất dữ liệu cho các bảng khác, nhưng có một số điều bạn có thể làm để tránh chu kỳ khôi phục sự cố thông thường của InnoDB.

Có một tùy chọn khởi động được gọi là innodb_force_recovery , cho phép bạn bỏ qua các giai đoạn khác nhau của phục hồi sự cố InnoDB.

Theo Tài liệu MySQL về Buộc InnoDB Recovery , đây là các cài đặt và tác dụng của nó:

1 (SRV_FORCE_IGNORE_CORRUPT)

Hãy để máy chủ chạy ngay cả khi nó phát hiện một trang bị hỏng. Cố gắng thực hiện CHỌN * TỪ tbl_name nhảy qua các bản ghi chỉ mục và trang bị hỏng, điều này giúp trong việc đổ bảng.

2 (SRV_FORCE_NO_BACKGROUND)

Ngăn chặn luồng chủ chạy. Nếu sự cố sẽ xảy ra trong quá trình thanh lọc, giá trị khôi phục này sẽ ngăn chặn nó.

3 (SRV_FORCE_NO_TRX_UNDO)

Không chạy rollback giao dịch sau khi phục hồi sự cố.

4 (SRV_FORCE_NO_IBUF_MERGE)

Ngăn chặn chèn hoạt động hợp nhất bộ đệm. Nếu chúng gây ra sự cố, đừng làm chúng. Không tính toán thống kê bảng.

5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

Không nhìn vào nhật ký hoàn tác khi bắt đầu cơ sở dữ liệu: InnoDB xử lý ngay cả các giao dịch chưa hoàn thành như đã cam kết.

6 (SRV_FORCE_NO_LOG_REDO)

Không thực hiện cuộn lại nhật ký liên quan đến phục hồi.

Với các thay đổi giao dịch được chôn trong nhật ký của UNDO và REDO, bạn có nguy cơ

• mất dữ liệu có nghĩa là được viết
• giữ dữ liệu có nghĩa là bị xóa

Trong trường hợp bạn mong đợi các tác dụng phụ xấu, hãy sao lưu toàn bộ / var / lib / mysql và đặt nó ở đâu đó trong trường hợp bạn muốn sao chép ibdata1, ib_logfile0 và ib_logfile1 và thử lại phục hồi bình thường.

Nếu mysql hoàn toàn ở một trong các chế độ

• mysqldump tất cả dữ liệu ngoại trừ bảng vi phạm
• tắt máy tính
• xóa mọi thứ trong / var / lib / mysql ngoại trừ / var / lib / mysql / mysql
• bắt đầu mys
• tải lại mysqldump

CAVEAT: Hãy chắc chắn rằng bạn sao lưu mọi thứ !!!

Tôi hi vọng cái này giúp được !!!

Tôi đã có một tình huống tương tự trong tuần này.

Và sau bốn lần khôi phục bản sao lưu đầy đủ cho máy chủ thử nghiệm và cố gắng thả, xóa hoặc hủy các bảng với các giao dịch đang chờ xử lý khổng lồ, cuối cùng chúng tôi đã đến chiều thứ Sáu và quyết định chỉ để nó chạy. Trong ba ngày, giao dịch kết thúc với tải máy chủ không đáng kể và cơ sở dữ liệu vẫn ổn. Điều này tốt hơn nhiều so với bất kỳ thao tác thủ công nào trên các tệp .frm và bảng mysql đã thử và thất bại.

Giải pháp của tôi: Đừng xóa nó . Cho phép các giao dịch đang chờ xử lý kết thúc, ngay cả khi bạn phải tạm dừng các hoạt động khác trong vài ngày hoặc tìm một số không gian đĩa ở đâu đó hoặc để máy chủ nô lệ của bạn tải.