ApsaraDB RDS:FAQ about the general query log feature of ApsaraDB RDS for MySQL

RDS neden genel sorgu günlüklerini bir tabloda saklar?

ApsaraDB RDS for MySQL, varsayılan olarak genel sorgu günlüklerini bir dosya yerine veritabanı tablosunda saklar. Bunun iki nedeni vardır:

• Kullanıcılar bir RDS örneğindeki dosyalara doğrudan erişemez; bu nedenle dosya tabanlı günlükler sorgulanamaz veya indirilemez.

• log_output parametresi, hem genel sorgu günlükleri hem de yavaş sorgu günlükleri için çıkış biçimini kontrol eder. RDS yavaş sorgu günlüklerini döndürür ve bunların tablolarda saklanmasını gerektirdiğinden, genel sorgu günlüklerinin de tablolarda saklanması gerekir.

Genel sorgu günlüğü neden depolamayı tüketir?

Örnek üzerinde çalıştırılan her SQL ifadesi bir günlük girişi oluşturur. Genel sorgu günlüğü uzun süre etkin kaldığında veya örnek yüksek sorgu hacmiyle karşılaştığında mysql.general_log tablosu sürekli büyür. Tabloyu periyodik olarak temizlemezseniz örneğin depolama alanını doldurur.

Depolama sorununa genel sorgu günlüğünün neden olduğunu doğrulamak için:

1. Örnek izleme sayfasında depolama kullanımını kontrol edin. sys_data_size alışılmadık derecede büyükse tablo verileri depolama alanını tüketiyor demektir. Ayrıntılar için bkz. İzleme bilgilerini görüntüleyin.

2. Örnek parametrelerini görüntüleyin. general_log değeri ON olarak ayarlanmışsa özellik etkindir.

Genel sorgu günlüğü neden performans sorunlarına yol açar?

Genel sorgu günlüğü etkinleştirildiğinde, bir SQL ifadesi çalıştıran her iş parçacığı mysql.general_log tablosuna bir satır yazmalıdır. Bu yazma işlemi hem meta veri kilitleri (MDL) hem de tablo kilitleri gerektirdiğinden iş parçacıkları tabloya paralel değil, sıralı olarak yazar.

Yüksek bağlantı sayısı altında birçok iş parçacığı bu kilitler için aynı anda yarışır ve bağlantılar Waiting for table level lock durumunda kalır. Bağlantı sayısı arttıkça CPU kullanımı da artar.

Doğrulamak için SHOW PROCESSLIST komutunu çalıştırın veya innodb_trx tablosunu sorgulayın. Çok sayıda bağlantı Waiting for table level lock durumunu gösteriyorsa genel sorgu günlüğü kilit çekişmesine katkıda bulunuyor demektir.

Genel sorgu günlüğü neden kurtarma süresini artırır?

Bir RDS örneği beklenmedik şekilde kapatılırsa genel sorgu günlüğünün çökme işaretleyicisi true olarak ayarlanır. Yeniden başlatıldığında örnek otomatik bir kurtarma işlemi başlatır. RDS örneğindeki tabloların boyutu büyükse bunların geri yüklenmesi uzun sürer ve bu süreçte örnek kullanılamaz durumda kalır. Bu durum kurtarma süresi hedefinizi (RTO) doğrudan uzatır.

Çözüm

1. Yeni günlük girişlerinin yazılmasını durdurmak için general_log değerini OFF olarak ayarlayın. Bkz. Örnek parametrelerini değiştirin.

2. Örneğe yetkili hesap kullanarak bağlanın. Bkz. ApsaraDB RDS for MySQL örneğine bağlanın.

3. Günlük tablosunu temizleyin:

   MySQL 5.6 çalıştıran örneklerde TRUNCATE ifadesi desteklenmez. Bu örnekler için günlüğü temizlemek üzere teknik destek ile iletişime geçin. Sürüme özel özellik desteğinin tam listesi için bkz. Özellikler . Bir yetkili hesap ile TRUNCATE ifadesini çalıştırmak için örneğin desteklenen bir küçük motor sürümünde çalışması gerekir: ApsaraDB RDS for MySQL 5.7 için 20210630 veya üzeri, ApsaraDB RDS for MySQL 8.0 için 20210930 veya üzeri. Daha eski bir küçük motor sürümü çalıştıran örneklerde TRUNCATE ifadesi yetkili hesap için bile başarısız olur. Bu durumda teknik desteğin sizin için günlüğü temizlemesi amacıyla bir destek talebi gönderin.

   TRUNCATE TABLE mysql.general_log;

Günlüğü temizledikten sonra depolama kullanımının azaldığını doğrulamak için örnek izleme sayfasını kontrol edin.

SQL analizi için alternatifler

Normal çalışma sırasında genel sorgu günlüğünü devre dışı bırakın. Yalnızca kısa hata ayıklama oturumları için etkinleştirin, ardından hemen devre dışı bırakın ve tabloyu temizleyin.

Sürekli SQL analizi için bunun yerine aşağıdaki yaklaşımlardan birini kullanın:

• SQL Explorer and Audit (önerilen): SQL ifadelerini otomatik olarak kaydetmek ve analiz etmek için bu özelliği etkinleştirin. Veriler Database Autonomy Service (DAS) içinde saklanır ve RDS örneğinizin depolama alanını tüketmez; bu nedenle örnek performansı üzerinde hiçbir etkisi yoktur. Bkz. SQL Explorer and Audit özelliğini kullanın.

• Geçici genel sorgu günlüğü: Belirli bir sorunu hata ayıklamanız gerekiyorsa genel sorgu günlüğünü etkinleştirin, ardından SQL etkinliğini incelemek için günlük tablosunu sorgulayın:

  SELECT * FROM mysql.general_log;

  Hata ayıklama tamamlandığında özelliği devre dışı bırakın ve tabloyu temizleyin.

Depolama zaten tükendiyse ne yapılmalı

Günlüğü temizleyemeden önce örnek depolama alanı bittiyse depolama kapasitesini genişletin:

• Manuel genişletme: Depolamayı artırmak için örnek teknik özelliklerini değiştirin. Bkz. Örnek teknik özelliklerini değiştirin.

• Otomatik genişletme: Kullanım belirtilen bir eşige ulaştığında sistemin depolamayı genişletmesi için otomatik depolama genişletmeyi yapılandırın. Bkz. Otomatik depolama genişletmeyi yapılandırın.