esnek PostgreSQL için Azure Veri Tabanı sunucudaki sınırlar

Aşağıdaki bölümlerde, PostgreSQL için Azure Veri Tabanı esnek sunucular için kapasite ve işlevsel sınırlar açıklanmaktadır. İşlem, bellek ve depolama için kaynak katmanları hakkında bilgi için işlem ve depolama makalelerine bakın.

En fazla bağlantı sayısı

Aşağıdaki tabloda, her fiyatlandırma katmanı ve sanal çekirdek yapılandırması için varsayılan en fazla bağlantı sayısı gösterilmektedir. PostgreSQL için Azure Veri Tabanı esnek sunucu, PostgreSQL için Azure Veri Tabanı esnek sunucunun fiziksel çoğaltması ve izlenmesi için 15 bağlantı ayırır. Bu nedenle, tablo maksimum kullanıcı bağlantısı değerini toplam maksimum bağlantıdan 15 azaltır.

Ürün adı vCores Bellek boyutu En fazla bağlantı sayısı En fazla kullanıcı bağlantısı
Patlama kapasiteli
B1ms 1 2 GiB 50 35
B2'ler 2 4 GiB 429 414
B2ms 2 8 GiB 859 844
B4ms 4 16 GiB 1,718 1,703
B8ms 8 32 GiB 3,437 3,422
B12ms 12 48 GiB 5.000 4,985
B16ms 16 64 GiB 5.000 4,985
B20ms 20 80 GiB 5.000 4,985
Genel Amaçlı
D2s_v3 / D2ds_v4 / D2ds_v5 / D2ads_v5 2 8 GiB 859 844
D4s_v3 / D4ds_v4 / D4ds_v5 / D4ads_v5 4 16 GiB 1,718 1,703
D8s_v3 / D8ds_V4 / D8ds_v5 / D8ads_v5 8 32 GiB 3,437 3,422
D16s_v3 / D16ds_v4 / D16ds_v5 / D16ads_v5 16 64 GiB 5.000 4,985
D32s_v3 / D32ds_v4 / D32ds_v5 / D32ads_v5 32 128 GiB 5.000 4,985
D48s_v3 / D48ds_v4 / D48ds_v5 / D48ads_v5 48 192 GiB 5.000 4,985
D64s_v3 / D64ds_v4 / D64ds_v5 / D64ads_v5 64 256 GiB 5.000 4,985
D96ds_v5 / D96ads_v5 96 384 GiB 5.000 4,985
Bellek için optimize edilmiş
E2s_v3 / E2ds_v4 / E2ds_v5 / E2ads_v5 2 16 GiB 1,718 1,703
E4s_v3 / E4ds_v4 / E4ds_v5 / E4ads_v5 4 32 GiB 3,437 3,422
E8s_v3 / E8ds_v4 / E8ds_v5 / E8ads_v5 8 64 GiB 5.000 4,985
E16s_v3 / E16ds_v4 / E16ds_v5 / E16ads_v5 16 128 GiB 5.000 4,985
E20ds_v4 / E20ds_v5 / E20ads_v5 20 160 GiB 5.000 4,985
E32s_v3 / E32ds_v4 / E32ds_v5 / E32ads_v5 32 256 GiB 5.000 4,985
E48s_v3 / E48ds_v4 / E48ds_v5 / E48ads_v5 48 384 GiB 5.000 4,985
E64s_v3 / E64ds_v4 / E64ds_v5 / E64ads_v5 64 432 GiB 5.000 4,985
E96ds_v5 / E96ads_v5 96 672 GiB 5.000 4,985

Ayrılmış bağlantı yuvaları şu anda 15 adet olup değişebilir. Sunucudaki toplam ayrılmış bağlantıları düzenli olarak doğrulamanızı öneririz. Bu sayıyı, reserved_connections ve superuser_reserved_connections parametrelerinin değerlerini toplayarak hesaplarsınız. Kullanılabilir kullanıcı bağlantısı sayısı üst sınırı: max_connections - (reserved_connections + superuser_reserved_connections).

Sistem, işlem için seçtiğiniz ürün adına göre esnek PostgreSQL için Azure Veri Tabanı sunucu örneğini sağladığınızda max_connections parametresi için varsayılan değeri hesaplar. Ürün seçiminde örneği destekleyen işlemde yapılan sonraki değişiklikler, o örneğin parametresi için max_connections varsayılan değer üzerinde herhangi bir etkiye sahip olmayacaktır. Bir örneğe atanan ürünü her değiştirdiğinizde, parametrenin değerini max_connections de önceki tablodaki değerlere göre ayarlamanızı öneririz.

max_connections değerini değiştirme

PostgreSQL için Azure Veri Tabanı esnek sunucunuzu ayarladığınızda, işleyebileceği en yüksek eşzamanlı bağlantı sayısını otomatik olarak belirler. Sunucunuzun yapılandırması bu sayıyı belirler ve değiştiremezsiniz.

Ancak, belirli bir zamanda kaç bağlantıya izin verebileceğini ayarlamak için ayarını kullanabilirsiniz max_connections . Bu ayarı değiştirdikten sonra, yeni sınırın çalışmaya başlaması için sunucunuzu yeniden başlatmanız gerekir.

Dikkat

değerini max_connections varsayılan ayarın ötesinde artırmak mümkün olsa da, buna karşı öneride bulunuruz.

İş yükü genişleyip daha fazla bellek talep ettiğinde örnekler sorunlarla karşılaşabilir. Bağlantı sayısı arttıkça bellek kullanımı da artar. Belleği sınırlı olan örnekler kilitlenmeler veya yüksek gecikme süresi gibi sorunlarla karşılaşabilir. Çoğu bağlantı boşta olduğunda için daha yüksek bir değer max_connections kabul edilebilir olsa da, etkin hale geldikten sonra önemli performans sorunlarına yol açabilir.

Daha fazla bağlantıya ihtiyacınız varsa, bunun yerine bağlantı havuzu yönetimi için yerleşik Azure çözümü olan PgBouncer'ı kullanmanızı öneririz. İşlem modunda kullanın. Başlamak için, 2 ile 5 aralığındaki sanal çekirdekleri çarparak konservatif değerler kullanmanızı öneririz. Daha sonra sorunsuz bir çalışma sağlamak için kaynak kullanımını ve uygulama performansını dikkatle izleyin. PgBouncer hakkında ayrıntılı bilgi için bkz. PostgreSQL için Azure Veritabanı'nda PgBouncer.

Bağlantılar sınırı aştığında aşağıdaki hatayı alabilirsiniz:

FATAL: sorry, too many clients already.

Çok fazla sayıda eşzamanlı bağlantıya sahip yoğun bir veritabanı için PostgreSQL için Azure Veri Tabanı esnek bir sunucu kullandığınızda, kaynaklar üzerinde önemli bir yük olabilir. Bu yük, özellikle aynı anda çok sayıda bağlantı kurulduğunda ve bağlantıların kısa süreleri olduğunda (60 saniyeden kısa) yüksek CPU kullanımına neden olabilir. Bu faktörler, bağlantıları ve bağlantı kesilmelerini işlemek için harcanan süreyi artırarak genel veritabanı performansını olumsuz etkileyebilir.

PostgreSQL için Azure Veri Tabanı esnek bir sunucudaki her bağlantı, boşta veya etkin olmasına bakılmaksızın veritabanınızdan önemli miktarda kaynak tüketir. Bu tüketim, disk ve kilit çekişmesi gibi yüksek CPU kullanımının ötesinde performans sorunlarına yol açabilir. PostgreSQL Wiki'deki Veritabanı Bağlantılarının Sayısı makalesinde bu konu daha ayrıntılı olarak ele alınmıştır. Daha fazla bilgi edinmek için bkz. Azure Postgres'te bağlantı performansını belirleme ve çözme.

İşlevsel sınırlamalar

Aşağıdaki bölümlerde, PostgreSQL için Azure Veri Tabanı esnek sunucularınız için nelerin desteklendiği ve nelerin desteklenmediğinden ilgili önemli noktalar listelenmektedir.

Ölçeklendirme işlemleri

  • Şu anda sunucu depolama alanının ölçeğini artırmak için sunucunun yeniden başlatılması gerekir.
  • Sunucu depolama alanı yalnızca 2 kat artırımlarla ölçeklendirilebilir. Ayrıntılar için bkz . Depolama .
  • Sunucu depolama boyutunun azaltılması desteklenmez. Depolama boyutunu küçültmek için dökümü alıp yeni PostgreSQL için Azure Veri Tabanı esnek bir sunucuya geri yüklemeniz gerekir.

Storage

  • Depolama boyutunu yapılandırdıktan sonra azaltamazsınız. İstenen depolama boyutuna sahip yeni bir sunucu oluşturmanız, el ile döküm ve geri yükleme işlemi gerçekleştirmeniz ve veritabanlarınızı yeni sunucuya geçirmeniz gerekir.
  • Depolama kullanımı 95% ulaştığında veya kullanılabilir kapasite 5 GiB'den azsa (hangisi daha fazlaysa), sistem disk dolu durumlarla ilişkili hataları önlemek için sunucuyu otomatik olarak salt okunur moda geçirir. Nadir durumlarda, veri büyüme hızı salt okunur moda geçmek için gereken süreyi aşıyorsa sunucunuzda depolama alanı tükenebilir. Bu sorunlardan kaçınmak için depolama otomatik büyütmeyi etkinleştirebilir ve iş yükü taleplerinize göre depolama alanınızı otomatik olarak ölçeklendikleyebilirsiniz.
  • Depolama boyutunu artırma gibi eylemleri proaktif bir şekilde gerçekleştirebilmeniz için storage usedstorage percent veya belirli eşikleri aştığında uyarı kuralları ayarlamanızı öneririz. Örneğin, depolama yüzdesi %80 kullanımı aşarsa bir uyarı ayarlayabilirsiniz.
  • Mantıksal çoğaltma kullanıyorsanız, ilgili abone artık mevcut değilse birincil sunucudaki mantıksal çoğaltma slotunu silmeniz gerekir. Aksi takdirde, önceden yazılan günlük (WAL) dosyaları birincilde birikir ve depolama alanını doldurur. Depolama belirli bir eşiği aşarsa ve mantıksal çoğaltma yuvası kullanımda değilse (kullanılamayan abone nedeniyle), PostgreSQL için Azure Veri Tabanı esnek bir sunucu kullanılmayan mantıksal çoğaltma yuvasını otomatik olarak bırakır. Bu eylem, birikmiş WAL dosyalarını serbest bırakır ve depolama alanı doldurulduğundan sunucunuzun kullanılamaz duruma gelmesini engeller.
  • Tablespaces oluşturma işlemi desteklenmez. Veritabanı oluşturuyorsanız tablo alanı adı sağlamayın. PostgreSQL için Azure Veri Tabanı esnek sunucu, şablon veritabanının devraldığı varsayılan tablo alanını kullanır. Hizmet, sunucu yeniden başlatmaları ve yüksek erişilebilirlik (HA) yük devretmeleri gibi olaylardan sonra bu tür nesnelerin kalıcı kalacağını garanti edemediğinden, geçici tablo alanı gibi bir tablo alanı sağlamak güvenli değildir.
  • Yalnız Bırakılmış Veri Dosyaları ve Disk Kullanımı Tutarsızlıkları: Nadir durumlarda PostgreSQL, diskteki yalnız bırakılmış veri dosyalarını geride bırakabilir. Bu dosyalar artık veritabanının sistem kataloğunda (tüm tabloları ve verileri izleyen) ilgili girdilere sahip değildir. Bu durum, bir tablo oluşturulup başarıyla tamamlanamayan bir işlem içinde doldurulursa (örneğin, bir sunucu çökmesi veya kesinti nedeniyle), veritabanının bildirdiği boyut ile gerçek disk kullanımı arasında bir uyumsuzluğa yol açabilir. Bu davranış PostgreSQL topluluk kod tabanından gelir ve Azure özgü değildir. PostgreSQL topluluğu sorunun farkında ve gelecek sürümlerde otomatik temizlemeye yönelik iyileştirmeleri araştırıyor. Daha fazla bilgi için bkz. PostgreSQL: PostgreSQL'de Yalnız Bırakılmış Dosyalar. Bu durum beklenmedik şekilde yüksek disk veya depolama tüketimine yol açabilir.
    • Algılama: Veritabanı tarafından bildirilen boyutu (gibi SELECT pg_database_size('your_database')sorguları kullanarak) gerçek disk kullanımı için Azure portalı ölçümleriyle karşılaştırın. Önemli bir tutarsızlık varsa, bunun nedeni yalnız bırakılmış dosyalar olabilir. Öyleyse:
      • Alan kazanmak için etkilenen tablolarda VACUUM FULL komutunu çalıştırın (not: Bu yoğun kaynak kullanır, tablo kilidi gerektirir ve kapalı kalma süresi gerektirebilir).
      • Alternatif olarak, kapalı kalma süresi olmadan yeniden düzenleme için pg_repack veya pg_squeeze uzantıları gibi araçları kullanın, ancak önce üretim dışı bir ortamda test edin.
      • Disk kullanım eşikleri için Azure portalı ölçümlerini izleyin. Sorun devam ederse veya emin değilseniz yardım için Azure Desteği'ne başvurun.
    • Nasıl önlenir: Tamamlanmamış işlemleri en aza indirmek için uygulamalarınızda işlemlerin düzgün yönetildiğinden emin olun. Azure portalı ölçümleri aracılığıyla disk kullanımını düzenli olarak izleyin. Desteklenen en son PostgreSQL sürümüne yükseltme, ilgili sorunlar için topluluk düzeltmeleri içerebilir.

Ağ Kurma

  • Şu anda bir sanal ağdan içeri ve dışarı taşımayı desteklemiyoruz.
  • Şu anda genel erişimin bir sanal ağda dağıtımla birleştirilmesi desteklenmiyor.
  • Sanal ağlar güvenlik duvarı kurallarını desteklemez. Bunun yerine ağ güvenlik gruplarını kullanabilirsiniz.
  • Genel erişim veritabanı sunucuları genel İnternet'e bağlanabilir; örneğin, aracılığıyla postgres_fdw. Bu erişimi kısıtlayamazsınız. Sanal ağlardaki sunucuların ağ güvenlik grupları aracılığıyla giden erişimi kısıtlanabilir.

Yüksek ulaşılabilirlik

Erişilebilirlik bölgeleri

  • Şu anda sunucuların farklı bir kullanılabilirlik alanına el ile taşınmasını desteklemiyoruz. Ancak, bekleme alanı olarak tercih edilen kullanılabilirlik bölgesini kullanarak HA'yı açabilirsiniz. Bekleme bölgesini oluşturduktan sonra, yük devretme işlemini bu bölgeye gerçekleştirebilir ve ardından HA'yı kapatabilirsiniz.

Postgres altyapısı, uzantılar ve PgBouncer

  • PostgreSQL için Azure Veri Tabanı esnek sunucu bölümleme, mantıksal çoğaltma ve yabancı veri sarmalayıcıları dahil olmak üzere PostgreSQL altyapısının tüm özelliklerini destekler.
  • PostgreSQL için Azure Veri Tabanı esnek sunucu tüm contrib uzantıları ve daha fazlasını destekler. Daha fazla bilgi için bkz. PostgreSQL uzantıları.
  • Hızla artırılabilir sunucuların şu anda yerleşik PgBouncer bağlantı havuzu oluşturucuya erişimi yoktur.

Durdurma/başlatma işlemleri

  • PostgreSQL için Azure Veri Tabanı esnek sunucuyu durdurduktan sonra, yedi gün sonra otomatik olarak başlatılır.

Zamanlanan bakım

  • Özel bakım penceresini haftanın herhangi bir günü/saati olarak değiştirebilirsiniz. Ancak, bakım bildirimini aldıktan sonra yaptığınız değişikliklerin sonraki bakım üzerinde hiçbir etkisi olmaz. Değişiklikler yalnızca aşağıdaki aylık zamanlanmış bakımla geçerlilik kazanır.

Sunucu yedeklemeleri

  • Sistem yedeklemeleri yönetir. Şu anda yedeklemeleri el ile çalıştıramazsınız. Bunun yerine pg_dump kullanmanızı öneririz.

  • İlk anlık görüntü tam yedektir ve sonraki anlık görüntüler diferansiyel yedeklerdir. Diferansiyel yedeklemeler, yalnızca son anlık görüntü yedeklemesinden bu yana değişen verileri yedekler.

    Örneğin, veritabanınızın boyutu 40 GB ve sağlanan depolama alanınız 64 GB ise, ilk anlık görüntü yedeklemesi 40 GB'tır. Şimdi, 4 GB’lık veriyi değiştirirseniz, bir sonraki diferansiyel anlık görüntü yedeğinin boyutu yalnızca 4 GB olacaktır. İşlem günlükleri (önceden yazma günlükleri), tam ve değişiklik yedeklemelerinden ayrıdır ve sürekli olarak arşivlenir.

Sunucu geri yükleme

  • Belirli bir noktaya geri yükleme (PITR) özelliğini kullandığınızda, sistem yeni sunucuyu temel alan sunucuyla aynı işlem ve depolama yapılandırmalarıyla oluşturur.
  • Sistem, bir yedeklemeden geri yükleme yaptığınızda sanal ağlardaki veritabanı sunucularını aynı sanal ağlara geri yükler.
  • Geri yükleme sırasında oluşturulan yeni sunucu, özgün sunucuda var olan güvenlik duvarı kurallarına sahip değil. Yeni sunucu için ayrı güvenlik duvarı kuralları oluşturmanız gerekir.
  • Farklı bir aboneliğe geri yüklemeyi desteklemiyoruz. Geçici bir çözüm olarak, sunucuyu aynı abonelik içinde geri yükleyebilir ve ardından geri yüklenen sunucuyu farklı bir aboneliğe geçirebilirsiniz.

Security

  • PostgreSQL 14 ve sonraki sürümler MD5 karmasını devre dışı bırakır ve sistem yalnızca SCRAM-SHA-256 yöntemini kullanarak yerel Postgres parolalarını karma hale getirmektedir.

İlgili içerik

  • Last updated on