Aynı fiziksel sunucuda çoğaltma çalıştırmak mantıksız mı?

Veritabanım için bir Master-Slave çoğaltması kurmayı düşünüyorum. Slave sunucu artıklık ve muhtemelen bir rapor sunucusu için kullanılacaktır. Ancak, karşılaştığım en büyük sorunlardan biri, veri merkezimizde zaten azami güce sahip olduğumuz. Yani başka bir fiziksel sunucu eklemek bir seçenek değildir.

Mevcut veritabanı sunucumuz cpu kadar oldukça az kullanılıyor (yük ortalamaları dört çekirdekli üzerinde asla 1'in üzerine çıkmıyor). Öyleyse ana fikir, bazı yeni sürücülerde atmak ve belleği ikiye katlamak (8GB'dan 16'ya) ve aynı fiziksel makinede ikinci bir mysql örneği çalıştırmaktır. Her örnekte veritabanı için ayrı diskler bulunur.

Bu fikirde bir sorun var mı?

Edit (daha fazla bilgi): (Neyse ki) asla sunucu aşağı çekmek için yeterince kötü bir şey oldu, ama önceden planlamak çalışıyorum. Elbette kurtarabileceğimiz gece yedeklerimiz var. Ancak, ana sunucunun sürücüleri başarısız olursa (ayrı ayrı tüm makine sönerse) ayrı disklerde yedek verilere sahip olmanın daha hızlı bir çözüm sağlayacağını düşündüm.

Raporlama yönüne gelince, rapor edeceğimiz tablolar MyIsam'dır. Yani aynı tablolarda pahalı okumalar yapmak sunucu bataklık yapabilirsiniz. Benim varsayım, rapor etmek için bir köle sunucu olması, yeterli RAM attığımız sürece (cpu yükü henüz bir sorun olmadığı için) ana sunucuyu etkilemezdi.

Master ile aynı makinede bir slave çalıştıran sistem güvenilirliği ve veri güvenliği açısından fazlalık için size hiçbir şey (veya yakın) sunmaz. Eğer efendiyi yıkacak kadar kötü bir şey olursa, muhtemelen köleyi de indirecektir.

Erişim hakları nedeniyle kullanıcıları tamamen ayırmak için, iyi bir RDBMS bunu yapmanın daha etkili yollarını sunacaktır.

İki veritabanını aynı makinede çalıştırmak, iki veritabanının çeşitli arabellekleri ve önbelleklerini korumak için alan için rekabet edeceği gibi aynı verimlilikte çalışması için daha fazla RAM gerektirir. Slave için veri dosyaları master'dan farklı fiziksel sürücülerdeyse, IO-yük ayrımı yoluyla bir performans avantajı olabilir. Bu durumda, sürücü IO bant genişliği için master ile rekabet etmeden, slave'e karşı birçok disk okuması gerektiren karmaşık raporlar çalıştırabilirsiniz.

Düzenleme: DTest aşağıdaki yorumunda belirtildiği gibi, bir köle DB (master ile aynı sürücülerde bile) olası bir diğer yararı, köle içinde aksi takdirde gün için kilitleme sorunlarına neden olabilir karmaşık uzun süre çalışan sorguları -master'da günlük çalışan sorgular daha güvenlidir. Yine de, bu tür önemli sorgular G / Ç çekişme sorunlarına neden olacağından, köle farklı sürücülerde sahip olmaktan daha iyidir.

Bunun sorununuzu nasıl çözdüğü açık değil. Aynı fiziksel donanımda, aynı işletim sistemi çekirdeğinde, aynı MySQL ikili dosyalarında, belki farklı disklerde, ancak aynı depolama denetleyicisinde, vb. Olduğu için artıklık yoktur. Ve bir raporlama DB'sinin nedeni OLTP DB'sinden ve hepsi aynı kitte, ekstra güç nereden geliyor? Yoksa bu kurulumdan almaya çalıştığınız başka bir şey var mı?

Bunun akla yatkın bir kullanımı, kullanıcıları bir şekilde ayırmak olabilir, ama yine de, bunun yapılabileceğini düşünürdüm GRANT.

Gerçekten akıllıca düşünülmüyor, sadece daha fazla çekirdekten yararlanmaya mı çalışıyorsunuz? Yeni tasarım düşüncesinin hedefleri nelerdir?

(konuşma dizisi odaklı tutmak için bir yorum değil bir cevap olarak yayınlanmıştır)

Bu iki ucu keskin bir kılıç olabilir

MySQL'in her örneği farklı bir diskte bulunuyorsa, ana sunucu ile aynı sunucuda salt okunur slave'ler olarak birden fazla mysql örneği çalıştırabilirsiniz. Bu, yalnızca MySQL'in birden çok çekirdekten (CPU) faydalanmayan eski sürümlerini çalıştırıyorsanız istenir. MySQL'in en son sürümleri, birden fazla MySQL örneğini çalıştırarak birden fazla çekirdeğe erişmeyi gereksiz kılan Çoklu CPU'ları kullanacak şekilde ayarlanabilir.

Aynı zamanda çok kötü bir fikir. Birçok müşterim bunu çıplak metal veya VM sunucuları satın almaktan tasarruf etmek için yaptı. Sunucu yükündeki herhangi bir artış, herhangi bir MySQL örneğindeki hatalı sorgular, yavaş sorgular, çok fazla bağlantı, bol bellek kullanımı, yetersiz sunucu belleği, önbellek atma vb. Nedeniyle çalışan tüm MySQL örneklerini etkileyebilir. Bu aynı zamanda farklı MySQL örneklerine port numaraları aracılığıyla erişmek zorunda kalarak uygulama karmaşıklığını da artırır ve TCP / IP'nin insafına kalırsınız.

Ben farklı bir sunucuda çoğaltma çapraz yani A A köle B ve B köle A. Çalışan bir sunucuya başarısız olmak, bir yedeklemeden geri yükleme yapmaktan çok daha hızlıdır.