Read Replicas في PostgreSQL للمتوسط: وزّع 80% من القراءات بدون تعديل سطر كود

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'strong_pwd_here';
SELECT pg_reload_conf();

2) على الـ replica: خد نسخة أساسية وابدأ

3) تأكد إن الـ replication شغّال

المخرج المتوقع: سطر واحد بـ state = streaming و lag_bytes أقل من 4MB في الحالة الطبيعية.

توجيه القراءات في التطبيق

أبسط طريقة لو شغّال Node.js: استخدم pool منفصل للـ replica.

الطريقة الأنضف: استخدم pgpool-II 4.5 أو PgBouncer + HAProxy كـ middleware يتعرّف على نوع الاستعلام تلقائيًا، فالتطبيق يكلّم endpoint واحد بدون منطق إضافي. ده موصوف في pgpool-II Load Balancing docs.

الأرقام الحقيقية: قبل وبعد

القياس على API FastAPI بـ 12,000 طلب/دقيقة (8,400 SELECT و 3,600 write)، DB بـ 38GB على Hetzner CCX23 (8 vCPU، 32GB RAM):

• قبل Replica: P95 latency = 480ms، CPU primary = 92%، connections = 187/200.
• بعد Replica واحد: P95 = 38ms، CPU primary = 41%، CPU replica = 58%.
• تكلفة شهرية إضافية: $54 لسيرفر replica واحد، مقابل $312 كانت هتتدفع لـ vertical scaling لـ CCX33.
• replication lag في الحالة الطبيعية: 12ms متوسط، 180ms في P99 وقت bulk imports.

الـ Trade-offs اللي محدش بيقولهالك

1. Eventual Consistency: لو user عمل UPDATE ثم قرأ مباشرة بعد 50ms، ممكن يقرأ القيمة القديمة. الحل: وجّه الـ read-after-write لنفس الـ primary لمدة ثانية بعد أي كتابة.
2. Long-running queries على الـ replica ممكن تأخّر تطبيق الـ WAL وتعمل lag كبير. hot_standby_feedback = on بيحلها لكن بيخلّي الـ primary يحتفظ بـ dead tuples أكتر.
3. Failover مش مجاني: لو الـ primary سقط، promotion للـ replica محتاج أداة زي Patroni أو repmgr. بدونها ده شغل يدوي ممكن ياخد 8-15 دقيقة.
4. الكتابات لسه bottleneck: Read Replicas مش بيحلوا مشكلة الكتابة. لو 80% من workload كتابة، انت محتاج Sharding أو Citus مش Replica.

متى لا تستخدم Read Replicas

• الـ workload عندك أقل من 1,000 طلب/دقيقة — vertical scaling أرخص وأبسط.
• التطبيق يعتمد على read-after-write strong consistency في كل صفحة (مثل لوحات تداول لحظية).
• القاعدة أصغر من 2GB — كل الـ working set في الذاكرة، الـ bottleneck غالبًا في الـ application أصلاً.
• فريق العمليات ما يقدرش يدير primary + replica + monitoring + failover — التشغيل الخاطئ أسوأ من instance واحد.

الخطوة التالية

افتح الـ postgresql.conf على الإنتاج، فعّل wal_level = replica و max_wal_senders = 10، وشغّل replica واحدة على نفس الـ subnet للتجربة. بعد 24 ساعة شوف pg_stat_replication.replay_lag — لو أقل من ثانية، أنت جاهز توجّه القراءات. ابعتلي الأرقام عندك قبل وبعد.

المصادر

• PostgreSQL 16 Documentation – Streaming Replication
• PostgreSQL 16 – pg_basebackup utility
• PostgreSQL 16 – Hot Standby
• pgpool-II 4.5 – Load Balancing
• Patroni HA Template Documentation
• 2ndQuadrant – Evaluating PostgreSQL Replication
• AWS RDS – Best Practices for PostgreSQL Replication