Yük dengeleyici olmadan yük dengeli MySQL kümesi


10

Yük dengeli bir MySQL kümesi oluşturmak istiyorum, ancak gerçek yük dengeleyici olmadan, başka bir hata veya karmaşıklık noktası eklemek için değil.

Düşündüğüm, aşağıdakilere sahip olmaktı:

  1. MySQL için bir master-master kurulumunuz olsun

  2. Her istemcide, istekleri sunucular arasında döndürecek basit bir yuvarlak geçişli proxy yerleştirin.

Mümkün mü? Yoksa bunu başarmanın daha iyi yolları var mı?

mysql 

Merak ediyorum, ne için kullanacaksın?

Yük dengeleyicileri ve benzerlerini içermeden çözümümüze HA eklemeye çalışıyorum.

Yanıtlar:


3

Lütfen herhangi bir tür MySQL proxy kullanmadan önce bu soruya verilen diğer cevabımı okuyun Bir CMS'nin yazdığı 2 master-master sunucunuz ve yalnızca ondan okunan 10 httpd'niz varsa, iyi olacaksınız, ancak (diğer cevapta belirtildiği gibi) her zaman böyle değildir. Uyarılmıştın.

MySQL Proxy , istemciniz ile iletişimlerini izleyebilen, analiz edebilen veya dönüştürebilen MySQL sunucu (lar) ı arasında yer alan basit bir programdır. Esnekliği sınırsız kullanım sağlar; yaygın olanları şunlardır: yük dengeleme; başarısızlık; sorgu analizi; sorgu filtreleme ve değiştirme; ve daha fazlası.

.

HAProxy , TCP ve HTTP tabanlı uygulamalar için yüksek kullanılabilirlik, yük dengeleme ve proxy sağlama sunan ücretsiz, çok hızlı ve güvenilir bir çözümdür

TCP modunda çalıştırırsanız, Wackamole'den bile daha iyi olabilir. Aralarında seçim yapsaydım, HAProxy kullanırdım. Ayrıca HAProxy çok fazla arka uca sahip olabilir, Waclamole sadece 2 olabilir. .


Sadece doğrulamak için: 1) HAProxy, HA için ek makine / 2 makine gerektirir 2) Wackamole kurulum başına sadece 2 sunucuyu destekleyebilir mi? Saygılarımızla.

Wackamole'un standart kullanım şekli (aslında bildiğim tek şey) serverA ve serverB'nin birbirini izlemesini ve ölürse diğerinin IP'sini almasını sağlamaktır. Wackamole web sitesi bir IP havuzunu korumak için kullanılabileceğini söylüyor ... Ama Wackamole'un istediği gibi stabilite sağlamadığını söylemeliyim, bu yüzden bunu tavsiye etmiyorum. HAProxy hakkında, bunlardan 2 tanesini yedeklilik için 2 özel makineye koyacaksınız, ya da soruda söylediğin gibi, her bir düğüme bir tane bile koyabilirsiniz. Sorgularınız çoğunlukla okuyorsa, bence oldukça işe yarayacak.

Merhaba Resif. Wackamole hakkında son bir şey - deneyiminizden, iki makinede yeterince kararlı değil mi?

2 makine birbirinden ping tamam, ama bunlardan biri 200 yük var, hepsi cpu% 100 kullanımda, hepsi koç kullanılmış. MySQL çöktü. <- wackamole orada çalışmaz. HAProxy, uzak APPLICATION uygulamasının açık olup olmadığını, yalnızca sunucu açık olduğunda ve Wackamole ve application_uptime <server_uptime öğelerini kontrol edebilir. Wackamole'e güvendiğimiz ve bizi hayal kırıklığına uğratan birçok vakamız vardı.

4

Muhtemelen bahsetmeye değer, gerçek bir çok ana MySQL kurulumu için MySQL için Galera Replication. Galera senkron bir çoğaltma protokolüdür, böylece uygulamalar MySQL Sunucularından herhangi birini okuyabilir ve bunlara yazabilir. İşte hızlı bir eğitim: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

MySQL Sunucularının önündeki yük dengeleyicilere gelince, ya bu işlevi destekleyen bir MySQL konektörü kullanın (örneğin, Java için Connector / J veya php için Mysqlnd)

Bunu yapabilen bir konektörünüz yoksa, bir HA Proxy gibi bir şey kullanın. Bu komut dosyası otomatik olarak HA Proxy'yi kurar ve iyi MySQL Sunucularının listesini tutar: https://github.com/severalnines/haproxy

Saygılarımla,

Vinay

www.severalnines.com


Önerdiğiniz ürünle olan ilişkinizi çok net bir şekilde açıklamanız önemlidir. Ayrıca, bu site kendi kendini tanıtmak için değildir. Gönderilen bir sorunu çözecek bir ürününüz varsa, harika! Tüm yanıtlarınız ürünleriniz etrafında dönüyorsa, yanıt göndermek yerine reklam alanı edinme konusunda birisiyle konuşmak isteyebilirsiniz. Lütfen sss .
JNK

3

Master-master çoğaltma düşündüğünüz kadar iyi değil, aynı şekilde round-robin proxy'ye ve benzer 'kolay' çözümlere gider. Verileri ayrı sunucularda hızlı bir şekilde (üretim sunucularında tam saniyeye kadar sürebilen sunucular arasındaki gecikmeden daha hızlı) ayırmayı taahhüt ederseniz *, her ikisi de verileri kabul eder. Bir açık artırma sunucunuz varsa, aynı arabayı iki kez sattınız . Kim aldı? Hangi DB'ye soracağınıza bağlıdır!

Uygulama aslında orada 2 veritabanı olduğunu bilmelidir ve her iki ip adreslerini bilmek zorundadır. "Satmak" istiyorsanız, fe gerekir

DB_number = `auction_number` % `number_of_databases`

( %için modulo)

... ve DB_number veritabanına kaydeder. Bir bağlantı hatası alırsanız, belki de diğeriyle yapın (ancak bir açık artırma sunucusunda, sadece bir hata görüntülerim).

Ayrıca, IP adreslerinin her iki sunucu arasında wackamole -d olması gerekir . Bir veritabanı sunucusunun en yüksek kullanım süresinde birkaç saatliğine düştüğü bir felaket senaryosunda, uygulamanın yok sunucuya bağlanmaya çalışacağını ve TIMEOUT, örneğin 3s'ye kadar askıda kalacağını göreceksiniz. Anketlerinizin yarısı aniden 3 sn daha uzun süre çalışır (ve sonuçta hepsi aynı veritabanına gider - bu da felaketten daha hızlı çalışmasını sağlamaz). Bu, muhtemelen eşzamanlı istek işleyici iş parçacıklarının sınırlı bir bağlantı havuzuna sahip olduğundan, httpd'nizi mutlu etmez ...

* üretim sunucularında çoğaltma gecikmesi tam bir saniyeye kadar olabilir - Bunu uzak bir yerde ve veri merkezimizde test ettim ve zamanın yaklaşık% 99'u 0, ancak bazen mysql 1s gösteriyor. Yoğun trafikte, istemci uygulamasının iki sorgulama, ekleme ve seçme ile sonuçlanan iki istekte bulunması nedeniyle birçok çarpışma yaşadım. Bazı durumlarda, satır henüz orada değildi , bu yüzden userID'nin karma değerini kullandık ve sorunu düzelttik

Umarım hatalarımdan öğrenirsin ;-)


Selam. Paylaşım için teşekkürler. Aslında HA için iyi olan Wackamole'u düşündüm. Aktif / aktif ararken temelde aktif / pasif oluşturarak, ikinci yük boşta kaldığında tüm yükün ana sunuculardan birinde olması sorunum. Belki de sunucular arasında istekleri değiştirmesine izin vermek için her istemciye hafif bir LB çözümü yerleştirmek daha iyidir? Böyle bir araç var mı?

Fazlalığa ihtiyacınız varsa, o zaman "bir çalışma, bir boşta" iyidir. Diyelim ki 2 sunucudan biri öldü (Size hatırlatırım, diğerini aldığınız, böylece ilk sunucu bozulursa hala çalışabilirsiniz). İkinci sunucu tüm trafiği işleyemiyorsa, HA için değil, ölçek içindir! Ayrıca: sadece Wackamole güvenmek kötü bir çözümdür (ping tamam! = Mysqld tamam).

3

Yük dengeli bir MySQL (veya başka bir) veritabanı kümesi oldukça işe yaramaz. Birden fazla sunucuya yazıyorsanız, sorun yaşarsınız veya eşzamanlı çoğaltma kullanırsınız (MySQL zaten desteklemez) ve bu da kilitleri senkronize etmesi gerektiği için performansı kötü incitir.

Okuma / yazma yüklerini ayırmanızı ve okumaları mysql slave'leri arasında dengelemenizi ve yazma için tek bir master'a sahip olmanızı veya masterınız için aktif / pasif yük devretme çifti kullanmanızı öneririm.

Aslında, her biri uygulamanızın tüm yazma yükünü yazmak zorunda olduğundan, veritabanına daha fazla sunucuyu köle olarak koyarak yazma ölçeklerini ölçekleyemezsiniz.

Yazmaları ölçeklendirmek için verilerinizi mantıksal olarak birden çok sunucuya, bölümlere ayırmaya veya "parçalara ayırmaya" vb. Bölmeniz gerekir. Bu, uygulamanızda genellikle önemsiz olmayan (test etmek çok zor düşünün) değişiklikler gerektirir; bu nedenle, GERÇEKTEN ona ihtiyacı olmak.


Gerçekten isterseniz MySQL kümesini kullanabilirsiniz, ancak kendi özellikleri ve dezavantajları ile tamamen farklı bir motordur - kurulumu biraz karmaşıktır, ancak emtia donanımında gerçekten HA dengeli bir veritabanı sağlar. Eşzamanlı çoğaltma kullanmaktan hala yazma performansı cezaları çekiyor, ancak sunucular arasında bölümleme oluştururken yazmaları ölçeklendirmenize izin veriyor.


3

Bu konuda bir başka harika rehber buldum ...

http://www.dancryer.com/2010/01/mysql-circular-replication

Bu üç gönderi dizisinin 1. bölümüdür:

  • MySQL Yük Dengeli Küme Kılavuzu - Bölüm 1 - sunucuların kendilerinin ayarlanması ve MySQL çoğaltmasının yapılandırılması.

  • MySQL Yük Dengeli Küme Kılavuzu - Bölüm 2 - MySQL küme düğümlerinizin durumunu izlemek için bir komut dosyası ayarlayın, bu sunucu sonraki proxy'de proxy'imizi ayarlamak için kullanacağız.

  • MySQL Yük Dengeli Küme Kılavuzu - Bölüm 3 - izleme komut dosyalarını kullanarak HAProxy ile yük dengeleyiciyi ayarlama


2

Şahsen, bir yük dengeleyici kullanmak daha iyi bir yol olurdu!

Evet, başka bir arıza noktası ekler, ancak yerine koyduğunuz veya HER istemciye yüklediğiniz herhangi bir rutin, standart bir yük dengeleyiciden çok daha karmaşıklık katar ....


Bu mantıklı, ama sorun tek başarısızlık noktası - 2 LB ile bile ... Müşterilerden birinin düşmesi durumunda, sadece etkilendi ve başka hiç kimse.

Her düğümde LB'yi korumak zordur. 12 sunucuya bir LB yüklerseniz ve sonra bir şeyi değiştirmek isterseniz (DB'lerden birinin adresi veya DB veya benzeri bir şey eklerseniz) - Sorunu fark edeceksiniz. Yaptım.

1

Connector / J, birden fazla sunucuda balans sorguları yükleme yeteneğine sahiptir. Bu öncelikle MySQL NDB Kümesi için tasarlanmıştır, burada tüm SQL düğümleri verilerin tutarlı bir görünümüne sahiptir, ancak iki master veritabanının bu iki master arasında makul bir şekilde tutarlı olmasını sağlayabilirsiniz, uygulamanız için güvenli olabilir.

Bağlantı dizesi şöyle görünecektir:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "rastgele" & loadBalanceBlacklistTimeout = 5000


0

Bölünen yazma işlemleri sunucuların yüklemesini kaldırmaz, çünkü yazma işlemlerinin yine de çoğaltılması gerekir.

Sadece 2 sunucu kullanıyorsanız drbd ile kalp atışı kullanıyorsanız ve drbd çoğaltmayı işleyebilsin İlk sunucu başarısız olursa, ikinci sunucu devralır. İkinci sunucuyu kullanmak istiyorsanız, gfs'yi drbd üzerinden kullanabilir ve ardından ikinci sunucuyu salt okunur olarak çalıştırabilir ve bir okuma sunucusu olarak kullanabilirsiniz. Yük devretme gerçekleştiğinde sunucuyu okuma / yazma olarak değiştirin.

re: wackamole - wackamole 2 sunucu ile sınırlı değildir

Bunu kapsayan bir eğitim serisi üzerinde çalışıyorum, ancak kurulumu gerçekten basit.


Evet, teorik olarak, wackamole 2'den fazla sunucuyu destekleyebilir, ancak bunu üretimde hiç denediniz mi? Yaptık. Şimdi pişmanız.

Şimdiye kadar hiçbir sorunum yoktu, centos 5 64 bit altında derleme alamıyorum dışında

0

Bu soruya daha yeni bir cevap vermek için, MySQL'in 5.6 sürümü ile , eşzamansız çoğaltmayı daha sağlam hale getirmeyi ve MySQL'i tekrar HA (Yüksek Kullanılabilirlik) yarışına sokmayı amaçlayan GTID'yi (Global İşlem Tanımlayıcıları) tanıttı .

Bu bölümde, genel işlem tanımlayıcılarını (GTID'ler) kullanarak işleme dayalı çoğaltma açıklanmaktadır. GTID'leri kullanırken, her işlem kaynak sunucuda işlendiği ve herhangi bir slave tarafından uygulandığı için tanımlanabilir ve izlenebilir; Bu, GTID'leri kullanırken yeni bir slave başlatılırken veya yeni bir master'a geçiş yaparken bu dosyalardaki günlük dosyalarına veya konumlara başvurmak için gerekli olmadığı anlamına gelir, bu da bu görevleri büyük ölçüde basitleştirir. GTID tabanlı çoğaltma tamamen işlem tabanlı olduğundan, master ve slave'lerin tutarlı olup olmadığını belirlemek kolaydır; bir master üzerinde yapılan tüm işlemler bir köleye bağlı olduğu sürece, ikisi arasında tutarlılık garanti edilir. GTID'lerle ifade tabanlı veya satır tabanlı çoğaltmayı kullanabilirsiniz (bkz. Bölüm 16.2.1, “Çoğaltma Biçimleri”); ancak, en iyi sonuçlar için,

Referans: 16.1.3 Global İşlem Tanımlayıcıları ile Çoğaltma (MySQL Belgeleri)

Loadbalance sorguları için HAProxy kullanımının bir SPOF (Tek Nokta Arıza Noktası) tanıttığını ve kalp atışını ekleyerek bu çözümü hantal hale getirdiğini düşündüm.

Daha basit bir çözüm, tüm MySQL düğümleriyle bir jdbc url'si üzerinden denge sorguları yüklemeyi amaçlayan Java konektörü JConnector aracılığıyla bağlanmaktır . Master / slave veya master / master kurulumlarını işleyebilir .

Bu, MySQL ile kutudan bir HA küme çözümü kurmayı mümkün kılar.

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.