Tại sao các byte âm lượng của tôi được sử dụng luôn luôn tăng trên cụm Amazon Aurora của tôi?

Tôi có một cụm Aurora DB của Amazon (AWS) và mỗi ngày, nó [Billed] Volume Bytes Usedđang tăng lên.

Tôi đã kiểm tra kích thước của tất cả các bảng của mình (trong tất cả các cơ sở dữ liệu của tôi trên cụm đó) bằng INFORMATION_SCHEMA.TABLESbảng:

SELECT ROUND(SUM(data_length)/1024/1024/1024) AS data_in_gb, ROUND(SUM(index_length)/1024/1024/1024) AS index_in_gb, ROUND(SUM(data_free)/1024/1024/1024) AS free_in_gb FROM INFORMATION_SCHEMA.TABLES;
+------------+-------------+------------+
| data_in_gb | index_in_gb | free_in_gb |
+------------+-------------+------------+
| 30         | 4           | 19         |
+------------+-------------+------------+

Tổng cộng: 53GB

Vậy tại sao một tôi được thanh toán gần 75GB tại thời điểm này?

Tôi hiểu rằng không gian được cung cấp không bao giờ có thể được giải phóng, giống như cách các tệp ibdata trên máy chủ MySQL thông thường không bao giờ có thể thu hẹp; Tôi ok với điều đó. Đây là tài liệu, và chấp nhận được.

Vấn đề của tôi là mỗi ngày, không gian tôi được lập hóa đơn tăng lên. Và tôi chắc chắn rằng tôi KHÔNG sử dụng 75GB dung lượng tạm thời. Nếu tôi làm điều gì đó như thế, tôi sẽ hiểu. Như thể không gian lưu trữ mà tôi đang giải phóng, bằng cách xóa các hàng khỏi bảng của tôi hoặc bỏ bảng hoặc thậm chí bỏ cơ sở dữ liệu, sẽ không bao giờ được sử dụng lại.

Tôi đã liên hệ với bộ phận hỗ trợ AWS (cao cấp) nhiều lần và không bao giờ có thể nhận được lời giải thích tốt về lý do đó.
Tôi đã nhận được đề xuất để chạy OPTIMIZE TABLEtrên các bảng có nhiều free_space(trên mỗi INFORMATION_SCHEMA.TABLESbảng) hoặc để kiểm tra độ dài lịch sử của InnoDB, để đảm bảo dữ liệu đã xóa vẫn không được giữ trong phân đoạn rollback (ref: MVCC ) và khởi động lại (các) thể hiện để đảm bảo phân đoạn rollback được làm trống.
Không ai trong số họ giúp đỡ.

Có nhiều thứ đang chơi ở đây ...

1. Mỗi bảng được lưu trữ trong không gian bảng riêng của nó

   Theo mặc định, nhóm tham số cho cụm Aurora (được đặt tên default.aurora5.6) xác định innodb_file_per_table = ON. Điều đó có nghĩa là mỗi bảng được lưu trữ trong một tệp riêng biệt, trên cụm lưu trữ Aurora. Bạn có thể xem không gian bảng nào được sử dụng cho mỗi bảng của mình bằng truy vấn này:

   SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

   Lưu ý: Tôi chưa thử đổi innodb_file_per_tablesang OFF. Có lẽ điều đó sẽ giúp ..?

2. Không gian lưu trữ được giải phóng bằng cách xóa không gian bảng KHÔNG được sử dụng lại

   Trích dẫn hỗ trợ cao cấp AWS:

   Do thiết kế độc đáo của công cụ Lưu trữ Aurora để tăng hiệu suất và khả năng chịu lỗi, Aurora không có chức năng chống phân mảnh không gian bảng trên mỗi bảng theo cách tương tự như MySQL tiêu chuẩn.

   Hiện tại, không may là Aurora không có cách thu nhỏ không gian bảng như MySQL tiêu chuẩn và tất cả không gian phân mảnh được tính phí vì nó được bao gồm trong VolumeBytesUsed.
   Lý do mà Aurora không thể lấy lại không gian của một bảng bị rớt theo cách tương tự như MySQL tiêu chuẩn là dữ liệu cho bảng được lưu trữ theo cách hoàn toàn khác với cơ sở dữ liệu MySQL tiêu chuẩn với một dung lượng lưu trữ duy nhất.

   Nếu bạn thả một bảng hoặc hàng trong Aurora, không gian sẽ không được lấy lại trên khối lượng cụm Auroras do thiết kế phức tạp này.
   Việc không thể lấy lại một lượng nhỏ dung lượng lưu trữ này là một sự hy sinh để có được mức tăng hiệu suất bổ sung của dung lượng lưu trữ cụm Auroras và khả năng chịu lỗi được cải thiện đáng kể của Aurora.

   Nhưng có một số cách tối nghĩa để sử dụng lại một số không gian lãng phí đó ...
   Một lần nữa, trích dẫn hỗ trợ cao cấp AWS:

   Khi tổng số dữ liệu của bạn vượt quá một kích thước nhất định (khoảng 160 GB), bạn có thể bắt đầu lấy lại dung lượng trong các khối 160 GB để sử dụng lại, ví dụ: nếu bạn có 400 GB trong khối lượng cụm Aurora và DROP 160 GB trở lên của bảng thì có thể tự động sử dụng lại 160 GB dữ liệu. Tuy nhiên, có thể chậm để lấy lại không gian này.
   Lý do cho một lượng lớn dữ liệu cần phải được giải phóng cùng một lúc là do thiết kế độc đáo của Auroras như một công cụ DB quy mô doanh nghiệp không giống như MySQL tiêu chuẩn không thể được sử dụng trên quy mô này.

3. BẢNG TỐI ƯU là xấu xa!

   Bởi vì Aurora dựa trên MySQL 5.6, OPTIMIZE TABLEđược ánh xạ tới ALTER TABLE ... FORCE, nó sẽ xây dựng lại bảng để cập nhật số liệu thống kê chỉ mục và không gian không sử dụng miễn phí trong chỉ mục được nhóm. Thực tế, cùng với innodb_file_per_table = ONđó, điều đó có nghĩa là chạy một OPTIMIZE TABLEtệp không gian bảng mới và xóa tệp cũ. Vì việc xóa tệp vùng bảng không giải phóng bộ nhớ mà nó đang sử dụng, điều đó có nghĩa là OPTIMIZE TABLEsẽ luôn dẫn đến việc lưu trữ được cung cấp nhiều hơn. Ôi!

   Tham chiếu: https://dev.mysql.com/doc/refman/5.6/en/optizes-table.html#optizes-table-innodb-details

4. Sử dụng bảng tạm thời

   Theo mặc định, nhóm tham số cho các trường hợp Aurora (được đặt tên default.aurora5.6) xác định default_tmp_storage_engine = InnoDB. Điều đó có nghĩa là mỗi khi tôi tạo một TEMPORARYbảng, nó sẽ được lưu trữ, cùng với tất cả các bảng thông thường của tôi , trên cụm lưu trữ Aurora. Điều đó có nghĩa là không gian mới được cung cấp để chứa các bảng đó, do đó làm tăng tổng VolumeBytesUsed.
   Giải pháp cho việc này đủ đơn giản: thay đổi default_tmp_storage_enginegiá trị tham số thành MyISAM. Điều này sẽ buộc Aurora tạo các TEMPORARYbảng trên bộ nhớ cục bộ của thể hiện.
   Lưu ý: lưu trữ cục bộ của các trường hợp bị hạn chế; xem Free Local Storagesố liệu trên CloudWatch để xem dung lượng của bạn có bao nhiêu dung lượng. Các trường hợp lớn hơn (chi phí cao hơn) có nhiều bộ nhớ cục bộ hơn.

   Tham khảo: chưa có; tài liệu Amazon Aurora hiện tại không đề cập đến điều này. Tôi đã yêu cầu nhóm hỗ trợ AWS cập nhật tài liệu và sẽ cập nhật câu trả lời của tôi nếu / một khi họ làm.

Khi dữ liệu Aurora bị xóa, chẳng hạn như bằng cách thả bảng hoặc phân vùng, không gian được phân bổ tổng thể vẫn giữ nguyên. Không gian trống được sử dụng lại tự động khi khối lượng dữ liệu tăng trong tương lai. https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html