PostgreSQL 9.1'de yük devretmeyi otomatikleştirme

PostgreSQL 9.1'de otomatik yük devretme için iki özdeş sunucu nasıl kurulur?

işletim sistemi

Centos 5
PostgreSQL 9.1 kaynaktan derlendi
Postgres kullanıcı hesabı her iki makinede de mevcuttur ve her iki makineye bağlanmak için ssh şifresiz bir anahtara sahiptir.

Geçerli Kurulumum:

Ana sunucu yapılandırması:

postgresql.conf:

listen_address = '*'
wal_level = hot_standby
max_wal_senders = 3
checkpoint_segments = 16    
wal_keep_segments = 8 
archive_mode = on    
archive_command = 'cp "%p" /opt/pgsql91/archive/"%f"'  

pg_hba.conf:

 host  replication   all   10.0.66.1/32      trust
 host  replication   all   10.0.66.2/32      trust

Bekleme Sunucusu

postgresql.conf ve pg_hba.conf ana sunucuda yapılandırılanla aynıdır.

recovery.conf:

 standby_mode = 'on'
 primary_conninfo = 'host=10.0.66.1'
 trigger_file = '/opt/pgsql91/data/trigger.txt'

HzRoot sayesinde, sunucuyu bekleme modundan master'a nasıl geçireceğimizi şimdi anlıyorum.

Aşağıdaki komutları kullanarak, yeni slave'i yeni master ile senkronize edebilir ve daha sonra replikasyon yedekleme ve çalıştırma elde edebilirim.

Yeni master'da (10.0.66.2)

1. su - postgres
2. / opt / pgsql91 / data / içindeki tetikleyici.txt'ye dokunun
3. recovery.conf, recovery.done olur
4. psql -c "; SEÇ pg_start_backup ('yedekleme', doğru)";
5. rsync -a -v -e ssh / opt / pgsql91 / data / 10.0.66.1:/opt/pgsql91/data/ - postmaster.pid'i ekleyin
6. psql -c "; SEÇ pg_stop_backup ()";

Yeni köle (10.0.66.1)

1. recovery.conf dosyasını oluşturun: cp recovery.done to recovery.conf
2. vi recovery.conf ip adresini değiştir: Primary_conninfo = 'host = 10.0.66.2'
3. postgresql başlat

Sorularım şu an:

1. Rolleri değiştirmenin doğru yolu bu mu?
2. Kimse bu süreci otomatikleştirdi, eğer öyleyse ne yaptınız?
3. Eşzamanlı çoğaltma etkinse, yeni ana sunucunun, slave'in yanıt vermesini beklediği için herhangi bir işlem yapmayacağını fark ettim. Ancak diğer sunucu, eski master kapalı olduğu için köle yoktur. Bu doğru mu veya yeni bağımlı çalışırken eşzamanlı çoğaltmayı geçici olarak devre dışı bırakmam gerekir mi?

Repmrg'ye göz atın :

repmgr, DBA'lara ve Sistem yöneticilerine PostgreSQL veritabanları kümesini yönetme konusunda yardımcı olan bir dizi açık kaynak aracıdır.

PostgreSQL 9'da sunulan Otomatik Yedekleme özelliğinden yararlanarak repmgr, yüksek kullanılabilirlik ve ölçeklenebilirlik gereksinimleri ile veritabanı kurma ve yönetme işlemini büyük ölçüde basitleştirir.

repmgr yönetimi ve günlük yönetimi basitleştirir, üretkenliği artırır ve PostgreSQL kümesinin genel maliyetlerini şu şekilde azaltır:

• çoğaltma işleminin izlenmesi; DBA'ların yüksek yayın yapmalarına izin vermek
• geçişler ve başarısızlıklar gibi kullanılabilirlik işlemleri.

İki şey yapar:

1. repmgr: kümenizdeki görevleri gerçekleştiren ve sonra çıkan komut programı
2. repmgrd: kümeyi izleyen ve uzaktan eylemleri otomatikleştirebilen yönetim ve izleme arka plan programı.

Otomatik yük devretme için repmgrd hile yapar ve ağınızda pgPool gibi bir SPOF değildir. Bununla birlikte, tüm deamonları izlemek ve başarısızlıktan sonra onları geri getirmek hala önemlidir.

Sürüm 2.0, RPM'ler de dahil olmak üzere piyasaya sürülmek üzere.

recovery.conf dosyanızda postgres'i master'dan slave'e yük devretmeye bildiren bir satır eklemelisiniz. eklemelisin

trigger_file = '/any/file/to/trigger'

bu dosyayı verilen yolda oluşturduğunuzda. düğümler değişecektir. (dosya sadece bir tetikleyici olan hiçbir şey içermez)

akış çoğaltması hakkında ek bilgi bulabilirsiniz

Öte yandan, bazı hilelerle otomatik olarak oluşturulabilir, ancak izleme araçlarını kullanmak ve manuel olarak başarısız yapmak daha iyi olacaktır.

Bunun için pgpool-II kullanmayı düşünen var mı?

http://pgpool.projects.postgresql.org/contrib_docs/simple_sr_setting/index.html

PostgreSQL için çoğaltma ayarlıyorum. Eski usta geri geldiğinde zor kısım ortaya çıkıyor gibi görünüyor.

Okuduğum kadarıyla, pgpool bunun çoğunu otomatikleştirebilir gibi görünüyor. Ancak PostgreSQL 9.1 zaten mevcut çoğaltma özellikleri kaldıraçlar emin değilim.