Technical Tutorials

Veritabanı taşıma, bir geliştiricinin veya DBA'nın yaşam döngüsündeki en kritik işlemlerden biridir. Yerel sunucudan Amazon RDS veya Google Cloud SQL gibi yönetilen bir bulut hizmetine geçiş yapıyor, daha yeni bir ana sürüme yükseltiyor veya şemanızı birden fazla küme arasında yeniden düzenliyor olun, riskler yüksektir. Başarısız bir taşıma işlemi veri kaybına, uzun süreli kesintilere ve ciddi iş etkilerine yol açabilir.

Bu kılavuz, temel yedeklemelerin ötesine geçerek PostgreSQL veritabanlarını taşıma için sağlam, üretim seviyesinde stratejileri keşfeder. Daha küçük veri setleri için tek komutlu çözümler, sıfır kesintili taşıma için sürekli veri senkronizasyonu ve doğrulama ile geri alma için en iyi uygulamaları ele alacağız.

Strateji 1: Klasik pg_dump Yaklaşımı

Daha küçük veritabanları (genellikle 100 GB altı) için veya kesintinin kabul edilebildiği planlı bakım pencereleri sırasında pg_dump, en basit ve güvenilir yöntem olmaya devam eder. Hedef sunucuda geri yüklenebilecek bir SQL betiği veya özel formatlı arşiv oluşturur.

pg_dump'u taşıma bağlamında etkili bir şekilde kullanmanın anahtarı, paralel geri yükleme ve daha fazla esneklik sağlayan özel formatı (-Fc) kullanmaktır.

# Kaynak sunucudan
pg_dump -Fc -h source_host -U source_user -d my_database -f backup.dump

# Hedef sunucuda
pg_restore -h dest_host -U dest_user -d new_database backup.dump

Bu yöntem basit olsa da, uygulamanın veritabanına yazamamadığı bir kesinti süresi gerektirir. Canlı bir uygulamanız varsa, veri tutarlılığını sağlamak için yedekleme işlemi sırasında uygulamanın çevrimdışı olduğundan veya salt okunur bir kopyaya yönlendirildiğinden emin olmalısınız.

Strateji 2: Mantıksal Replikasyonla Sıfır Kesintili Taşıma

Kesintiye tahammülü olmayan kritik uygulamalar için mantıksal replikasyon altın standarttır. Bu yöntem, kaynak ve hedef veritabanlarını sürekli olarak senkronize tutarak trafiği hassas bir anda yönlendirmenize olanak tanır.

Adım 1: Hedefi Hazırlayın

Öncelikle, hedef sunucuda aynı şemaya sahip boş bir veritabanı oluşturun. Hem kaynak hem de hedef sunucularda wal_level değerinin logical olarak ayarlandığından emin olun.

Adım 2: Yayın ve Abonelik Oluşturun

Kaynak sunucuda, taşımak istediğiniz tablolar için bir yayın oluşturun:

CREATE PUBLICATION my_migration_pub FOR TABLE users, orders, products;

Hedef sunucuda, kaynağa bağlanan bir abonelik oluşturun:

CREATE SUBSCRIPTION my_migration_sub
CONNECTION 'host=source_ip dbname=my_database user=replicator password=secret'
PUBLICATION my_migration_pub;

PostgreSQL şimdi veriyi kaynaktan hedefe senkronize etmeye başlayacaktır. İlerlemeyi pg_stat_subscription sistem görünümü üzerinden izleyebilirsiniz. İlk senkronizasyon tamamlandığında ve canlı değişikliklerle yakalandığında, geçiş işlemine devam edebilirsiniz.

Doğrulama ve Geçiş

Trafiği yönlendirmeden önce son bir doğrulama yapın. Her iki örnekteki kritik tablolar için satır sayılarını ve sağlama toplamlarını kontrol edin. Geçişe hazır olduğunuzda, kaynak veritabanındaki yazmaları durdurun (veya tutarlılığı sağlamak için hedefteki aboneliği duraklatın).

-- Son senkronizasyonu sağlamak için aboneliği duraklatın
SELECT pg_subscription_rel.*, pg_stat_replication.*
FROM pg_subscription_rel 
JOIN pg_stat_replication ON pg_subscription_rel.sql_localid = pg_stat_replication.pid;

Replikasyon gecikmesi sıfıra indiğinde, aboneliği devre dışı bırakın, uygulamanızın bağlantı dizesini yeni veritabanına işaret edecek şekilde değiştirin ve yazmaları etkinleştirin. Kararlılığı sağlamak için ilk birkaç saat boyunca uygulamayı yakından izleyin.

Sonuç

Doğru taşıma stratejisini seçmek, veri boyutunuza, kabul edilebilir kesinti sürenize ve altyapı karmaşıklığınıza bağlıdır. Küçük değişiklikler için pg_dump yeterlidir. Kurumsal düzeydeki gereksinimler için mantıksal replikasyon, sorunsuz geçişler için gereken güvenliği ve sürekliliği sağlar. Riskleri azaltmak ve sorunsuz bir işlem sağlamak için üretim ortamında denemeden önce taşıma işleminizi her zaman bir önizleme (staging) ortamında test edin.