PolarDB:Data management and cleaning

Alıkoyma ilkesi

Binlog dosyaları için aşağıdaki alıkoyma ilkeleri geçerlidir:

• Binlog etkinleştirildiğinde dosyalar varsayılan olarak 3 gün boyunca saklanır. 3 günden eski dosyalar otomatik olarak silinir.

  Not

  • 23 Kasım 2023 tarihinden önce satın alınan PolarDB for MySQL kümeleri için varsayılan Binlog alıkoyma süresi iki haftadır (14 gün).

  • 17 Ocak 2024 tarihinden önce satın alınan PolarDB for MySQL kümeleri için varsayılan Binlog alıkoyma süresi bir haftadır (7 gün).

• Binlog devre dışı bırakıldıktan sonra mevcut Binlog dosyaları süresiz olarak saklanır ve otomatik olarak silinmez.

  Not

  Binlog dosyalarını silmek için Binlog etkin durumdayken Binlog alıkoyma süresi parametresini (loose_expire_logs_hours veya binlog_expire_logs_seconds) küçük bir değere ayarlamanız gerekir. Dosyaların süresi dolduktan ve otomatik olarak silindikten sonra Binlog'u devre dışı bırakabilirsiniz.

Alıkoyma süresini değiştirin

Binlog alıkoyma süresini aşağıdaki gibi değiştirebilirsiniz:

• MySQL 5.6: Binlog alıkoyma süresini ayarlamak için loose_expire_logs_hours parametresini (değer aralığı: 0 ila 2376, saat cinsinden, varsayılan değer: 72) değiştirebilirsiniz. 0 değeri, Binlog dosyalarının otomatik olarak silinmediği anlamına gelir.

• MySQL 5.7MySQL 8.0: Binlog alıkoyma süresini ayarlamak için binlog_expire_logs_seconds parametresini (değer aralığı: 0 ila 4294967295, saniye cinsinden, varsayılan değer: 259200) değiştirebilirsiniz. 0 değeri, Binlog dosyalarının otomatik olarak silinmediği anlamına gelir.

Geçmiş dosyaları temizleyin

Binlog alıkoyma süresi parametresini (loose_expire_logs_hours veya binlog_expire_logs_seconds) değiştirdikten sonra kümedeki geçmiş Binlog dosyaları hemen temizlenmez. Geçmiş dosyaları temizlemek için aşağıdaki üç yöntemden birini kullanabilirsiniz:

• Otomatik temizlemeyi bekleyin: Kümedeki son Binlog dosyası maksimum depolama boyutuna (parametre max_binlog_size) ulaştığında sistem yeni bir Binlog dosyasına geçer ve bu geçmiş Binlog dosyaları otomatik olarak temizlenir.

• Manuel temizleme: Ayrıcalıklı bir hesap kullanarak flush binary logs komutunu çalıştırın; bu işlem Binlog dosyası geçişini hemen tetikler ve süresi dolmuş Binlog dosyalarını temizler.

• Kümeyi yeniden başlatın: Küme yeniden başlatıldığında sistem geçmiş Binlog dosyalarını otomatik olarak temizler.

Commit edilmemiş işlemleri belirleyin ve sonlandırın

1. Veritabanında oturum açın: PolarDB konsolu adresine gidin, hedef kümenin Basic Information sayfasını tıklayın ve DMS üzerinden PolarDB for MySQL kümesinde oturum açmak için sağ üst köşedeki Log on to Database düğmesini tıklayın.

2. Commit edilmemiş işlemleri bulun: Uzun süredir devam eden commit edilmemiş işlemleri kontrol etmek için aşağıdaki komutu çalıştırın.

   SELECT * FROM INFORMATION_SCHEMA.innodb_trx;

   trx_started (işlem başlangıç zamanı) önemli ölçüde eski olan veya trx_state (işlem durumu) uzun bir süre boyunca RUNNING durumunda kalan işlemlere odaklanın. trx_mysql_thread_id (iş parçacığı kimliği) değerini kaydedin.

3. İşlemi sonlandırın: İşinizin etkilenmeyeceğini doğruladıktan sonra hedef işlemi sonlandırmak için KILL komutunu çalıştırın.

   kill [Thread ID];

Temizleme ilerlemesini izleyin

İşlemlere karşılık gelen iş parçacıklarını temizledikten sonra mevcut Undo history ilerlemesini kontrol etmeniz gerekir. Undo history uzunluğu hızla artmaya devam ediyorsa arka plan temizleme (purge) performansını ayarlamanız gerekir.

1. Temizleme ilerlemesini izleyin: Undo history uzunluğunu gözlemlemek için aşağıdaki komutu çalıştırın.

   SELECT COUNT FROM INFORMATION_SCHEMA.innodb_metrics WHERE name = 'trx_rseg_history_len';

   Değer 1 milyonu aşarsa veya mevcut baskı gerçekten yüksekken birkaç dakika boyunca yükselmeye devam ederse temizleme hızı yazma hızına yetişemez.

2. Temizleme parametrelerini ayarlayın: Temizleme verimliliğini artırın.

   1. Her temizleme toplu işinin daha büyük olması için innodb_purge_batch_size parametresini artırın.

   2. Daha fazla temizleme iş parçacığı eklemek için innodb_purge_threads parametresini artırın. Bu değeri küme teknik özelliklerindeki CPU çekirdek sayısına ayarlamanızı öneririz.

      Not

      Bu işlem kümeyi yeniden başlatır. Yoğun olmayan saatlerde yapmanızı öneririz.

İşgal edilen alanı geri kazanın

Undo history uzunluğu azalıp stabilize olduktan sonra undo logları tarafından işgal edilen alanı temizlemek istiyorsanız Undo truncate özelliğini etkinleştirebilirsiniz.

• Özelliği etkinleştirin: innodb_undo_log_truncate parametresini ON olarak ayarlayın.

• Tetikleyici mekanizma: Tek bir undo dosyası innodb_max_undo_log_size değerini aştığında Undo truncate işlemi tetiklenir.

• Sürüm sınırlamaları: Bazı önceki sürümlerde Undo truncate ile ilgili bilinen hatalar bulunmaktadır. Kümenizde bu parametrenin değiştirilmesine izin verilmiyorsa en son küçük sürüme yükseltmeniz gerekir.

• Hemen devre dışı bırakın: Bu özellik, küme yük devretme ve yeniden başlatma işlemleri sırasında ek yük getirir. Alan geri kazanma tamamlandıktan hemen sonra bu parametreyi tekrar OFF olarak ayarlamanızı öneririz; özellikle en son küçük sürüme yükseltme gibi bakım işlemlerinden önce. Bu özelliği yalnızca gerektiğinde etkinleştirin.

PolarDB for MySQL kümeleri, birincil düğüm ile salt okunur düğümler arasındaki veri senkronizasyonu için Binlog yerine Redo loglarını kullanır.

• Günlük yedeklemeleri olmadan yerel Redo logları 2 GB ila 11 GB arasında depolama alanı kaplar ve maksimum 11 GB'a ulaşabilir. Buna arabellek havuzundaki 8 Redo logu (8 GB), yazılan Redo logu (1 GB), önceden oluşturulan Redo logları (1 GB) ve son Redo logu (1 GB) dahildir.

• Günlük yedeklemeleri ile yerel Redo logları, yedekleme tamamlandıktan sonra yaklaşık bir saat boyunca saklanır. Yazma hızı yüksekse (örneğin 35 MB/s'yi aşarsa) geçici Redo log birikimi oluşabilir.

Temizleme kuralları

Redo logları manuel temizlemeyi desteklemez. Günlük yedeklemesi tamamlandıktan sonra otomatik olarak temizlenir ve manuel müdahale gerektirmez.