AWS RDS Read Replica Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

Veritabanı yükünüz artmaya başladığında ve okuma sorguları production’ınızı yavaşlatmaya başladığında, ilk aklınıza gelen çözüm genellikle sunucuyu büyütmek oluyor. Ama bu her zaman doğru hamle değil. AWS RDS Read Replica, okuma yükünü ana veritabanınızdan ayırmanın en temiz ve ölçeklenebilir yollarından biri. Bu yazıda Read Replica’nın ne olduğunu, nasıl kurulduğunu ve production ortamında nasıl yönetileceğini adım adım ele alacağız.

Read Replica Nedir ve Ne Zaman Kullanılır?

Read Replica, ana RDS instance’ınızın (primary/master) asenkron olarak kopyalandığı salt okunur bir veritabanı instance’ıdır. Uygulamanızın SELECT sorguları bu replica’ya yönlendirilirken, INSERT/UPDATE/DELETE işlemleri hâlâ primary’a gider.

Şöyle bir senaryo düşünün: E-ticaret platformunuzun ürün listeleme sayfaları saniyede yüzlerce sorgu atıyor. Bunların büyük çoğunluğu SELECT * FROM products WHERE category_id = ? gibi sorgular. Bu yükü primary’dan alıp replica’ya taşıdığınızda hem primary’ınız write işlemlerine odaklanabiliyor hem de toplam veritabanı kapasitenizdeki dramatik bir artış sağlıyorsunuz.

Read Replica’nın mantıklı olduğu durumlar şunlardır:

  • Raporlama ve analitik sorgular: Uzun süren, kaynak tüketen raporları primary’dan ayırmak için
  • Okuma ağırlıklı uygulamalar: 80/20 veya daha fazla okuma/yazma oranına sahip sistemler
  • Coğrafi dağıtım: Farklı bölgelerdeki kullanıcılara yakın veri sunmak için cross-region replica
  • Felaket kurtarma hazırlığı: Replica’yı bağımsız bir instance’a promote ederek DR senaryosu

Şunu açıkça belirteyim: Read Replica, Multi-AZ ile aynı şey değil. Multi-AZ senkron replikasyon yaparak yüksek erişilebilirlik sağlar ve otomatik failover destekler. Read Replica ise asenkron çalışır, okuma ölçeklendirmesi içindir ve manuel promotion gerektirir.

Ön Gereksinimler

Başlamadan önce şunların hazır olduğundan emin olun:

  • Çalışan bir RDS Primary instance (MySQL, MariaDB, PostgreSQL, Oracle veya SQL Server)
  • AWS CLI yapılandırılmış ve yeterli IAM yetkilerine sahip
  • Automated backups primary instance’da etkin olmalı (bu zorunlu)
  • VPC ve Security Group yapılandırması

Automated backup kontrolü için:

aws rds describe-db-instances 
  --db-instance-identifier my-production-db 
  --query 'DBInstances[0].BackupRetentionPeriod' 
  --output text

Eğer bu komut 0 dönüyorsa, Read Replica oluşturamazsınız. Backup retention’ı en az 1 güne çekmeniz gerekiyor.

AWS Console ile Read Replica Oluşturma

Konsol üzerinden yapacaksanız adımlar oldukça düz:

RDS dashboard’a gidin, primary instance’ı seçin, Actions menüsünden Create read replica seçeneğine tıklayın. Burada dikkat etmeniz gereken ayarlar:

  • DB instance identifier: Anlamlı bir isim verin, örneğin my-production-db-replica-1
  • Instance class: Primary ile aynı veya daha küçük olabilir. Raporlama için kullanıyorsanız bazen daha büyük de seçebilirsiniz
  • Multi-AZ deployment: Replica’nın kendisi de Multi-AZ olabilir, kritik sistemlerde bunu aktif edin
  • Publicly accessible: Production’da genellikle hayır
  • Destination region: Cross-region replica için farklı bir bölge seçin

AWS CLI ile Read Replica Oluşturma

CLI ile daha fazla kontrol elde ediyorsunuz ve bu yaklaşım infrastructure as code açısından da daha temiz:

aws rds create-db-instance-read-replica 
  --db-instance-identifier my-production-db-replica-1 
  --source-db-instance-identifier my-production-db 
  --db-instance-class db.r6g.large 
  --availability-zone eu-west-1b 
  --port 3306 
  --auto-minor-version-upgrade 
  --publicly-accessible false 
  --tags Key=Environment,Value=production Key=Role,Value=read-replica 
  --region eu-west-1

Oluşturma işlemi başladıktan sonra durumu takip edebilirsiniz:

aws rds describe-db-instances 
  --db-instance-identifier my-production-db-replica-1 
  --query 'DBInstances[0].DBInstanceStatus' 
  --output text

creating durumundan available durumuna geçmesi instance büyüklüğüne göre 10-45 dakika sürebilir. Hazır olduğunda replica endpoint’ini alın:

aws rds describe-db-instances 
  --db-instance-identifier my-production-db-replica-1 
  --query 'DBInstances[0].Endpoint.Address' 
  --output text

Terraform ile Read Replica

Eğer infrastructure’ınızı Terraform ile yönetiyorsanız, bu daha sürdürülebilir bir yaklaşım:

# main.tf
resource "aws_db_instance" "primary" {
  identifier           = "my-production-db"
  engine               = "mysql"
  engine_version       = "8.0.35"
  instance_class       = "db.r6g.large"
  allocated_storage    = 100
  storage_encrypted    = true
  
  username             = var.db_username
  password             = var.db_password
  
  backup_retention_period = 7
  backup_window           = "03:00-04:00"
  maintenance_window      = "Mon:04:00-Mon:05:00"
  
  multi_az             = true
  
  tags = {
    Environment = "production"
    Role        = "primary"
  }
}

resource "aws_db_instance" "read_replica" {
  identifier             = "my-production-db-replica-1"
  replicate_source_db    = aws_db_instance.primary.identifier
  instance_class         = "db.r6g.large"
  
  # Replica'da backup gerekmeyebilir, primary'dan alınıyor
  backup_retention_period = 0
  skip_final_snapshot     = true
  
  auto_minor_version_upgrade = true
  publicly_accessible        = false
  
  tags = {
    Environment = "production"
    Role        = "read-replica"
  }
}

Bu konfigürasyonu apply etmek için:

terraform init
terraform plan -out=tfplan
terraform apply tfplan

Replikasyon Gecikmesini İzlemek

Read Replica’nın en kritik metriği replication lag‘dir. Bu değer, replica’nın primary’dan ne kadar geride kaldığını saniye cinsinden gösterir.

CloudWatch üzerinden bu metriği görüntüleyebilirsiniz:

aws cloudwatch get-metric-statistics 
  --namespace AWS/RDS 
  --metric-name ReplicaLag 
  --dimensions Name=DBInstanceIdentifier,Value=my-production-db-replica-1 
  --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%S) 
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) 
  --period 300 
  --statistics Average Maximum 
  --output table

Replikasyon gecikmesi için alarm kurmak iyi bir pratik. Gecikme 30 saniyeyi aştığında uyarı alacak bir alarm oluşturalım:

aws cloudwatch put-metric-alarm 
  --alarm-name "RDS-ReplicaLag-High" 
  --alarm-description "Read Replica gecikme yüksek" 
  --metric-name ReplicaLag 
  --namespace AWS/RDS 
  --statistic Maximum 
  --dimensions Name=DBInstanceIdentifier,Value=my-production-db-replica-1 
  --period 60 
  --evaluation-periods 3 
  --threshold 30 
  --comparison-operator GreaterThanThreshold 
  --alarm-actions arn:aws:sns:eu-west-1:123456789:db-alerts 
  --ok-actions arn:aws:sns:eu-west-1:123456789:db-alerts

MySQL üzerinde gecikmeyi doğrudan veritabanından da kontrol edebilirsiniz, replica’ya bağlanın ve:

mysql -h my-production-db-replica-1.xxxx.eu-west-1.rds.amazonaws.com 
  -u admin -p -e "SHOW SLAVE STATUSG" | grep -E "Seconds_Behind_Master|Running"

PostgreSQL için replica üzerinde:

psql -h my-production-db-replica-1.xxxx.eu-west-1.rds.amazonaws.com 
  -U admin -d mydb 
  -c "SELECT now() - pg_last_xact_replay_timestamp() AS replication_delay;"

Uygulamayı Read Replica’ya Yönlendirmek

Replica kurulumu tamam, şimdi asıl iş: uygulamanızı doğru yönlendirmek. Bunu yapmanın birkaç yolu var.

Uygulama seviyesinde bağlantı ayrımı en yaygın yaklaşım. Python/Django örneği:

# settings.py
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': 'my-production-db.xxxx.eu-west-1.rds.amazonaws.com',
        'NAME': 'myapp',
        'USER': 'admin',
        'PASSWORD': os.environ.get('DB_PASSWORD'),
        'PORT': '3306',
    },
    'replica': {
        'ENGINE': 'django.db.backends.mysql',
        'HOST': 'my-production-db-replica-1.xxxx.eu-west-1.rds.amazonaws.com',
        'NAME': 'myapp',
        'USER': 'admin',
        'PASSWORD': os.environ.get('DB_PASSWORD'),
        'PORT': '3306',
        'TEST': {
            'MIRROR': 'default',
        },
    }
}

DATABASE_ROUTERS = ['myapp.routers.ReadWriteRouter']
# routers.py
class ReadWriteRouter:
    def db_for_read(self, model, **hints):
        return 'replica'
    
    def db_for_write(self, model, **hints):
        return 'default'
    
    def allow_relation(self, obj1, obj2, **hints):
        return True
    
    def allow_migrate(self, db, app_label, model_name=None, **hints):
        return db == 'default'

ProxySQL veya RDS Proxy kullanarak uygulama kodunu değiştirmeden de trafik yönlendirmesi yapılabilir. RDS Proxy’nin read/write endpoint ayrımı bu açıdan çok kullanışlı.

Read Replica Promote Etmek

Disaster recovery senaryosunda ya da primary’ı kapatıp replica’yı bağımsız instance haline getirmeniz gerektiğinde promotion yaparsınız. Promote edilen instance artık write kabul eder ve replikasyondan kopar.

aws rds promote-read-replica 
  --db-instance-identifier my-production-db-replica-1 
  --backup-retention-period 7 
  --preferred-backup-window "03:00-04:00"

Promote işlemi tamamlandıktan sonra durum kontrolü:

aws rds describe-db-instances 
  --db-instance-identifier my-production-db-replica-1 
  --query 'DBInstances[0].{Status:DBInstanceStatus,ReadReplicaSourceDBInstanceIdentifier:ReadReplicaSourceDBInstanceIdentifier}' 
  --output json

ReadReplicaSourceDBInstanceIdentifier alanı boş geliyorsa promotion başarılı demektir. Artık bu instance bağımsız çalışıyor.

Cross-Region Read Replica

Farklı coğrafyalardaki kullanıcılara düşük latency sunmak veya bölgesel DR planınız varsa cross-region replica mantıklı. Dikkat etmeniz gereken nokta, cross-region trafik için veri transfer ücreti oluşuyor.

aws rds create-db-instance-read-replica 
  --db-instance-identifier my-production-db-replica-us 
  --source-db-instance-identifier arn:aws:rds:eu-west-1:123456789:db:my-production-db 
  --db-instance-class db.r6g.large 
  --source-region eu-west-1 
  --region us-east-1 
  --kms-key-id arn:aws:kms:us-east-1:123456789:key/your-key-id

Cross-region replica için şifreli storage kullanıyorsanız, hedef bölgede ayrı bir KMS key oluşturmanız gerekiyor, kaynak bölgenin KMS key’i kullanılamıyor.

Güvenlik Yapılandırması

Read Replica için ayrı bir security group oluşturmak ve sadece gerekli uygulamaların erişimine izin vermek iyi bir pratik:

# Read replica için ayrı security group
aws ec2 create-security-group 
  --group-name rds-read-replica-sg 
  --description "Read Replica erişim kuralları" 
  --vpc-id vpc-xxxxxxxxx

# Sadece uygulama sunucularından erişim
aws ec2 authorize-security-group-ingress 
  --group-id sg-xxxxxxxxx 
  --protocol tcp 
  --port 3306 
  --source-group sg-yyyyyyyyy

# Replica'ya security group uygula
aws rds modify-db-instance 
  --db-instance-identifier my-production-db-replica-1 
  --vpc-security-group-ids sg-xxxxxxxxx 
  --apply-immediately

Read Replica üzerinde ayrı bir veritabanı kullanıcısı oluşturmak da önerilir, özellikle raporlama araçları için sadece SELECT yetkisi verilmiş kullanıcılar kullanılmalı. Replica üzerinde DDL/DML çalıştıramazsınız, bu normal, ama create user gibi işlemler primary üzerinde yapılır ve otomatik replikalanır.

Performans Optimizasyonu

Read Replica’dan maksimum verim almak için bazı ayarları gözden geçirmeniz gerekiyor.

Parameter Group ayarları: Replica için ayrı bir parameter group oluşturabilir ve okuma odaklı optimizasyonlar yapabilirsiniz. Örneğin innodb_buffer_pool_size değerini artırmak okuma performansını ciddi şekilde artırır.

# Yeni parameter group oluştur
aws rds create-db-parameter-group 
  --db-parameter-group-name mysql80-replica-params 
  --db-parameter-group-family mysql8.0 
  --description "Read replica optimized parameters"

# Okuma odaklı parametre ayarları
aws rds modify-db-parameter-group 
  --db-parameter-group-name mysql80-replica-params 
  --parameters "ParameterName=innodb_buffer_pool_size,ParameterValue={DBInstanceClassMemory*3/4},ApplyMethod=pending-reboot" 
               "ParameterName=query_cache_type,ParameterValue=1,ApplyMethod=pending-reboot" 
               "ParameterName=query_cache_size,ParameterValue=268435456,ApplyMethod=pending-reboot"

# Parameter group'u replica'ya uygula
aws rds modify-db-instance 
  --db-instance-identifier my-production-db-replica-1 
  --db-parameter-group-name mysql80-replica-params 
  --apply-immediately

Read Replica ölçeklendirme: Tek bir replica yetmediğinde birden fazla oluşturabilirsiniz. MySQL için 5, PostgreSQL için 5, Aurora için 15 adede kadar replica destekleniyor.

# İkinci replica oluştur
aws rds create-db-instance-read-replica 
  --db-instance-identifier my-production-db-replica-2 
  --source-db-instance-identifier my-production-db 
  --db-instance-class db.r6g.xlarge 
  --availability-zone eu-west-1c

Birden fazla replica kullandığınızda önünüze load balancer koymak mantıklı. AWS’in kendi çözümü RDS Proxy bu işi güzel yapıyor, ya da uygulama seviyesinde round-robin bağlantı havuzu kullanabilirsiniz.

Maliyet Optimizasyonu

Read Replica ek maliyet demek, dolayısıyla akıllıca kullanmak lazım. Birkaç pratik öneri:

Raporlama replica’nız sadece mesai saatlerinde kullanılıyorsa, gece durduramayacağınız için (RDS instance’ları durdurulamıyor, silinip yeniden oluşturulabilir), bunun yerine Aurora Serverless veya scheduled instance type değişikliği düşünülebilir.

Storage maliyetleri açısından replica, primary ile aynı storage boyutunu kullanmak zorunda değil. Eğer sadece son X günün verisini raporlamak istiyorsanız, bunu uygulama mimarisinde çözmek daha mantıklı.

Reserved Instance alırken replica’larınızı da hesaba katın. Uzun vadeli kullanacaksanız RI önemli tasarruf sağlar.

Yaygın Sorunlar ve Çözümleri

Replikasyon durması: Bazen replica primary’dan kopabilir. Bu genellikle büyük DDL işlemleri, disk dolması veya ağ sorunlarından kaynaklanır. AWS bu durumda genellikle otomatik olarak yeniden senkronize etmeye çalışır ama bazen replica’yı silip yeniden oluşturmanız gerekebilir.

Yüksek replikasyon gecikmesi: Primary’da çok fazla write işlemi olduğunda replica geride kalabilir. Çözümler arasında primary instance’ı büyütmek, write işlemlerini optimize etmek veya replica için daha güçlü bir instance seçmek sayılabilir. Büyük batch işlemler gecenin geç saatlerine almak da gecikmeyi azaltır.

Replica üzerinde bağlantı hatası: Uygulamanız primary down olduğunda replica’ya bağlanmaya çalışıyorsa ve read-only hata alıyorsa, promotion yapmadan write çalışamaz. Failover senaryolarınızı önceden test edin.

Storage full: Replica’da binary log’lar veya geçici tablolar disk dolduğunda replikasyon durur. CloudWatch’ta FreeStorageSpace metriğini izleyin.

Sonuç

Read Replica kurulumu tek başına bir amaç değil, daha büyük bir veritabanı yönetimi stratejisinin parçası. Doğru kurulduğunda primary veritabanınızın üzerindeki yükü dramatik şekilde azaltıyor ve uygulamanızın okuma kapasitesini yatay olarak ölçeklendirmenizi sağlıyor.

Bu yazıda anlattıklarımı özetlersek: primary instance’da backup’ın aktif olduğunu doğrulayın, replica’yı CLI veya Terraform ile oluşturun, replikasyon gecikmesini CloudWatch alarm’larıyla izleyin ve uygulamanıza okuma/yazma yönlendirmesini düzgünce ekleyin.

Bir sonraki adım olarak Aurora Global Database’e göz atmanızı öneririm, özellikle multi-region gereksiniminiz varsa standart Read Replica’dan çok daha gelişmiş bir çözüm sunuyor. Ama büyük çoğunluk için bu yazıda anlattıkları uygulamak zaten büyük fark yaratacaktır.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir