Amazon Aurora kümemde neden kullanılan "birim baytlarım" sürekli artıyor?

Bir Amazon (AWS) Aurora DB kümem var ve her geçen gün [Billed] Volume Bytes Usedartıyor.

INFORMATION_SCHEMA.TABLESTabloyu kullanarak tüm tablolarımın boyutunu (bu kümedeki tüm veritabanlarımda) kontrol ettim :

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         |
+------------+-------------+------------+

Toplam: 53GB

Öyleyse neden şu anda neredeyse 75 GB faturalandırılıyorum?

Sağlanan alanın, normal bir MySQL sunucusundaki ibdata dosyalarının asla küçülemeyeceği şekilde serbest bırakılamayacağını anlıyorum; Ben iyiyim. Bu belgelenmiştir ve kabul edilebilir.

Benim sorunum, her gün faturalandırdığım alanın artması. Eminim 75GB'lık alanı geçici olarak KULLANMADIM. Eğer böyle bir şey yapsaydım, anlardım. Sanki serbest bıraktığım depolama alanı, tablolarımdaki satırları silerek veya tabloları bırakarak, hatta veritabanlarını bırakarak asla yeniden kullanılmıyor.

AWS (premium) desteğiyle birkaç kez iletişim kurdum ve bunun neden olduğu konusunda iyi bir açıklama alamadım. Silinen verilerin geri alma segmentinde tutulmadığından emin olmak için ( tablo başına ) veya InnoDB geçmiş uzunluğunu kontrol etmek için tabloların üzerinde
çalıştırmak OPTIMIZE TABLEiçin öneriler aldım (ref: MVCC ) ve geri alma segmentinin boşaltıldığından emin olmak için örnekleri yeniden başlatın. Bunların hiçbiri yardım etmedi.free_spaceINFORMATION_SCHEMA.TABLES

Burada birçok şey var ...

1. Her tablo kendi tablo alanında saklanır

   Varsayılan olarak, Aurora kümeleri (adlı default.aurora5.6) için parametre grubu tanımlar innodb_file_per_table = ON. Bu, her tablonun Aurora depolama kümesinde ayrı bir dosyada saklandığı anlamına gelir. Bu sorguyu kullanarak tablolarınızın her biri için hangi tablo alanının kullanıldığını görebilirsiniz:

   SELECT name, space FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES;

   Not: Ben değişikliğine denemedim innodb_file_per_tableiçin OFF. Belki bu yardımcı olur ..?

2. Tablo alanları silinerek serbest bırakılan depolama alanı yeniden KULLANILAMAZ

   AWS premium desteğinden alıntı:

   Aurora Depolama motorunun performansını ve hata toleransını artırmak için benzersiz tasarımı nedeniyle Aurora, tablo başına dosya tablo alanlarını standart MySQL ile aynı şekilde birleştirecek bir işleve sahip değildir.

   Şu anda Aurora, standart MySQL'in yaptığı gibi tablo alanlarını küçültmenin bir yoluna sahip değil ve VolumeBytesUsed'e dahil olduğu için tüm parçalanmış alan ücretlendiriliyor.
   Aurora'nın bırakılan bir tablonun alanını standart MySQL ile aynı şekilde geri alamamasının nedeni, tablodaki verilerin tek bir depolama hacmine sahip standart bir MySQL veritabanından tamamen farklı bir şekilde saklanmasıdır.

   Aurora'da bir tablo veya satır bırakırsanız, bu karmaşık tasarım nedeniyle alan Auroras küme hacminde geri kazanılmaz.
   Az miktarda depolama alanını geri kazanamama, Auroras küme depolama hacminin ek performans kazanımlarını ve Aurora'nın büyük ölçüde geliştirilmiş hata toleransını elde etmek için yapılan bir fedakarlıktır.

   Ancak boşa giden alanın bir kısmını yeniden kullanmanın bazı belirsiz yolları var ...
   Yine AWS premium desteğini teklif edin:

   Toplam veri kümeniz belirli bir boyutu (yaklaşık 160 GB) aştığında, yeniden kullanmak üzere 160 GB'lık bloklarda alan kazanmaya başlayabilirsiniz, örneğin Aurora küme hacminizde 400 GB ve Aurora'nın DROP 160 GB veya daha fazla tablosu varsa 160 GB veriyi otomatik olarak yeniden kullanır. Ancak bu alanı geri almak yavaş olabilir.
   Bir kerede serbest bırakılması gereken büyük miktarda verinin nedeni, bu ölçekte kullanılamayan standart MySQL'in aksine, kurumsal ölçekli bir DB motoru olarak Auroras'ın benzersiz tasarımından kaynaklanmaktadır.

3. OPTİMİZE TABLOSU kötüdür!

   Aurora MySQL 5.6 tabanlı olduğundan , kümelenmiş dizinde dizin istatistiklerini ve kullanılmayan alanı güncellemek için tabloyu yeniden oluşturan OPTIMIZE TABLE, eşlenir ALTER TABLE ... FORCE. Etkili bir şekilde, bununla birlikte innodb_file_per_table = ON, bir çalıştırmak OPTIMIZE TABLEyeni bir tablo alanı dosyası oluşturur ve eskisini siler. Bir tablo alanı dosyasının silinmesi, kullandığı depolama alanını serbest bırakmadığı için OPTIMIZE TABLE, her zaman daha fazla depolama alanı sağlanmasına neden olur. Ah!

   Ref: https://dev.mysql.com/doc/refman/5.6/en/optimize-table.html#optimize-table-innodb-details

4. Geçici tabloları kullanma

   Varsayılan olarak, Aurora örnekleri (adlandırılmış default.aurora5.6) için parametre grubu tanımlar default_tmp_storage_engine = InnoDB. Bu, her TEMPORARYtablo oluşturduğumda , tüm normal tablolarımla birlikte Aurora depolama kümesinde saklandığı anlamına gelir . Bu, bu tabloları tutmak için yeni alan sağlandığı ve böylece toplam VolumeBytesUsed değerinin artırıldığı anlamına gelir.
   Bunun çözümü yeterince basittir: default_tmp_storage_engineparametre değerini olarak değiştirin MyISAM. Bu, Aurora'yı TEMPORARYörneğin yerel depolama alanındaki tabloları oluşturmaya zorlar .
   Not: örneklerin yerel depolaması sınırlıdır; bkz Free Local Storageörnekleriniz ne kadar saklama alanı görmek için CloudWatch metrik. Daha büyük (daha pahalı) örneklerde daha fazla yerel depolama alanı bulunur.

   Ref: henüz yok; mevcut Amazon Aurora belgeleri bundan bahsetmiyor. AWS destek ekibinden belgeleri güncellemesini istedim ve eğer cevaplarsa / bir kez yanıtımı güncelleyeceğim.

Bir tabloyu veya bölümü atmak gibi Aurora verileri kaldırıldığında, ayrılan toplam alan aynı kalır. Gelecekte veri hacmi arttığında boş alan otomatik olarak yeniden kullanılır. https://docs.amazonaws.cn/en_us/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html