Amazon RDS PostgreSQL'den AlloyDB'ye geçiş

· Levent Güneş · 4 dk okuma · PostgreSQL , AlloyDB , AWS , Google Cloud , Migrasyon

Selamlar, bu yazımda Amazon RDS PostgreSQL üzerindeki bir veritabanını Google Cloud AlloyDB'ye nasıl taşıyacağımıza bakacağız. İki ayrı bulut arasında bir migrasyon (göç) yapıyoruz; yani işin içinde sadece veritabanı değil, ağ tarafı da var. Lafı uzatmadan başlayalım.

İlk akla gelen yöntem genelde pg_dump ile dökümü almak ve hedefte geri yüklemek. Çalışır, evet; ama büyük bir veritabanında saatlerce kesinti demek. Açıkçası bu çağda kimsenin gönlü razı olmaz. Bunun yerine Google'ın Database Migration Service (DMS) aracını kullanacağız. DMS, RDS PostgreSQL'i kaynak olarak desteklediği için logical replication üzerinden sürekli akışlı bir kopya tutuyor; cutover anında downtime saniyeler mertebesine düşüyor.

Mimarinin kabaca özeti

Akış şu şekilde işliyor:

  1. RDS PostgreSQL, WAL (Write-Ahead Log) kayıtlarını logical replication ile dışarı veriyor.
  2. DMS bu replication stream'ini AWS-GCP arasındaki VPN ya da interconnect üzerinden okuyor.
  3. Veriler GCP tarafındaki VPC'de çalışan AlloyDB cluster'ına yazılıyor.
  4. Replication güncel hâle gelince uygulama bağlantıları AlloyDB'ye çevriliyor.

Buradaki kritik nokta şu: RDS'in private IP'si, GCP tarafından routable olmak zorunda. Yani iki bulut arasında ya bir Cloud VPN tüneli ya da dedicated interconnect kuruyorsunuz. Şahsi kanaatim, ilk denemelerde VPN yeter; production'da kalıcı bir çözüm olarak değerlendirin.

RDS tarafini logical replication'a hazirlamak

RDS'te wal_level=logical doğrudan değiştirilemez; parameter group üzerinden rds.logical_replication=1 set ediliyor ve sonrasında instance reboot şart. Reboot sonrası kontrol için:

SHOW wal_level;
-- 'logical' donmesi gerekiyor

Bu adımı atlarsanız DMS connection profile'i oluşturuyor ama job başlatınca anlamsız bir hata alıyorsunuz. Bir keresinde bunu unutup yarım saat boş yere debug etmiştim, dikkat edin.

Aglar konusabiliyor mu?

VPN tüneli ayağa kalktıktan sonra GCP tarafında bir test VM'i açıp bağlantıyı doğrulayın. RDS ICMP'ye cevap vermez; o yüzden ping yerine nc ile PostgreSQL portuna vurun:

nc -zv <RDSPrivateIp> 5432 -w 5

open görüyorsanız tamam. Görmüyorsanız security group, route table ve GCP firewall'larını sırayla geçmek gerek. Bu kısım migrasyonun en sinir bozucu yeridir, ben uyarmış olayım.

DMS connection profile ve job

GCP tarafında önce hedef AlloyDB cluster'ını, sonra iki connection profile'i (kaynak RDS ve hedef AlloyDB) ve son olarak CONTINUOUS tipinde bir migration job oluşturuyorsunuz. Job başladığında önce mevcut veriyi taşıyor (full dump fazı), ardından replication moduna geçiyor.

İlerlemeyi izlemek için job'un state ve phase alanlarına bakıyoruz; RUNNING + CDC görüyorsak değişiklik yakalama (change data capture) modundayız demektir. Replication lag'in sıfıra yaklaşması bu fazda olur.

Cutover anini iyi planlayin

Cutover, migrasyonun en stresli dakikalarıdır. Şu sırayı izleyin:

  1. Uygulamayı bakım moduna alın, RDS'e yazılan trafiği durdurun.
  2. Replication lag'in sıfırlanmasını bekleyin (genellikle saniyeler).
  3. AlloyDB'yi promote edin; artık bağımsız bir primary.
  4. Uygulamanın connection string'ini AlloyDB endpoint'ine çevirin.
  5. Trafiği aç, log'lara dik dik bakın.

Connection string tarafında değişiklik genelde böyle:

# Onceki: RDS
DATABASE_URL = 'postgresql://kullanici:sifre@rds-endpoint.amazonaws.com:5432/uretim'

# Sonraki: AlloyDB
DATABASE_URL = 'postgresql://kullanici:sifre@10.0.0.5:5432/uretim'

Sırrı AWS Secrets Manager'da tutuyorsanız, GCP Secret Manager'a taşımayı da bu adımda yapın. Yarım yamalak bırakmayın; production'da ortada kalmış secret kadar hayatı zorlaştıran az şey var.

Sik karsilasilan hatalar

  • rds.logical_replication'i unutmak: Parameter group'u atadığınızı sanıyorsunuz ama reboot atmadığınız için aktif değil. Reboot şart, pending-reboot durumu sizi yanıltmasın.
  • VPN yerine public endpoint zorlamak: RDS'i public yapıp GCP'den bağlanmak akla gelse de güvenlik ve gecikme açısından kötü fikir. VPN kurmaktan kaçmayın.
  • Desteklenmeyen extension'lar: RDS'te kurulu olan her extension AlloyDB'de olmayabilir. Önce pg_extension'ı listeleyin, AlloyDB dokümanıyla karşılaştırın. Aksi hâlde job ortasında patlıyor.
  • Cutover'da rollback planinin olmamasi: RDS instance'ını hemen kapatmayın. En az bir hafta açık tutun, problem çıkarsa geri dönebilesiniz.
  • Replication lag'i izlememek: phase alanına bakmadan cutover'a geçmek tehlikeli. Lag sıfır değilken promote ederseniz veri kaybedersiniz.

Kapanis

Bu yazıda RDS PostgreSQL'den AlloyDB'ye DMS üzerinden geçişin ana hatlarını gördük. Bana sorarsanız bu işin asıl zor kısmı veritabanı değil, iki bulut arasındaki ağ tarafı; oraya hâkim olduktan sonra DMS gerisini sessiz sedasız hallediyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.