PostgreSQL Çoğaltma


45

Bunu sürekli ofisten geçiriyoruz ve soru ortaya çıkmaya devam ediyor. PostgreSQL replikasyonuyla nasıl başa çıkıyorsunuz? Mutlaka gelişmiş kümelerden bahsetmiyorum bile, sadece Master-Slave, Master-MultiSlave ve Master-Master ile basitleştiriliyor. Bunu MySQL için kurmanın genellikle oldukça basit olduğunu düşünüyorum. Yük devretme, özellikle yapılandırılmasının ne kadar kolay olduğu için mükemmel değilse, basittir. Slony ile oynadık, ancak biraz fazla çalışıyor (şema değişiklikleri müdahale gerektirir, yeni veritabanları müdahale gerektirir, vb.). PGPool2 çok güzeldi, bir düğüm kapanana kadar ve tekrar senkronizasyonu tekrarlamak için zarif bir yol bulamadık (her şeyi yıkmak ve düşmüş düğümü yeniden basmak dışında). Temelde işte tipik olarak aradığım:

  • Kolay kurulum (Zor kurulum için karar vereceğim, ancak genişletilmesi kolay)
  • Basit yerine çalışma
  • Düşmüş bir düğümü geri getirmek sadece zaman gerektirir (örneğin, mysql. Sunucu kapanır, onu açarsınız ve çoğaltmanın yetişmesini beklersiniz).
  • Şema değişiklikleri çoğaltmayı bozmuyor
  • Sunucuya yeni bir veritabanı eklemek sorunsuzdur (mysql gibi, bütün bir DB sunucusunu çoğaltabilirsiniz, böylece ana bilgisayarda yeni bir veritabanı oluşturulur, otomatik olarak slave'e yayılır)

MySQL bunların çoğunu oldukça iyi idare ediyor, ancak PostgreSQL için belirli bir düşkünlüğe sahibim. Ayrıca, tek seçeneğimiz olan bazı durumlarımız var ve karışıma çoğaltma eklemek istiyoruz. Şu anda ne kullanıyorsunuz ve çözümünüz hakkında ne hissediyorsunuz? Bu bir MySQL değil PostgreSQL postası değil, söz veriyorum, çünkü yapmaya başladığım şey bu değil. :)


3
Bunun cevabını merak ediyorum. Bir MySQL arkaplanından geliyorsa, PSQL için çoğaltma seçenekleri en azını söylemek için tarımsaldır.
Dave Cheney

Evet, şu ana kadar oynadığım her seçeneğin önemli dezavantajları var. Umarım bariz bir şeyi özlüyorum .. ama sanmıyorum
f4nt

Başka bir şey olmadığından şüpheliyim, ama birisinin beni yanlış olduğunu ispatlaması için istekliyim
Vinko Vrsalovic

BTW, pgsql-general@postgresql.org adresini denediniz mi?
Vinko Vrsalovic

Yanıtlar:


9

Kısa cevap - çevrimiçi salt okunur kölelere ihtiyacınız varsa PostgreSQL için henüz böyle bir çözüm yok.

Şu anda PostgreSQL 9.0'da (İlkbahar / Yaz 2010) yer alan bu alanda devam etmekte olan iki büyük gelişme projesi var:

  • Senkron Çoğaltma:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

  • Sadece sıcak bekleme slave'lerini okuyun:

http://wiki.postgresql.org/wiki/Hot_Standby

Bu arada, MySQL tarzı çoğaltmanın kullanım kolaylığı elde etmeyi hedefleyen eksi hatalar / sorunlar MySQL'in ayrıca kullanıcıların PostgreSQL'in bildiği güvenilirliği.

Tüm bunlar 2008'de PostgreSQL Çekirdek Ekibinin bir bildirisi ile başladı:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

PostgreSQL'in en büyük kullanıcı tabanına sahip bu güne yönelik replikasyon çözümleri Slony-I (yazarlar için daha pahalı, şema değişikliklerini fiddly yapar), WAL shipping / walmgr (Slaves çevrimiçi olarak kullanılamaz) ve Skype / Skytools'tan pgQ / londiste bitmiş bir çözümden daha fazla araç / yapı taşı).

Log Shipping, walmgr ve Slony-I hakkında birkaç şey yazdım.

Daha fazla bilgi için http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 adresini ziyaret edin.


6
Senkron Replikasyon + Sıcak Bekleme şimdi mevcuttur - mevcut tekniklerin iyi bir özeti için bakınız wiki.postgresql.org/wiki/…
David Fraser

5

Ve halkaya başka bir çözüm atmak için: rubyrep.

Gereksinimlerinizle karşılaştırmak için:

  • Kolay kurulum
    Evet, bu aslında rubyrep'in odak noktasıdır.
  • Basit yerine çalışma
    Evet. Aslında rubyrep ana-master replikasyonunu yapar - başarısız olmak için hiçbir işlem yapmak gerekmez. Sadece diğer veritabanını kullanmaya başla.
  • Şema değişiklikleri çoğaltmayı bozmuyor
    Evet.
    Birincil olmayan anahtar değişiklikleri için çoğaltmanın durması bile gerekmez (ancak şemanın her iki tarafta da aynı anda değiştiğinden emin olun)
    Tablo eklemek / kaldırmak için, çoğaltma arka planını yeniden başlatmanız yeterlidir. Bir tablonun yalnızca birincil anahtar sütununu değiştirmek biraz çaba gerektirir.
  • Sunucuya yeni bir veritabanı eklemek sorunsuzdur (mysql gibi, bütün bir DB sunucusunu çoğaltabilirsiniz, böylece ana bilgisayarda yeni bir veritabanı oluşturulur, otomatik olarak slave'e yayılır)
    Bu yalnızca sınırlı bir şekilde desteklenir: her rubyrep setup, bir kerede yalnızca bir veritabanını çoğaltır. (Ancak, birden fazla veritabanı için çoğaltma oluşturmak çok kolaydır.)

4

Sıcak bir okuma-kölesini bir şart olarak kullanmaktan bahsetmediniz, bu yüzden Heartbeat'i paylaşımlı depolama veya DRBD ile kullanmayı önereceğim. Sadece doğru olanı yapıyor ve yönetim bir esinti. Eski Microsoft SQL Server kümelemesinin Linux eşdeğeridir. Bir düğüm aktif ve diğer düğüm ise veriler ikisi arasında paylaşılırken pasif. SQL tabanlı çoğaltma konusunda endişelenmenize gerek yok, çünkü hepsi blok seviyeden aşağıya çekiliyor.

Cidden, okumaya bağlı kölelere ihtiyacınız yoksa, bu en iyi çözümdür. WAL arşiv malzemeleri en iyi şekilde hokeydi ve bir sunucunun yeniden başlatılması için gönderim işlemini bir kez daha keserseniz her şeyi yeniden ayarlamanız gerekir. slony ve londiste hardalı kesmez. Ana kaynak ağacında kalmak ve ticarileşmek istemiyorsanız, Heartbeat en iyi bahistir.


2

Gereksinimlerinizden, PITR'in probleminizi çözmenin en kolay yolu olduğu anlaşılıyor:

Çevrimiçi yedekleme ve anında kurtarma (PITR)

Bağımlı sunucuyu sorgulamanız gerektiğini söylemediniz, bu yüzden PITR haklı olabilir.

PostgreSQL'in 8.0 sürümünden itibaren standart bir parçası olduğundan, çalışmaya başlaması için gereken her şeye zaten sahip olabilirsiniz.

Çok ayrıntılı talimatlar bulursanız, beklemede olan veriye tekli komut görevi oluşturma / yük devretme işlemini yapacak SkyTools WalMgr'a bir göz atın .

Daha karmaşık çoğaltma senaryoları için, Slony-1 konusunda iyi bir deneyime sahiptim, ancak PostgreSQL'in birçok iyi çoğaltma / HA seçeneği var.


ve bu seçenekler ...?
Dave Cheney

... blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html blog yazısında listelenen cevaplardan birisine bakın ...
dpavlin

2

Eşzamansız master / slave replikasyonunu istiyorsanız, Londiste'yi (Skype'tan skytools paketinin bir parçası) düşünün. Wiki.postgresql.org/wiki/Londiste_Tutorial

Kurulumu kolaydır, yeni bir DB eklemek kolaydır, çoğaltma sadece "yakalar".

Yerine çalışma yerine yerleşik değil. Uygulama bağlantı dizgilerinizi değiştirmeniz veya başka bir yazılım katmanının arkasındaki DB bağlantısını gizlemeniz gerekecek.

Bazı şema değişiklikleri kolaydır. Diğerleri daha zor. Bu uygulamanıza bağlıdır. Skytools'un bir sonraki sürümünün (sürüm 3.0) DDL'yi kullanması ve yük devretmeyi kolaylaştıracak özellikler içermesi beklenmektedir.

Slony'yi kullanmak için çok acı verici bulduktan sonra Londiste'ye taşındık.



1

Aradığınızı sağlamanın ücretsiz / açık kaynaklı yolları yoktur. Çok anahtar bir şey istiyorsanız, çeşitli üçüncü taraf ticari çoğaltma çözümlerine bakın.

Şimdi, bir rulo Postgres ile kendi çoğaltma yazma kafalı günlüğünü (WAL) nakliye kullanmanın sıralamak mümkün:

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Bu, temelde sürekli kurtarma moduna ikincil bir düğüm koyabileceğiniz ve işlem günlüklerini her {küçük aralıklı} içine içe aktarabileceğiniz yerdir. Postgres konfigürasyonunda, bir WAL tamamlandığında bir Postgres olduğunda bazı şeyleri yapmanıza izin veren ve bu yüzden hayır olan bazı şeyleri yapmanıza izin veren "saplamalar" bulunur ve bu kurulumun bu "saplamalar" kullanılarak yapılması gereken şeydir.

Ancak, bu master-master ve / veya dairesel çoğaltma yapmanıza izin vermez.

Her durumda, kesinlikle hata için çalışıyor, ama ben "kolay kurulum", "basit yerine çalışma", "kesintisiz" veya benzeri bir şey demezdim.


Bu cevap PITR önerisinin kopyasıdır, çünkü PITR WAL :-) kullanmaktadır :-)
dpavlin



Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.