How-To Guides

PostgreSQL Veritabanı Göçünü Ustalaşma: Kapsamlı Bir Kılavuz

Oct 13, 2026 · 5 views
devopspostgresqldatabase migrationdata migrationpg_dump

Veritabanı göçü, yazılım mühendisliğindeki en kritik ve yüksek riskli görevlerden biridir. 9.6 sürümünden 15'e yükseltme yapıyor, AWS RDS gibi bulut altyapılarına yerel sunuculardan geçiş yapıyor veya barındırma sağlayıcıları arasında değişim yapıyor olmanız, başarısız bir göçün veri kaybına ve önemli kesintilere yol açabileceği gerçeğini değiştirmez. Bu kılavuz, PostgreSQL veritabanlarını göç ettirmek için en güvenilir yöntemleri, güvenlik, hız ve minimum kesinti dengesini gözeterek ele alır.

Doğru Stratejiyi Seçme

Komutlara dalınmadan önce, kesinti toleransınıza ve veri hacminize dayanarak uygun stratejiyi seçmeniz gerekir. İki temel yaklaşım Mantıksal Yedekleme ve Geri Yükleme ile Fiziksel/Mantıksal Replikasyondur.

  • Mantıksal Yedekleme (pg_dump): Küçük ve orta ölçekli veritabanları için veya minimum kesinti kabul edilebilir olduğunda en iyisidir. Verileri SQL veya özel format dosyaları olarak dışa aktarır.
  • Mantıksal Replikasyon: Neredeyse sıfır kesinti gerektiren büyük veritabanları için idealdir. Son geçişe kadar değişiklikleri gerçek zamanlı olarak akıtır.

Yöntem 1: pg_dump ve pg_restore Kullanımı

pg_dump aracı, mantıksal yedeklemeler için endüstri standardıdır. Şema farkındalığına sahiptir ve karmaşık veri türlerini, işlevleri ve tetikleyicileri işleyebilir. Üretim ortamlarında, paralel geri yükleme ve seçici tablo kurtarma imkânı tanıması için her zaman özel formatı (-Fc) kullanın.

Adım 1: Dump Oluşturma

Kaynak veritabanınıza bağlanın ve sıkıştırılmış, özel format bir arşiv oluşturun.

# Tüm tabloları, şemaları ve verileri dump edin
pg_dump -h old-db-host -p 5432 -U postgres -Fc -f production_backup.dump mydb

# Büyük veritabanları için süreci hızlandırmak paralel işçiler kullanın
pg_dumpall -h old-db-host -p 5432 -U postgres -Fc -f full_cluster_backup.dump

Adım 2: Aktarma ve Geri Yükleme

Yedek dosyasını scp veya bulut depolama kullanarak yeni sunucuya güvenli bir şekilde aktarın. Ardından verileri yeni örneğe geri yükleyin. Performans için paralel geri yükleme kritiktir.

# Yeni örnekte boş bir veritabanı oluşturun
createdb -h new-db-host -U postgres mydb_new

# Paralel işçilerle geri yükleyin
pg_restore -h new-db-host -p 5432 -U postgres -d mydb_new -j 4 --no-owner production_backup.dump

Not: --no-owner bayrağı, tüm nesnelerin mevcut kullanıcıya ait olmasını sağlayarak, orijinal kullanıcı yeni sunucuda yoksa izin sorunlarını önler.

Yöntem 2: Mantıksal Replikasyon ile Sıfır Kesinti

Kesintinin kabul edilemez olduğu devasa veritabanları için mantıksal replikasyon, yeni örneğin eski örnekle senkron kalmasını sağlar. Bunun için PostgreSQL 10 veya üzeri sürüm gereklidir.

Yapılandırma Adımları

  1. Kaynak Veritabanı: WAL arşivlemeyi etkinleştirin veya yeterli max_wal_senders değerinden emin olun.
  2. Hedef Veritabanı: Bir replikasyon yuvası oluşturun.
  3. Başlatma: Fiziksel kurulum için pg_basebackup veya saf mantıksal senkronizasyon için mantıksal replikasyon yuvaları kullanın.

Hedef sunucuda, WAL kayıtlarını tutmak için bir replikasyon yuvası oluşturun:

CREATE REPLICATION SLOT my_rep_slot LOGICAL "pgoutput";

Kaynak sunucuda, replikasyon için tüm tabloları yayınlayın:

CREATE PUBLICATION my_pub FOR ALL TABLES;

Hedef sunucuda, veri akışını başlatmak için bir abonelik oluşturun:

SUBSCRIBE my_sub TO my_pub
CONNECTION 'host=old-db-host port=5432 user=replicator password=secret'
WITH (copy_data = true);

Abonelik yakalandığında (pg_stat_subscription kontrol ederek doğrulayın), eski veritabanına yazmaları durdurabilir, son geçişi yapabilir ve aboneliği silebilirsiniz.

Doğrulama ve En İyi Uygulamalar

Doğrulama olmadan bir göçe asla güvenmeyin. Geri yüklemeden sonra, kaynak ve hedef arasındaki satır sayılarını ve kritik veri örneklerini karşılaştırmak için checksum sorguları çalıştırın.

-- Kritik bir tablo için satır sayısını kontrol edin
SELECT COUNT(*) FROM orders;

-- Eksik dış anahtar bütünlüğünü kontrol edin
SELECT COUNT(*) FROM child_table WHERE id NOT IN (SELECT id FROM parent_table);

Temel en iyi uygulamalar şunları içerir:

  • Staging'de Test Edin: Göçü her zaman önce üretim benzeri bir ortamda provası yapın.
  • Göçten Önce Yedek Alın: Başlamadan önce kaynağın tam bir yedeğinin olduğundan emin olun.
  • Disk I/O'yu İzleyin: Büyük dump'lar disk bant genişliğini doyurabilir; pg_dump kullanıyorsanız planlamayı düşük yoğunluklu saatlere bırakın.
  • Şema Uyumluluğu: Ana sürümler arasında geçiş yapıyorsanız (ör. 9.6'dan 12'ye), pg_upgrade kontrol modunu kullanarak terk edilen özellikleri kontrol edin.

Sonuç

Doğru göç yolunu seçmek, spesifik kısıtlamalarınıza bağlıdır. Çoğu uygulama için, özel biçimlendirme ile pg_dump sağlam ve basit bir çözüm sunar. Ancak, yüksek kullanılabilirlik gereksinimleri olan hayati sistemler için mantıksal replikasyon, gerçek zamanlı senkronizasyonun güvenlik ağını sağlar. Bu adımları izleyerek ve veri bütünlüğünü titizlikle doğrulayarak, PostgreSQL veritabanlarını güvenle ve minimum riskle göç ettirebilirsiniz.

Share:
Related Posts