Veritabanı sunucusu olarak ZFS ana düğümü mü kullanıyorsunuz?

Burada görüldüğü gibi Nexenta'nın önerilen mimarisini temel alan yüksek kullanılabilirlikli küme paylaşılan depolama için çift kafalı ZFS destekli NAS kullanıyorum:

1 JBOD'daki diskler, tek bir 4 TB Postgres veritabanı için veritabanı dosyalarını ve diğer JBOD'daki diskleri 20 TB büyük ham ikili düz dosyalar depolar (büyük yıldız nesnesi çarpışma simülasyonları için küme sonuçları). Başka bir deyişle, Postgres dosyalarını destekleyen JBOD esas olarak rastgele iş yüklerini, simülasyon sonuçlarını destekleyen JBOD ise esas olarak seri iş yüklerini işleyecektir. Her iki kafa düğümü de 256 GB bellek ve 16 çekirdeğe sahiptir. Kümenin her biri Postgres oturumunu sürdüren yaklaşık 200 çekirdeğe sahiptir, bu yüzden yaklaşık 200 eşzamanlı oturum bekliyorum.

ZFS kafa düğümlerinin aynı anda kümem için yansıtılmış bir Postgres veritabanı sunucusu çifti olarak hareket etmesinin akıllıca olup olmadığını merak ediyorum? Görebildiğim tek dezavantajları:

Altyapımı ölçeklemek için daha az esneklik.
Biraz daha düşük yedeklilik seviyesi.
Postgres için sınırlı bellek ve CPU kaynakları.

Ancak, gördüğüm avantaj, ZFS'nin otomatik yük devretme konusunda oldukça aptal olması ve her bir Postgres veritabanı sunucusunu, kafa ile birlikte başarısız olacağından bir kafa düğümünün başarısız olup olmadığını anlamak için çok fazla iş harcamak zorunda değilim düğümü.

— elleciel
kaynak

PostgreSQL olamaz paylaşılan depolama modunun herhangi bir biçimde çalıştırılabilir. Bunu yapma girişimleri başarısız olur. Yapmanızı durdurmak için korumaları atlamaya çalışmak (taşıma / gizleme gibi postmaster.pid) ciddi veri bozulmasına neden olur.

— Craig Ringer

@CraigRinger Hımm, bu kadar çelişkili bir wiki.postgresql.org/wiki/Shared_Storage ?

— elleciel

Veri dizinine aynı anda yalnızca bir posta yöneticisinin erişebileceğini kesinlikle garanti ederseniz çalıştırabilirsiniz. İyi STONITH / eskrim, büyük veri bozulmasını önlemek için mutlak bir gerekliliktir. Şahsen bunu yapmamın bir yolu yok. Bu, konuştuğunuz avantajları da ortadan kaldırır - ana / canlı sunucunun otomatik olarak hangisinin olduğunu vb. - Yük devretmeyi yönetmeniz gerektiğinden.

— Craig Ringer

Daha net yapmak için wiki sayfasını gözden geçirdim; işaret ettiğiniz için teşekkürler.

— Craig Ringer

Bu mantıklı değil. Nexenta'nın HA çözümü RSF-1 kümelemesinden yararlanıyor . Bunu, RSF-1 parçası olmadan Linux'ta ZFS ile yaptığınız anlaşılıyor. Unutmayın, Linux'taki ZFS'nin gerçekten bir kümeleme seçeneği yoktur, bu nedenle Nexenta referansı geçerli değildir. İki kafa düğümü ile ne kazanmanız gerekir?

— ewwhite

Aynı fiziksel dosyalar üzerinde çalışan iki Postgres örneğiniz (Postgres terminolojisinde "kümeler") olamaz.

performans istiyorsanız, parçalama size yardımcı olabilir (her biri farklı veriler taşıyan iki örneğiniz vardır)

Yüksek kullanılabilirlik istiyorsanız, STONITH ile başarısızlık çözüm olabilir. daha sonra donanım onarıldığından emin olmanız gerekir, ikinci düğüm hizmet verirken veritabanını açmayı denemez.

— Jasen
kaynak