ApsaraDB RDS:RDS MySQL storage issues

Acil durum yanıtı

Örnek zaten kilitlendiyse (salt okunur), yazma erişimini geri kazanmak için diski hemen genişletin. Hizmeti yeniden kullanılabilir hale getirdikten sonra tüm temizleme ve kök neden düzeltme işlemlerini yapın.

1. RDS konsolu içinde örnek kimliğini tıklayın.

2. Örneğin kilidini açmak için Diski manuel olarak yeniden boyutlandırın.

Yeniden boyutlandırma işlemi tamamlandıktan yaklaşık 5 dakika sonra örneğin kilidi açılır. İlerlemeyi Görev Merkezi üzerinden izleyebilirsiniz.

Depolama kullanımını görüntüleyin

Bir RDS for MySQL örneğinin depolama alanı; kullanıcı verilerini, sistem verilerini, günlükleri ve geçici dosyaları içerir.

1. RDS konsolunda örnek kimliğini tıklayın.

2. Sol gezinme bölmesinde Monitoring and Alerts > Standard Monitoring seçeneklerini seçin.

3. MySQL Storage Space Used görünümünü bulun. Her bir parametrenin açıklamasını görmek için görünüm başlığının yanındaki simgeye tıklayın.

Ayrıntılı izleme adımları için bkz. İzleme bilgilerini görüntüleme.

Nedeni belirleyin

MySQL Storage Space Used görünümünü kontrol edin ve yüksek kullanım gösteren parametreyi aşağıdaki dosya türü ve çözümle eşleştirin.

Ayrıca, ayrı parametreler olarak görünmese de önemli miktarda alan tüketebilecek parçalanma ve dizin şişmesini de kontrol edin:

• Parçalanma: bkz. Parçalanma birikimi

• Dizin şişmesi: bkz. Dizin dosyası birikimi

Geçici dosya birikimi

MySQL, büyük veri kümelerini sıralayan, gruplayan veya birleştiren SQL deyimlerini yürütürken geçici dosyalar oluşturur. Büyük işlemler için binary loglar da işlem commit edilene kadar geçici olarak önbelleğe alınır. Bu dosyaların birikmesi durumunda örnek kilitlenir.

Anlık kilidi çözün:

• MySQL 5.7 veya önceki sürümler: Örneği yeniden başlatın. Sistem, yeniden başlatma sırasında geçici dosyaları otomatik olarak siler.

• MySQL 8.0: Örnek tüm kullanıcı oturumlarını sonlandırır ve otomatik bir geri alma işlemi başlatır. Geri alma işlemi tamamlandıktan sonra geçici dosyalar serbest bırakılır.

Örnek otomatik olarak kilit açılmazsa, durumu Copy to tmp table veya Sending data olan oturumları belirlemek için show processlist komutunu çalıştırın ve ardından kill komutuyla bu oturumları sonlandırın.

Daha fazla bilgi için bkz. RDS for MySQL'de geçici dosya birikimine yönelik çözümler.

Binary log dosya birikimi

Büyük işlemler kısa sürede çok sayıda binary log dosyası oluşturur. Loglar temizlenenden daha hızlı biriktiğinde depolama alanı tükenir ve örnek kilitlenir.

Mevcut logları yükleyerek çözün:

Binary log dosyalarını RDS örneğinden OSS'e yüklemek için One-click binary log upload özelliğini kullanın. RDS, yüklenen dosyaları otomatik olarak siler. Bkz. Binary log dosyalarını görüntüleme ve silme.

Alıkoyma ilkesini ayarlayarak tekrarlanmasını önleyin:

1. RDS konsolunda Backup and Restoration sayfasına gidin.

2. Backup Strategy sekmesine tıklayın.

3. Local Log Retention Policy yanında Edit seçeneğine tıklayın.

4. Alıkoyma süresini, maksimum depolama kullanımını ve kullanılabilir depolama alanını ayarlayın. Yerel log depolama alanı eşik değere ulaştığında sistem en eski logları otomatik olarak siler.

Daha fazla bilgi için bkz. MySQL binlog dosya birikimine yönelik çözümler.

Parçalanma birikimi

InnoDB, tablespace'leri sayfa bazında yönetir. delete veya update kullanarak satırları sildiğinizde veya güncellediğinizde MySQL alanı yeniden kullanılabilir olarak işaretler ancak disk dosyasını küçültmez. Serbest bırakılan sayfalar yeniden kullanılamazsa parçalanma birikir ve depolama alanını tüketir.

Parçalanmayı aşağıdaki yöntemlerden birini kullanarak çözün:

• Komut satırı: Tabloyu yeniden oluşturmak ve parçalanmış alanı geri kazanmak için optimize table <table_name> komutunu çalıştırın.

• DMS konsolu: DMS üzerinden RDS örneğine giriş yapın. Bir tablo adına sağ tıklayın ve Batch operation table seçeneğini seçin. Parçalanmayı gidermek istediğiniz tabloları seçin, ardından Table Maintenance > Optimize Table seçeneklerini belirleyin.

• Automatic reclamation: RDS konsolunda Autonomy Services > Diagnostics > Autonomy Center yolunu izleyin. Autonomy Service Settings seçeneğine tıklayın, ardından Optimization and Throttling sekmesinde Automatic Fragment Reclamation özelliğini etkinleştirin. Ayrıntılar için bkz. Otomatik parça geri kazanımı özelliğini kullanma.

Daha fazla bilgi için bkz. MySQL alan parçalanmasına yönelik çözümler.

Sistem dosyası birikimi

Büyük sistem dosyaları neredeyse her zaman undo log büyümesinden kaynaklanır. Uzun süren InnoDB sorguları büyük veri güncellemeleriyle eşzamanlı olarak çalıştığında MySQL yüksek miktarda undo verisi üretir. Bu veriler sistem tablespace'ini doldurur ve depolama alanını tüketebilir.

Çözüm, MySQL sürümünüze ve undo tablespace yapılandırmanıza bağlıdır.

MySQL 8.0

Sistem undo dosyalarını otomatik olarak temizler. Manuel bir işlem gerekmez.

**innodb_undo_tablespaces = 2 ayarlı MySQL 5.7**

Örnek ayrı undo tablespace'leri kullanır. Undo dosyası boyutu innodb_max_undo_log_size değerini aştığında ve veriyi gerektiren aktif bir işlem olmadığında sistem alanı serbest bırakmak için bir truncate işlemi çalıştırır.

**innodb_undo_tablespaces = 0 ayarlı MySQL 5.7**

Undo verileri sistem tablespace'i ibdata1 içinde depolanır ve geri kazanılamaz. Sorunu çözmek için aşağıdaki yöntemlerden birini kullanın:

• Yöntem 1: Yeni bir örnek oluşturun ve verileri DTS kullanarak geçirin. Bkz. RDS MySQL konsolu aracılığıyla veri geçişi.

• Yöntem 2: MySQL 8.0'a yükseltin. Bkz. Veritabanı sürümünü yükseltme.

MySQL 5.5 ve 5.6

Undo dosyası temizleme desteklenmez. MySQL 5.7 Yüksek Kullanılabilirlik Sürümüne veya MySQL 8.0'a yükseltin. MySQL 5.7'ye yükselttikten sonra otomatik temizlemeyi desteklemek için ayrı undo tablespace'lerini etkinleştirin. MySQL 8.0 undo dosyalarını otomatik olarak temizler.

Daha fazla bilgi için bkz. MySQL sistem dosyası birikimine yönelik çözümler.

General log dosya birikimi

Genel sorgu günlüğü etkinleştirildiğinde RDS, SELECT, INSERT, UPDATE ve DELETE dahil olmak üzere yürütülen her SQL deyimini kaydeder. Yüksek trafikte log dosyası hızla büyür. Düzenli olarak temizlenmezse depolama alanını tüketebilir.

Anında çözüm:

Mevcut tüm general log kayıtlarını silmek için aşağıdaki komutu çalıştırın:

TRUNCATE TABLE mysql.general_log;

Yeni log oluşumunu durdurun:

general_log çalışma zamanı parametresini OFF olarak ayarlayarak general log toplamayı devre dışı bırakın. Bkz. Örnek parametrelerini ayarlama.

En iyi uygulama: Üretim ortamında general log'u devre dışı tutun. Yalnızca hata ayıklama veya sorun giderme amacıyla geçici olarak etkinleştirin ve işlem tamamlandıktan hemen sonra devre dışı bırakıp temizleyin.

Daha fazla bilgi için bkz. MySQL general log dosya birikimine yönelik çözümler.

Kullanıcı veri dosyası birikimi

Kullanıcı veri dosyaları zamanla büyür ve yönetilmezse depolama alanını doldurabilir. blob, text veya uzun varchar türündeki sütunlar büyük veri dosyası boyutlarına yaygın olarak katkıda bulunur. Depolama alanı dolduğunda RDS, veri kaybını önlemek için örneği kilitler.

Kullanılmayan verileri temizleyerek çözün:

• Artık ihtiyaç duyulmayan tabloları veya verileri kaldırmak için drop veya truncate kullanın.

• Büyük nesne verileri için depolama alanı kullanımını azaltmak amacıyla verileri depolamadan önce sıkıştırın.

Daha fazla bilgi için bkz. RDS for MySQL veri dosyası birikimine yönelik çözümler.

Dizin dosyası birikimi

Veritabanı dizinleri disk dosyaları olarak depolanır. Verimsiz bir dizinleme ilkesi veya çok sayıda ikincil dizin, dizin dosyalarının büyümesine ve depolama alanının tükenmesine neden olabilir.

Dizinleme stratejinizi optimize edin:

• Uygun alanlarda dizin oluşturun: Sıkça sorgulanan, sıralanan veya tablo birleştirmelerinde kullanılan alanlarda dizin oluşturun. Toplam dizin dosyası boyutunu azaltmak için mümkün olduğunca tek sütunlu dizinler yerine bileşik dizinler kullanın.

• Kullanılmayan dizinleri kaldırın: Yedek olan veya artık hiçbir sorgu tarafından referans verilmeyen dizinleri silin.