MySQL çoğaltma topolojisi yönetim aracı Orkestratörünün ayrıntılı açıklaması - yüksek kullanılabilirlik mekanizması
Genel Bakış
Orchestrator, go dilinde yazılmış açık kaynaklı bir MySQL çoğaltma topolojisi yönetim aracıdır, MySQL ana-bağımlı çoğaltma topolojisinin ayarlanmasını destekler, otomatik MySQL ana veritabanı yük devretmeyi, manuel ana-bağımlı anahtarlamayı ve diğer işlevleri destekler.
Orchestrator arka ucu, meta verileri depolamak için MySQL veya SQLite kullanır.MySQL kümesinin topolojik ilişkisini ve örnek durumunu görüntülemek için bir web arayüzü sağlayabilir.MySQL örneğinin yapılandırma bilgilerinin bir kısmı web arayüzü aracılığıyla değiştirilebilir. Ayrıca daha fazla esneklik için komut satırları ve API arayüzleri sağlar Otomatik operasyon ve bakım yönetimi.
MHA ile karşılaştırıldığında, Orchestrator, herhangi bir MySQL çoğaltma topolojisi ilişkisinin ayarlanmasını gerçekleştirebilen ve bu temelde MySQL yüksek kullanılabilirliğini gerçekleştirebilen çoğaltma topolojisi ilişkisinin yönetimine daha fazla odaklanmıştır. Kendi yüksek kullanılabilirliğini sağlamak için tutarlılık anlaşması.
Bugün esas olarak orachestrator'ın yüksek kullanılabilirlik mekanizmasını tanıtıyoruz.
1. Orchestrator yüksek kullanılabilirliği
Kendi yüksek kullanılabilirliğini elde etmek için sal tutarlılık protokolü aracılığıyla Orchestrator çoklu düğüm dağıtımı.
MHA Manager'ın tek noktasıyla karşılaştırıldığında ORCHESTRATOR, kendi yüksek kullanılabilirlik ve ağ izolasyon sorunlarını, özellikle çapraz veri merkezi ağ anormalliklerini Raft algoritması aracılığıyla çözer. İşte fikir birliği algoritması aracılığıyla Raft'ın açıklaması:
Orkestratör düğümleri, tahkime sahip bir lider seçebilir. 3 ork düğüm varsa, bunlardan biri lider olabilir (3 düğümün tahkim boyutu 2, 5 düğümün tahkim boyutu 3'tür). Yalnızca liderin değişiklik yapmasına izin verilir. Her MySQL topoloji sunucusuna, üç farklı orkestratör düğümü tarafından bağımsız olarak erişilecektir.Normal şartlar altında, üç düğüm aşağı yukarı aynı topoloji haritasını görecek, ancak her biri bağımsız olarak analiz edilecek ve yazılacaktır. Kendi özel arka uç veritabanı sunucusu:
Tüm değişiklikler lideri geçmelidir.
Sal modu etkinleştirildiğinde orkestratör istemcisinin kullanılması yasaktır.
Orkestratör istemciyi sal modunda kullanın, orkestratör istemci orkestratör olmadan sunucuya kurulabilir.
Tek bir orkestratör düğümünün başarısızlığı, orkestratörün kullanılabilirliğini etkilemeyecektir. 3 düğümlü bir kurulumda, en fazla bir sunucu başarısız olabilir. 5 düğümlü bir kurulumda 2 düğüm başarısız olabilir.
Orkestratör düğümü anormal şekilde kapatıldı ve ardından yeniden başlatıldı. Yeterli Raft kaydı olduğu sürece Raft grubuna yeniden katılacak ve kaçırılan tüm olayları alacak.
Günlük tutmanın izin verdiğinden daha uzun / daha fazla bir orkestratör düğümü veya veritabanı tamamen boş olan bir düğüm eklemek için, arka uç DB'nin başka bir etkin düğümden klonlanması gerekir.
İki, yüksek kullanılabilirlik deneyi
Örneğin, aşağıdaki 3 makinede Orchestrator düğümlerini dağıtın:
- 172.26.151.69
- 172.26.151.94
- 172.26.151.95
1. Her düğümdeki orchestrator.conf.json yapılandırma dosyasını değiştirin:
Not: RaftBind şu şekilde yapılandırılmıştır: Geçerli düğüm ip
2. Her düğümde orkestratör hizmetini başlatın:
3. Test ziyareti
Tarayıcıda aşağıdaki şekilde ziyaret edin:
172.26.151.69 düğümünde orkestratör hizmetini kapatın ve lider otomatik olarak 172.26.11.94 veya 172.26.11.95'e geçer. 172.26.151.69 yeniden başlatılır ve kümeye katılırsa, takipçi olarak hareket eder.
Faydalı bulursanız, lütfen iletmeye yardım edin! Daha sonra daha fazla devop ve DBA içeriği paylaşacağım, ilgilenen arkadaşlar takip edebilir
