Raporlama için PostgreSQL okuma replikaları: panelleri hızlı tutun

Neden raporlama birincil veritabanınızı yavaşlatabilir

Sık görülen bir durum şöyle görünür: uygulama günün çoğunda iyi çalışıyor, sonra biri bir gösterge paneli açar ve aniden checkout'lar, girişler veya destek araçları yavaşlamaya başlar. Hiçbir şey “down” değil, ama her şey daha yavaş. Genellikle bu, birincil veritabanınızın aynı anda iki yönde çekiliyor olmasıdır.

Transaction (günlük uygulama işleri) kısa ve seçicidir. Birkaç satır okur veya günceller, indeksleri kullanır ve hızlı biter, böylece diğer istekler ilerleyebilir. Raporlama sorguları farklı davranır. Genellikle çok veri tarar, birden çok tabloyu join eder, sonuçları sıralar ve günler/aylar boyunca toplamlar hesaplar. Yazmaları doğrudan engellemese bile, uygulamanızın ihtiyaç duyduğu aynı paylaşılan kaynakları tüketebilirler.

Panellerin bir OLTP veritabanına zarar verdiği yaygın yollar şunlardır:

• Ağır okuma işlemleri CPU, bellek ve disk I/O için rekabet yaratır
• Büyük taramalar önbellekten "sıcak" sayfaları çıkarır, böylece normal sorgular yavaşlar
• Büyük sıralamalar ve GROUP BY'lar diske taşınır ve yük patlamaları oluşturur
• Uzun süren sorgular içsel rekabeti artırır ve anlık yükselmeleri uzatır
• Ad-hoc filtreler (tarih aralıkları, segmentler) yükü öngörülemez kılar

Bir okuma replikası, verileri birincil sunucunuzdan sürekli kopyalayan ve salt okunur sorguları cevaplayabilen ayrı bir PostgreSQL sunucusudur. Raporlama için PostgreSQL okuma replikalarını kullanmak, panellerin ağır işleri başka yerde yapmasına izin verir; böylece birincil, hızlı transaction'lara odaklanabilir.

Erken belirlemeniz gereken beklenti: replikalar okumalara yardımcı olur, yazmalara değil. Standart bir replikaya güvenle INSERT/UPDATE gönderemezsiniz ve sonuçlar birincilden biraz geride olabilir çünkü replikasyon zaman alır. Birçok pano için bu makul bir takastır: biraz daha az "taze" sayılar karşılığında tutarlı uygulama performansı.

İç paneller (örneğin AppMaster içinde) oluşturuyorsanız, bu ayrım genellikle iyi eşleşir: uygulama yazmaları birincile yapmaya devam ederken, raporlama ekranları replikayı sorgular.

PostgreSQL'de okuma replikaları nasıl çalışır (düz İngilizce ile)

Bir PostgreSQL okuma replikası, ana (birincil) veritabanınızın neredeyse gerçek zamanlı kopyasını tutan ikinci bir veritabanı sunucusudur. Birincil yazmaları (INSERT, UPDATE, DELETE) işler. Replika çoğunlukla okumalar (SELECT) sunar, böylece raporlama sorguları günlük transaction'larla rekabet etmez.

Bir dakikada birincil vs replikaya bakış

Birincili yoğun bir mağazadaki kasiyer gibi düşünün: her satış stok, ödeme ve siparişleri güncellediği için cevap verebilir kalması gerekir. Replika ise toplamları ve eğilimleri gösteren bir ekran gibidir. Kasiyerin yaptıklarını izler ve kısa bir süre sonra kendi görünümünü günceller.

Arkada, PostgreSQL değişiklikleri birincilden gönderdiği değişiklik akışını ileterek ve replikada bunları yeniden oynatarak kopyalar. Bu, replikayı aynı yapı ve veriye sahip hale getirir, sadece biraz geride.

Pratikte replikasyon şunları kopyalar:

• Tablo verileri (satırlar)
• İndeks değişiklikleri (böylece sorgular aynı indeksleri kullanabilir)
• Şema değişiklikleri (yeni sütunlar, yeni tablolar ve birçok türde migration)
• Normal SQL yoluyla gerçekleşen diğer çoğu veritabanı değişikliği

Replica'nın çözmediği şeyler: ağır yazmaları sihirli şekilde ucuzlatmaz ve kötü bir şema veya eksik indeks nedeniyle yavaşlayan bir sorguyu düzeltmez. Eğer dashboard sorgunuz replikada da devasa bir tabloyu tarıyorsa, yine de yavaş olabilir. Sadece aynı anda checkout'ı yavaşlatmayacaktır.

İşte bu yüzden raporlama için PostgreSQL okuma replikaları popülerdir: OLTP işleri (hızlı, sık transaction'lar) ile OLAP tarzı işleri (uzun süren okumalar, gruplama ve toplamlar) ayırırlar. İç paneller veya yönetim panelleri (örneğin AppMaster içinde) oluşturuyorsanız, raporlama sayfalarını bir replikaya yönlendirmek genellikle her iki tarafı da memnun etmenin en basit yoludur.

Replikada olması gereken yaygın raporlama iş yükleri

İyi bir kural: bir sorgu çoğunlukla veriyi özetlemek için çok okuma yapıyorsa, replikada çalıştırılması için güçlü bir adaydır. PostgreSQL raporlama replikaları sayesinde checkout akışlarını, girişleri ve diğer transactional işleri panellerin yaptığı ağır işten korursunuz.

En yaygın pano deseni geniş bir tarih aralığı artı birkaç filredir. "Son 90 gün bölge, ürün ve kanal bazında" gibi bir sorgu, nihai grafik sadece 12 çubuk gösterse bile milyonlarca satıra dokunabilir. Bu taramalar birincil veritabanınızla disk okumaları ve önbellek alanı için rekabet edebilir.

Replikada iyi uyan iş yükleri

Çoğu ekip şu tür işleri raporlama veritabanına taşımaya başlar:

• Birden çok tablonun büyük join'leri (orders + items + customers + refunds)
• SUM, COUNT DISTINCT, yüzde hesapları, cohort analizleri gibi agregasyonlar
• Büyük sonuç kümelerini sıralayan ve gruplayan uzun süren sorgular
• Her saat/gün çalışan ve aynı ağır işi tekrar eden planlı raporlar
• İnsanların tıklayıp varyasyonları yeniden çalıştırdığı keşifsel BI oturumları

Bir sorgu "salt okunur" olsa bile CPU, bellek ve I/O yakabilir. Büyük GROUP BY işlemleri diğer sorguları belleğin dışına itebilir. Tekrarlanan taramalar buffer cache'i döndürebilir, bu yüzden birincil daha sık diskten okumaya başlar.

Bağlantı davranışı da önemlidir. Birçok BI aracı kullanıcı başına birden çok bağlantı açar, panelleri birkaç dakikada bir yeniler ve arka planda extract'ler çalıştırır. Bu, bağlantı ve eşzamanlı sorgularda ani zirveler yaratabilir. Bir replika bu zirvelerin güvenle düşeceği bir yer sağlar.

Basit bir örnek: operasyon panonuz sabah 09:00'da yüklenir ve 50 kişi aynı anda açar. Her sayfa görüntüsü birkaç widget tetikler ve her widget farklı bir filtreyle sorgu çalıştırır. Birincilde bu patlama sipariş oluşturmayı yavaşlatabilir. Replikada ise pano daha yavaş veya biraz geride olabilir, ama transaction'lar hızlı kalır.

Eğer AppMaster gibi bir platform içinde iç paneller oluşturuyorsanız, raporlama ekranlarını replikaya bağlamak genellikle kolay bir kazançtır, yeter ki herkes verinin birkaç saniye (veya dakika) geride olabileceğini anlasın.

Takas: tazelik mi hız mı (replikasyon gecikmesi)

Bir okuma replikası, raporlama sorgularını birincilden alarak panelleri hızlandırır. Bedeli ise replikaların genellikle biraz geride olmasıdır. Bu gecikmeye replikasyon gecikmesi denir ve raporlama için PostgreSQL okuma replikalarında ana takastır.

Kullanıcıların fark ettikleri basittir: "bugün" sayısı biraz düşük, en son siparişler eksik veya bir grafik birkaç dakika geç güncelleniyor. Haftalık eğilimin 2 dakika geride olması çoğu insanı rahatsız etmez, ama "ödeme az önce başarılı oldu" gibi bir görünüm yanlışsa sıkıntı çıkar.

Gecikme, birincil replikaya uygulamadan daha hızlı değişiklik ürettiğinde olur. Yaygın nedenler arasında yazma patlamaları (flash satışlar, içe aktarmalar), sınırlı ağ bant genişliği, replikadaki yavaş disk veya replikada değişiklikleri uygulamaya çalışırken CPU ve I/O için rekabet yaratan uzun sorgular bulunur.

Kabul edilebilir gecikmeyi belirlemenin pratik yolu, bunu panonun desteklediği karara göre eşleştirmektir:

• Yönetici KPI panoları: saniyelerden birkaç dakikaya kadar genellikle uygundur.
• Operasyon kuyrukları (sevkiyat, destek): yakın gerçek zaman, genellikle saniyeler hedeflenir.
• Finansal kapanış veya denetimler: canlı değil, kontrollü snapshot'lar üzerinde çalıştırılmalıdır.
• Müşteri tarafı "son siparişlerim": yakın gerçek zaman veya birincil kullanılmalı.

Basit kural: bir rapor en son commit edilmiş transaction'ı içermek zorundaysa, birincile gitmelidir (veya garantili tazelik için tasarlanmış bir sisteme). Tipik örnekler: checkout sırasındaki stok durumu, sahtekarlık kontrolleri ve anında aksiyon tetikleyen her şey.

Örnek: satış ekibi panosu güvenle replikadan okunabilir ve her dakika yenilenebilir. Ancak "sipariş onayı" sayfası birincilden okumalıdır; çünkü yeni verilen bir sipariş için "sipariş bulunamadı" göstermek destek bileti demektir.

Eğer uygulamanız veya no-code aracınız bir veritabanı bağlantısı seçmenize izin veriyorsa (örneğin AppMaster içinde salt okunur ekranları replikaya yönlendirmek), UI'yi değiştirmeden bu ayrımı uygulayabilirsiniz.

Adım adım: panolar için okuma replikası kurma

Panolar için bir replikayı kurmak, genelde başta birkaç net tercih yapmak ve ardından raporlama trafiğini birincilden uzak tutmakla ilgilidir.

1) Doğru topolojiyi belirleyin

Topolojiden başlayın. Tek bir replikası tek bir BI aracı ve birkaç pano için genellikle yeterlidir. Birden fazla replikaya, birçok analistiniz veya gün boyunca veriye vuran birden fazla aracınız olduğunda ihtiyaç vardır. Kullanıcılarınız ana bölgenizden uzaksa bölgesel bir replika panolar için gecikmeyi azaltabilir, ama izlenecek daha fazla yer ekler.

Sonra eşzamanlı mı yoksa eşzamansız mı replikasyon seçeceğinize karar verin. Eşzamanlı replikasyon en iyi tazeliği verir ama yazmaları yavaşlatabilir; bu birçok ekip için amaca ters olur. Eşzamansız genellikle panolar için tercih edilir, yeter ki herkes verinin biraz geride olabileceğini kabul etsin.

2) Replikayı raporlama sunucusu gibi inşa edin

Bir replikayı production'un ucuz bir kopyası gibi düşünmeyin. Raporlama sorguları genellikle daha fazla CPU, sıralamalar için daha fazla bellek ve taramalar için hızlı diskler gerektirir.

İşte PostgreSQL raporlama replikaları için pratik bir kurulum akışı:

• Kaç replika gerektiğine ve nerede bulunmaları gerektiğine karar verin (aynı bölgede mi yoksa kullanıcılara daha yakın mı).\n- Panolarınızın katlanabileceği gecikmeye göre async vs sync seçin.\n- Okuma-ağırlıklı işler için kaynakları sağlayın (CPU, RAM ve disk IOPS genellikle depolama boyutundan daha önemli).\n- Raporlama kullanıcıları ve araçları için ayrı, salt okunur kimlik bilgileri oluşturun.\n- Dashboard sorgularını replikaya yönlendirin (uygulamanızı, BI aracınızı veya küçük bir raporlama servisini replikaya bağlayın).

Yönlendirdikten sonra basit bir testle doğrulayın: bilinen ağır bir pano sorgusu çalıştırın ve artık birincil veritabanı etkinliğinde görünmediğini teyit edin.

AppMaster ile uygulamalar inşa ediyorsanız, bu genellikle raporlama için ayrı bir veritabanı bağlantısı tanımlamak ve bunu sadece pano uç noktaları için kullanmak anlamına gelir; böylece checkout ve diğer transactional akışlar kendi hızlı yolunu korur.

Raporlama kullanıcıları için erişim kontrolü ve güvenlik

Okuma replikası panolar için harikadır, ama yine de güvenlik önlemleri gerekir. Paylaşılan bir kaynak gibi davranın: raporlama araçlarına işlerini yapmaları için yeterli erişimi verin ve kötü bir sorgunun verebileceği zararı sınırlayın.

Başlangıç olarak raporlama için ayrı bir veritabanı kullanıcısı oluşturun. Uygulamanızın ana kimlik bilgilerini yeniden kullanmaktan kaçının, replikaya işaret etseniz bile. Bu etkinliği denetlemeyi, parolaları döndürmeyi ve ayrı ayrı ayrıcalıkları tutmayı kolaylaştırır.

Çoğu ekip için uygun basit bir yaklaşım şudur:

-- Create a dedicated login
CREATE ROLE report_user LOGIN PASSWORD '...';

-- Allow read-only access to a schema
GRANT CONNECT ON DATABASE yourdb TO report_user;
GRANT USAGE ON SCHEMA public TO report_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO report_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO report_user;

-- Put safety limits on the role
ALTER ROLE report_user SET statement_timeout = '30s';
ALTER ROLE report_user SET idle_in_transaction_session_timeout = '15s';

Sonra bağlantı fırtınalarını kontrol edin. Panolar ve BI araçları özellikle birden çok widget yenilerken çok sayıda bağlantı açmayı sever. Raporlama bağlantılarını veritabanında ve pooler'da sınırlandırın ve bunları transactional trafikten ayrı tutun.

Pratik kontrol listesi:

• Salt okunur bir kullanıcı kullanın (INSERT/UPDATE/DELETE yok, şema değişiklikleri yok).
• Uzun sorgular ve boşta oturumlar için rol başına zaman aşımı ayarları koyun.
• Raporlama kullanıcıları için maksimum bağlantıyı güvenli bir sayıda sınırlandırın.
• Yalnızca bir panonun ihtiyaç duyduğu şemalara ve tablolara erişimi kısıtlayın.
• Hassas sütunları (KİŞİSEL VERİ, gizli anahtarlar, tokenlar) maskeleyin veya raporlama görünümlerinden hariç tutun.

Müşteri verisinin kısmi gösterilmesi gerekiyorsa, "insanlar dikkatli olacaktır" varsayımına güvenmeyin. Hassas alanları gizleyen veya hashleyen raporlama görünümleri oluşturun ya da küratörlü bir raporlama şeması tutun. Ekipler AppMaster ile panolar inşa ederken, replikaya ait bağlantı dizesini ve özel raporlama kullanıcısını kullanarak oluşturulan uygulamanın yazma erişimine dokunmadan güvenli okuma yapmasını sağlayın.

Bu kontroller PostgreSQL raporlama replikalarını hızlı, öngörülebilir ve kötüye kullanımı zorlaştırılmış hale getirir.

Panellerinizi şaşırtmadan koruyacak izleme

Bir replika sadece öngörülebilir davranırsa yardımcı olur. Ekipleri genellikle şaşırtan iki şey sessiz replikasyon gecikmesi (panolar "yanlış" görünür) ve replikadaki kaynak patlamalarıdır (paneller yavaşlar). İzleme her ikisini de kullanıcılarınızdan önce yakalamalıdır.

Önce gecikmeyi ölçün ve işletmeniz için "yeterince taze"nin ne anlama geldiği konusunda anlaşın. Birçok raporlama panosu için 30–120 saniye uygundur. Diğerleri (stok veya sahtekarlık gibi) için 5 saniye bile çok fazla olabilir. Ne seçerseniz seçin, bunu görünür kılın ve uyarı verin.

Takip etmeniz gereken pratik sinyaller:

• Replikasyon gecikmesi (zaman ve byte cinsinden). Eşiğinizi birkaç dakika aştığında uyarı verin, sadece tek bir spike ile değil.
• Replika sağlığı: pik raporlama saatlerinde CPU, bellek baskısı ve disk okuma I/O.
• Replikadaki bağlantı doygunluğu (çok fazla pano oturumu veritabanının yavaş olduğunu gösterir).
• Replikadaki yavaş sorgular, replikanın kendi istatistikleri ve logları kullanılarak izlenmeli (birincilin tüm hikâyeyi anlatacağını varsaymayın).
• Autovacuum ve bloat. Tablolar veya indeksler şiştiğinde okumalar kötüleşebilir.

Yavaş sorgu takibi özel dikkat gerektirir. Yaygın bir başarısızlık modu, testte iyi çalışan bir panonun production'da "tam tablo tarama festivaline" dönüşmesidir. Replikada birincilde güvendiğiniz izlemeye sahip olun; en yavaş sorgulara göre toplam zaman ve ortalama zaman gibi metrikleri izleyin.

Son olarak, replika kullanılamaz hale geldiğinde veya çok geride kaldığında uygulamanızın ne yapacağına baştan karar verin. Tek bir davranış seçin ve tutarlı uygulayın:

• Gecikme eşiğini aştığında "veri gecikmeli" bandı gösterin.
• En ağır grafikleri geçici olarak devre dışı bırakıp hafif özetleri tutun.
• Kısa bir süre için önbelleğe düşmüş sonuçlara geri dönün (örneğin son 15 dakika).
• Kritik okumaları sadece belirli ekranlar için birincile yönlendirin.
• Replika toparlanana kadar panoları salt okunur bakım moduna alın.

AppMaster gibi iç paneller oluşturuyorsanız, replikayı ayrı bir veri kaynağı olarak ele alın: onu ayrı izleyin ve panoları tazelik veya performans düştüğünde kademeli olarak bozulacak şekilde tasarlayın.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Bir replikası yardımcı olur, ama raporlama "bedava" yapacak sihirli bir düğme değildir. Çoğu replik probleminin kaynağı, onu limitsiz bir analitik veri ambarıymış gibi muamele edip sonra panoların yavaşlamasına veya yanlış olmasına şaşırmaktır.

Kolay bir kaçırma: replikalar da aşırı yüklenebilir. Birkaç geniş tablo taraması, ağır join'ler veya "SELECT *" dışa aktarmaları CPU ve diski zorlayabilir ve zaman aşımına neden olabilir. Replika birincilden daha küçük donanımda çalışıyorsa (maliyetten tasarruf etmek için yaygın), yavaşlama daha çabuk görülür.

En çok acı veren tuzaklar şunlardır:

• Kritik gerçek zamanlı ekranları replikaya yönlendirmek. Bir pano yeni bir checkout'u doğrulamak veya canlı stok göstermek için kullanılıyorsa, replikasyon gecikmesi verinin eksik görünmesine neden olabilir.
• BI araçlarının çok fazla bağlantı açmasına izin vermek. Bazı araçlar birçok karoyu aynı anda yeniler; her karo kendi oturumunu açabilir. Bağlantı zirveleri replikanın çökmesine neden olabilir.
• İndekslerin yeterli olacağını varsaymak. Bir indeks milyonlarca satırı çeken, yanlış anahtarlarda gruplayan veya limit içermeyen join'leri düzeltmez. Sorgu yapısı ve veri hacmi ekstra indeksten daha önemlidir.
• "Bir kere hızlıydı"nın her zaman hızlı olacağını varsaymak. Veri büyüdüğünde veya çok kişi aynı raporu yenilediğinde bir sorgu yavaşlayabilir.
• Failover davranışı için plan yapmamak. Failover sırasında bir replika promote edilebilir veya değiştirilebilir; istemciler salt okunur hataları veya eski endpoint'lerle karşılaşabilir.

Gerçekçi bir örnek: BI aracınız "bugünün siparişleri" sayfasını her dakika yeniliyor. Eğer her yenileme beş ağır sorgu çalıştırıyorsa ve 20 kişi açık tutuyorsa, bu dakikada 100 ağır sorgu patlaması demektir. Birincil güvenli kalabilir, ama replika çöker.

AppMaster gibi bir platformla iç panolar inşa ediyorsanız, raporlama veritabanını ayrı bir hedef gibi ele alın: kendi bağlantı limitleri ve "güncellik gerekli" kurallarıyla yapılandırın, böylece kullanıcılar kazara geride kalan verilere bağımlı olmaz.

Replikada raporlama hızını artıran tasarım kalıpları

Bir replikası size nefes aldırır, ama her paneli otomatik olarak hızlandırmaz. En iyi sonuçlar, raporlama sorgularınızı daha az, daha öngörülebilir iş yapacak şekilde şekillendirdiğinizde gelir. Bu kalıplar PostgreSQL raporlama replikalarında iyi çalışır çünkü ağır taramaları ve tekrarlanan agregasyonları azaltır.

"Raporlama katmanını" ayırın

Stabil görünümler ve yardımcı tablolar içeren ayrılmış bir raporlama şeması (örneğin reporting) düşünün. Bu, BI araçlarının ve panellerin ham transactional tablolara doğrudan dokunmasını engeller ve optimize edilebilecek tek bir yer sağlar. İyi bir raporlama view'u karmaşık join'leri gizler, böylece pano sorgusu basit kalır.

Ağır işleri önceden toplayın (pre-aggregate)

Bir pano gün boyunca aynı toplamları yeniden hesaplıyorsa (günlük gelir, durumlara göre siparişler, en iyi ürünler), her sayfa yüklemede sıfırdan hesaplamayı bırakın. Bu sayıları zaten gruplanmış olarak saklayan özet tablolar veya materialized view'lar oluşturun.

Yaygın seçenekler:

• Günlük veya saatlik rollup'lar (tarih, bölge, kanal bazında)
• "Son bilinen" snapshot tabloları (stok, hesap bakiyesi)
• Top-N tabloları (en iyi ürünler, en iyi müşteriler)
• Filtrelemeyi hızlandırmak için denormalize edilmiş fact tablolar

Ağır metrikleri zamanlanmış olarak yenileyin

Ön-aggregasyonları planlı işler ile, tercihen düşük trafikli zamanlarda, yenileyin. İş dünyası "her 5 dakikada güncellensin" diyorsa, küçük bir gecikme için çok daha hızlı panolar elde edebilirsiniz. Çok büyük veri setleri için tam yenilemeler yerine artımlı güncellemeler (son çalıştırmadan bu yana eklenen satırlar) genellikle daha ucuzdur.

Kullanıcıların sıkça tıkladığı şeyleri önbelleğe alın

Aynı pano widget'ları tekrar tekrar isteniyorsa, sonuçları uygulama katmanında kısa süreli (30–120 saniye) önbelleğe alın. Örneğin "Bugünün satışları" kutucuğu şirket veya mağaza bazında cache'lenebilir. AppMaster gibi araçlarda bu tür önbellekleme, pano'yu besleyen API uç noktasının etrafına eklemek en kolay yoldur.

Basit kural: bir sorgu yavaş ve popülerse, ya ön-aggregate edin ya önbelleğe alın ya da her ikisi.

Gerçekçi bir örnek: checkout'ı yavaşlatmadan satış raporlaması

Küçük bir e-ticaret uygulamasını hayal edin. Ana veritabanı tüm gün girişler, sepetler, ödemeler ve sipariş güncellemeleriyle meşgul. Aynı zamanda ekip saatlik gelir, en iyi ürünler ve iadeleri gösteren bir pano istiyor.

Değişiklik öncesi, pano ağır sorguları birincil veritabanında çalıştırıyordu. Ay sonuna yaklaşırken biri "son 30 gün ürün bazında" grafiğini açtı ve orders tablosunun büyük bir bölümünü taradı. Checkout yavaşlamaya başladı çünkü bu raporlama sorguları aynı CPU, bellek ve disk okumaları için rekabet ediyordu.

Çözüm basitti: panoyu bir replikaya taşıyın. PostgreSQL raporlama replikaları ile birincil hızlı yazmaya devam ederken replikası uzun okumaları cevaplar. Pano birincilin değil, replikasyon bağlantı dizesine işaret eder.

Ekip ayrıca net tazelik kuralları belirledi:

• Panoda "Veri X dakika önce güncellendi" gösterin
• Normal saatlerde 5 dakikaya kadar gecikmeye izin verin
• Gecikme 10 dakikayı aşarsa, panoyu "gecikmeli moda" alın ve en ağır grafikleri duraklatın
• Checkout ve sipariş güncellemeleri her zaman birincilde kalsın

Değişiklikten sonra sonuç fark edilir oldu. Rapor patlamaları sırasında bile checkout stabil kaldı ve grafikler hızlı yüklendi çünkü transaction'larla mücadele etmiyorlardı.

Kullanıcılara söylemeniz gereken basit: pano "neredeyse gerçek zamanlı"dır, son 10 saniyenin doğruluk kaynağı değildir. Kesin toplamlar gerekiyorsa, planlı bir export veya gün sonu raporu çalıştırılmalıdır.

Uygulamayı AppMaster ile inşa ediyorsanız, baştan itibaren raporlama için ayrı bir salt okunur bağlantı oluşturun ki transactional akışlar öngörülebilir kalsın.

Hızlı kontroller ve sonraki adımlar

Panoları bir replikaya yönlendirmeden önce hızlı bir akıl yürütme yapın. Birkaç küçük ayar ve alışkanlık en yaygın sürprizleri (eski veriler, zaman aşımları ve yanlışlıkla yazma) önler.

Yapılandırmadan önce kontrol listesi:

• Raporlama bağlantılarını salt okunur yapın (ayrı bir kullanıcı kullanın ve salt okunur işlemleri zorunlu kılın).
• Raporlamayı uygulama trafiğinden ayırın (kendi bağlantı havuzu ve mantıklı bağlantı limitleri).
• Replikada panolarınızın dayandığı indekslerin olduğundan emin olun (indeksler replikalar tarafından kopyalanır, ama yeni değişikliklerin eksik olmadığını kontrol edin).
• Bir raporun her şeyi takmaması için statement ve lock timeout'ları ayarlayın.
• Grafiklerin küçük gecikmelere toleransı olduğundan emin olun (gerekirse "as of" zaman damgası gösterin veya dakika bazında yuvarlayın).

Trafik akmaya başladıktan sonra izlemede hafif haftalık rutin olarak devam edin; bunu bir yangın tatbikatı haline getirmeyin. Bu, PostgreSQL raporlama replikaları için özellikle önemlidir; "dün çalışıyordu" durumu veri hacmi büyüdüğünde hızla değişebilir.

Haftalık izleme kısa listesi (10 dakika):

• Replikasyon gecikmesi: tipik gecikmeyi ve pik saatlerdeki en kötü spike'ları izleyin.
• Yavaş sorgular: toplam süreye göre en büyük suçluları takip edin, sadece tekil yavaş çalışmaları değil.
• Bağlantılar: maksimum bağlantılar, pool doygunluğu ve biriken idle bağlantıları kontrol edin.
• Disk ve CPU: replika ağır taramalarda depolamada darboğaz yaşayabilir.
• Başarısız sorgular: zaman aşımı, iptal edilen ifadeler veya yetki hatalarını kontrol edin.

Sonraki adımlar büyük ölçüde yönlendirme kuralları ve bir yedek planla ilgilidir. Hangi uç noktaların her zaman replikadan okunabileceğine (panolar, dışa aktarımlar, yönetici raporları) ve hangilerinin birincilde kalması gerektiğine (gerçek zaman gerektirenler) karar verin. Gecikme sınırınızı aştığında ne olacağını tanımlayın: uyarı göster, bazı sayfalar için okumaları birincile geri yönlendir veya en ağır grafikleri geçici olarak devre dışı bırakın.

İç paneller veya yönetim araçları inşa ediyorsanız, AppMaster panoları hızlıca yayına alırken raporlama ekranlarını replikaya yönlendirmek için pratik bir yol sunabilir; böylece çekirdek transactional uygulamanız sorunsuz çalışmaya devam eder.