MySQL Docker'da çalışabilir mi?
Önsöz
Geçtiğimiz birkaç ay içinde, MySQL'in Docker'da çalıştırılıp çalıştırılamayacağına dair sık sık çeşitli tartışmalar gördüm. Bu yanlış! Bu doğru! Yanlış ifadenin birçok nedeni vardır ve doğru fikir açıktır. Herkes mantıklı. Ama şahsen böyle bir tartışmanın çok az önemi olduğunu hissediyorum. Çünkü doğru ve yanlışın hala uygulanması gerekiyor.
Bu nedenle Tongcheng Travel, MySQLin Dockerization uygulamasını çok erken başlattı. Şimdiye kadar Docker platformunda 1.000'den fazla MySQL örneği güvenli ve istikrarlı bir şekilde çalışıyor. DB'nin çalışma ve bakım yetenekleri niteliksel olarak iyileştirildi (DBA artık endişelenmenize gerek yok Kitaplığı silin ve uzaklaşın).
Elbette bu, önceki tartışmanın sonucunun doğru olduğunu kanıtlayabilir mi? Öyle düşünmüyorum, çünkü uçmayı öğrenen küçük bir kuşuz ve daha fazlasını öğrenmemiz gerekiyor, bu yüzden MySQL'in Dockerizasyonu konusundaki pratiğimizi herkesle paylaşacağız.
Arka plan tanıtımı
Tongcheng Travel'ın ilk günlerinde, veritabanı esas olarak MSSQL'e dayanıyordu.Bu ürünün bir özelliği, UI işleminin harika olmasıdır. Ancak toplu ve otomatik yönetim yapmak zordur ve çok sayıda insan işi vardır. Daha sonra kademeli olarak MySQL ile değiştirildi ve geleneksel işletim ve bakım yöntemine göre yönetildi. İşin çoğu insan operasyonu ve bakımı gerektirir.
Elbette, ilk günlerde kullandığımız MSSQL'in de avantajları vardır: yani, tek bir makinenin performansı daha iyidir.Kaynakların yetersiz olduğu çağda, yüksek oranda erişilebilir örnekler üzerinde genellikle birden çok kitaplık çalıştırabiliriz. Bu durumda, fiziksel makinelerin sayısı ve örneklerin sayısı hala nispeten kontrol edilebilir ve göreceli sayı nispeten küçüktür, bu nedenle insan operasyonu ve bakımı bunu tamamen halledebilir.
Bununla birlikte, MSSQL'in birçok dezavantajı vardır, örneğin, yatay olarak bölünmesi zordur, bu da veritabanının sistemde daha büyük bir darboğaz haline gelmesine neden olur. Ancak MySQL + ara yazılımını kullandıktan sonra (bu ara yazılımı yapmak için çok düşündük, daha sonra paylaşabiliriz) yatay bölmeden sonra bu darboğazı çözmeye başladık.
Yatay bölünmenin getirilmesi aynı zamanda küçük bir dezavantaj getirir, yani veritabanı örneklerinin sayısında önemli bir artışa neden olur. Örneğin, 1024 parça yaparsak, genellikle 32 düğüm yaparız. Bir ana ve bir bağımlı (çoğu durumda, bir ana ve iki yardımcı), ardından en az 64 örnek, ayrıca acil durum genişletme ve yedekleme için düğümler gerekir Bu daha fazlası (ara yazılım geliştiricileri, 1024 parçanın 1024 örnek olduğunu umuyor).
İki DBA'nın çevrimiçi olduktan sonra 32 düğümlü bir parçalama uzantı bağımlı kitaplığı oluşturması 4 saat sürdü. Ayrıca, tek makineli tek bir örnek yaparsanız, kesinlikle işe yaramayacak, bahsetmeye gerek yok, maliyet büyük bir sorun olacak ve fiziksel makinenin kaynakları maksimumda kullanılamayacak. Dahası, MySQL'in performans avantajı olmadığı için, çoğunlukla parçalanmıştır.Çoğu durumda, her kitaplık tüm fiziksel makineyi çalıştıramaz. Tüm makinenin kaynakları ile dolu olarak çalışabilen bazı kitaplıklar olsa bile, çok düğümlü yedeklemesi, ortamın tekdüzeliği ve tek tip işletim ve bakım eylemleri DBA'yı bir karmaşa haline getirecektir.Yoğun ve hataya açık çalışma aslında anlamsızdır.
Birden çok örneğe sahip tek bir makinede MySQL örneklerini çalıştırmaya ihtiyaç vardır. Tek makineli çoklu örnek için dikkate alınması gereken ana sorun, kaynak izolasyonu ve kısıtlaması için birçok uygulama şeması varsa, nasıl seçilir? KVM, Docker ve Cgroups, izolasyona ulaşabilen mevcut genel çözümlerdir.
KVM, bir DB'nin yalıtımı için çok ağırdır ve performans etkisi çok büyüktür ve bir üretim ortamında kullanım için uygun değildir. Bunun nedeni, MySQL'in bir süreç çalıştırması ve yüksek IO gereksinimlerine sahip olmasıdır, bu nedenle KVM gereksinimleri karşılamaz (ancak IO, optimizasyondan sonra biraz iyileştirilebilir).
Cgroups nispeten hafiftir.Izolasyon çok yüksek olmasa da, MySQL çoklu örnek izolasyonumuz için tamamen yeterlidir (Docker'ın kaynak limiti cgrupları kullanır). Ancak her MySQL örneği için ek yönetim süreçleri (izleme vb.) Çalıştırmak istiyoruz. Cgrup'larla uygulamak daha karmaşık olacak ve ayrıca örnek yönetimini fiziksel makinelerden ayırmak istiyoruz, bu nedenle cgroup'lar da vazgeçiyor.
Docker'a gelince, oldukça iyi ve cgroup'ları çıplak kullanmanın tüm sorunları çözüldü. Ve destek sağlayacak API'ler var ve geliştirme maliyeti düşük. Ve Docker görüntüsüne dayalı dağıtım otomasyonu yapabiliriz, böylece ortamın tekdüzeliği de kolayca çözülebilir. Bu yüzden sonunda bulut platformu için kaynak izolasyon çözümü olarak Docker'ı seçtik (tabii ki bu süreçte çok fazla performans ve kararlılık uyarlama çalışması da yapıldı, bu yüzden burada ayrıntılara girmeyeceğim).
Aşağıdaki iki resim, bu ürünün devrim niteliğindeki önemini canlı bir şekilde gösterebilir:
Elbette ona bulut diyebilmek için platformun en temel gereksinimi kaynak hesaplama ve kaynak planlama fonksiyonlarına sahip olmaktır ve kaynak tahsisi manuel katılım gerektirmez. Kullanıcılar için, elde ettikleri doğrudan erişilebilir kaynaklar olmalıdır ve yüksek kullanılabilirlik, otomatik yedekleme, izleme alarmları, yavaş günlük analizi ve diğer işlevlerle, kullanıcının kaynakların ardındaki şeylerle ilgilenmesine gerek kalmadan doğarlar. Sonraki, çeşitli günlük DBA çalıştırma ve bakım gereksinimlerinin hizmet odaklı çıktılarıdır. Platformumuzun nasıl uygulandığından adım adım bahsedelim.
Platform gerçekleştirme süreci
Devlerin omuzlarında duruyorum
Her zaman bir veritabanının artılarını ve eksilerini değerlendirmek için veritabanının kendisini değerlendiremeyeceğinizi düşünüyorum. Çevresindeki ekolojinin sağlam olup olmadığını entegre etmemiz gerekiyor, örneğin: yüksek kullanılabilirlik çözümleri, yedekleme çözümleri, günlük bakımda zorluk, yetenek rezervleri vb. Elbette aynı şey bir bulut platformu için de geçerli, bu nedenle kısa ve hızlı deneme yanılma çalışmaları yürüttük ve platformu çeşitli sürüm geliştirme aşamalarına ayırdık. İlk sürümün geliştirme döngüsü nispeten kısadır ve esas olarak test için kullanılır, bu nedenle, ihtiyaçlarımıza ulaşmak için veya mevcut açık kaynaklı ürünlerin ikincil geliştirilmesinden sonra özelleştirilmiş ihtiyaçlara ulaşmak için mevcut açık kaynaklı ürünleri mümkün olduğunca kullanmalıyız. Aşağıdakiler, o sırada kullandığımız açık kaynaklı ürünlerden ve teknolojilerden bazılarıdır.
İşte bununla elde ettiğimiz işlevlerden kısaca bahsetmek için birkaç ürün:
Percona: Yedeklememiz, yavaş günlük analizi, aşırı yük koruması ve diğer işlevlerimizin tümü, pt araçları araç setine dayanmaktadır.
Prometheus: Tüm platform örneğini izlemek ve uyarmak için kullanılan, üstün performans ve güçlü işlevlere sahip TSDB. Dezavantajı, küme işlevinin olmaması ve tek bir makinenin performansının bir darboğaz olmasıdır (tek bir makinenin işlem kapasitesi zaten çok güçlü olsa da), bu nedenle dağıtılmış depolama ve genişletme elde etmek için DB'yi iş düzeyinde böleriz.
Consul: İzleme düğümü kaydını gerçekleştirmek için prometheus ile dağıtılmış hizmet keşif ve konfigürasyon paylaşım yazılımı.
Python: Docker konteynerindeki MySQL örneğini ve bazı işlem betiklerini yöneten aracı.
Docker: MySQL örneklerini barındırın ve kaynak izolasyonu ve kaynak kısıtlamalarını uygulayın.
Genel mimari
Bir konteyner planlama sistemi nasıl seçilir
Konteyner planlaması için ana açık kaynaklı ürünler Kubernetes ve mesos'tur, ancak biz bu ikisini seçmedik. Bunun ana nedeni, dahili olarak 2 yıldan uzun süredir istikrarlı bir şekilde çalışan Docker tabanlı bir kaynak yönetimi ve zamanlama sistemi geliştirmiş olmamızdır. Bu mimaride küçük bir değişiklik, gereksinimleri karşılar.
Ek olarak, üçüncü taraf kaynak planlama sistemi mevcut yüksek kullanılabilirlik mimarimizle uyumludur, diğer otomatik yönetim biraz zordur ve kaynak tahsis stratejilerinin özelleştirilmesi gerekir. Sonuçta, kendi geliştirdiğim kaynak planlama yönetimini benimsemeyi seçtim. Kişinin mevcut durumuna uyan ihtiyaçlar daha iyidir. Elbette, daha sonra bilgi işlem planlamasını ve depolama planlamasını ayırma fırsatımız olduğunda Kubernetes çözümüne geçebiliriz.
çalışma prensibi
Bir küme oluşturma örneğini ele alalım. Platform, bir küme oluşturmak için bir görev başlattığında, önce küme boyutuna göre (bir-ana-bir-bağımlı veya bir-ana-çok-bağımlı veya parçalanmış küme) oluşturulacak örnek sayısını belirleyecek ve ardından kaynak filtreleme kurallarımıza göre bu gereksinime göre ( Örneğin, ana ve bağımlı aynı makinede olamaz, bellek yapılandırmasının aşırı satılmasına izin verilmez, vb.), Mevcut kaynak havuzundaki mevcut kaynakları eşleştiremez ve ardından ana-bağımlı ilişkisi oluşturabilir, yüksek kullanılabilirlik yönetimi oluşturamaz, küme çoğaltma durumunu kontrol edemez ve kümeyi itemez. Bilgi ara yazılım (ara yazılım seçildiğinde) kontrol merkezine gönderilir ve son olarak yukarıdaki ilgili bilgiler CMDB ile senkronize edilir.
Yukarıdaki görevlerin her biri, sunucu aracılığıyla aracıya bir mesaj göndermektir ve ardından aracı, karşılık gelen komut dosyasını yürütür.Betik, yürütme sonucunu belirtilen biçimde döndürür. Bu komut dosyaları DBA tarafından geliştirilmiştir. Bu yöntemin avantajı, DBA'nın veritabanını herkesten daha iyi tanımasıdır, bu nedenle bu yöntem proje geliştirme verimliliğini etkili bir şekilde artırabilir ve ayrıca DBA'nın projeye katılmasına izin verebilir. Geliştirmenin yalnızca ön uç mantığını yazması gerekir ve DBA, arka uç tarafından yürütülen belirli talimatlardan sorumludur. Gelecekteki işlevlerde değişiklikler veya yinelemeler varsa, yalnızca yinelemeli komut dosyalarına ihtiyaç vardır ve bakım miktarı minimumdur.
Kaynak planlama ve tahsis ilkeleri
Tongcheng'in yıllarca süren DB işletim ve bakım veri analizinden sonra aşağıdaki deneyim elde edildi:
CPU 3 kat fazla satılır ve bellek aşırı satılmaz;
Aynı makine odası tercihen en az kaynakla makineyi seçer;
Master ve slave rollerine aynı makinede izin verilmez;
VIP gereksinimi varsa, ana ve yardımcı bağlantı noktalarının tutarlı olması gerekir ve bağlantı noktası tutarlılığı kısıtlaması olmadan ara yazılıma doğrudan bağlanmak için VIP gereksinimi yoktur;
Parçalanmış bir küme, düğümleri birden çok fiziksel makineye dağıtır;
ürün kategorileri
Temel işlevler
Yukarıdakiler başlatılan temel işlevlerden bazılarıdır ve tek tek gösterilmeyecek daha birçok işlev vardır.
Yedekleme ve kurtarma sistemi
Percona-xtrabackup'ı yedekleme aracı olarak kullanıyoruz. Veriler, akış yedekleme yoluyla bir uzak yedekleme sunucusuna yedeklenir. Kendi bilgisayar odalarına göre bölünmüş birden fazla yedekleme sunucusu vardır.
Farklı senaryoların ihtiyaçlarını karşılamak için manuel yedekleme ve planlı yedekleme sağlıyoruz. Çok örnekli yedeklemenin disk G / Ç'sine ve ağa dikkat etmesi gerekir, bu nedenle yedekleme stratejimiz tek bir fiziksel makinedeki paralel yedekleme sayısını sınırlayacaktır.Ayrıca, tek bir bilgisayar odasının yedekleme görevi sırasının paralelliği de paralel yedekleme görevlerinin her zaman belirttiğimiz sayıda tutulduğundan emin olmak için kontrol edilir.
Tüm bilgisayar odasında paralel olarak 50 görev varsa, 50 görevden 5'i önceden yedeklenirse, yedeklenmeyi bekleyen 5 yeni görev yedekleme kuyruğuna eklenecektir. Daha sonra yedeklemelerin depolama yöntemini dönüştürdük ve yedeklemeleri doğrudan dağıtılmış depolamaya aktartık.
Alarm sistemini izleme
Bu bulut platformunu başlatmadan önce, hala geleneksel zabbix'i izlemek ve uyarmak için kullanıyorduk. Zabbix'in işlevi gerçekten çok güçlüdür, ancak arka uç veritabanı, veritabanını bölerek elbette çözülebilecek bir darboğazdır.
Veritabanı tarafından izlenecek daha fazla gösterge var.Toplanacak daha fazla öğe varsa, zabbix'in proxy eklemesi gerekiyor.Mimari gittikçe daha karmaşık hale geliyor.Ayrıca, platformumuza yerleştirme maliyeti nispeten yüksek.Bazı karmaşık istatistiksel sorgular için (95 değer, Tahmin değeri, vb.) Performans görece zayıf.
Bu nedenle, son derece güçlü performansa sahip bir zaman serisi veritabanı olan ve izleme sistemleri için son derece uygun olan bir TSDB-prometheus'u seçtik. Prometheus'un avantajı, süper güçlü bağımsız performansıdır. Ancak her şeyin iki tarafı vardır: Dezavantajı, küme mimarisini desteklememesidir (ancak aşağıda tartışılacak olan genişleme sorununu çözdük).
Prometheus kullanımı bir yıl önce başlamalıydı, o zamanlar onu sadece yardımcı bir izleme sistemi olarak kullandık ve alıştıkça konteyner izleme için mükemmel bir çözüm olduğunu hissettik. Bu yüzden bulut platformuna gittiğimde, tüm platform için izleme sistemi olarak seçtim.
Veri toplamayı izleme
Prometheus, pushgateway'i ve çekmeyi desteklemenin bir yoludur. Çekme yöntemini seçtik. Basit yapısı ve düşük geliştirme maliyeti nedeniyle, sistemimize mükemmel bir şekilde bağlanabilir. Konsolos kümesi, MySQL örnek ana-köle, Linux ana-köle hizmeti ve kapsayıcı kayıt hizmetine karşılık gelen hizmetler gibi örnek bilgilerinin ve hizmet bilgilerinin kaydedilmesinden sorumludur. Prometheus daha sonra konsülde kayıtlı bilgiler aracılığıyla izleme hedefini elde eder ve ardından izleme verilerini çeker. İzleme istemcisi bir aracı şeklinde mevcuttur Prometheus, aracı tarafından toplanan verileri HTTP protokolü aracılığıyla alır.
İzleme göstergesi çizimi
Grafana'nın izleme ve çizim dünyasının kolu olduğunu söylemeliyim.Tam özellikli bir ölçüm panosu ve bir grafik editörü var.Basit konfigürasyondan sonra çeşitli izleme grafiklerinin görüntülenmesini tamamlayabilir. Ardından bulut platformu ile grafana arasındaki ilişkiyi açtık.Kullanıcıların bulut platformundaki örnek veya küme bilgilerini görüntülemesi gerekiyor, sadece düğmeye tıklayın.
Alarm yönetimi
Alarm yönetimi ikiye ayrılır: alarm gönderme, alarm alıcı yönetimi, alarm susturma ve diğer fonksiyonlar. Prometheus bir uyarı gönderme modülü uyarı yöneticisine sahiptir Uyarı yöneticisinin bir web kancası aracılığıyla bulut platformunun uyarı API'sine uyarı bilgilerini göndermesine ve ardından uyarı içeriğini aşağıdaki mantığa göre bulut platformuna göndermesine izin veriyoruz.
Warningmanager'ın ittiği şey yalnızca örnek enleminin alarmıdır, bu nedenle alarm içeriğinin çok boyutlu bir bilgisini hecelemek için alarm platformunun örneğe ilişkin bilgilerini birleştiririz. DBA'ya, hangi kümenin hangi seviyeyi, hangi alarmı ne zaman tetiklediğini bir bakışta bildirin. Alarm geri yüklendikten sonra tekrar bir kurtarma bildirimi gönderilecektir.
Alertmanager ayrıca alarm bastırmayı, alarm yönlendirme stratejisini, gönderme döngüsünü, sessiz alarmı vb. Destekleyen güçlü bir araçtır. Gerekirse yapılandırabilirsiniz. Ancak platformdan ayrılan bu yönetim yöntemi istediğimiz şey değil, bu yüzden alertmanager'ın uyarı bilgisi işleme fonksiyonlarının bu kısmını bulut platformuna entegre etmek istiyoruz.
Ancak, resmi belge alertmanager'ın API'sinden bahsetmiyordu.Kaynak kodunun analizi sonucunda, uyarı yönetimi ile ilgili API'ler bulduk. Ardından, alertmanager'ın yerel kullanıcı arayüzünde çalıştırılan işlevler mükemmel bir şekilde bulut platformumuza aktarılır ve kümenin adı ve örnekten sorumlu kişi gibi daha fazla enlem bilgisi eklenir.
İşte bazı örnek işlemler:
Mevcut alarm:
Alarm susturma ekleyin:
Sessiz kurallar oluşturuldu:
Yavaş günlük analiz sistemi
Yavaş günlüklerin toplanması, pt-query-Digest aracılığıyla her saat yerel analiz ile yapılır.Analiz tamamlandıktan sonra, sonuçlar yavaş günlüklerin depolandığı veritabanına yazılır. Elbette, kullanıcının mevcut yavaş günlüğü hemen kontrol etmesi gerekiyorsa, arayüzdeki yavaş günlük analizine de tıklayabilir. Analiz tamamlandıktan sonra, örneğin yavaş günlük analizi sonucunu görmek için UI arayüzündeki yavaş günlük görünümünü tıklayabilirsiniz. Tablo durumunu açıklama ve görüntüleme gibi işlevleri de entegre eder.
Küme yönetimi
Platformun temel işlevlerinden biri olan küme yönetimi, tüm platformun çalışmasının% 70'ini kaplar. Bu işlevler genellikle DBA işletiminde ve bakımında kullanılır. Tasarım fikrimiz kümeye dayalıdır, bu nedenle aynı anda kümenin yalnızca bir örneği üzerinde çalışabiliriz. Bu şekilde bir sayfada çok fazla gereksiz bilgi görüntülenmeyecektir ve dağınık görünüyorsa yanlış çalışmaya neden olabilir. Aşağıdaki şekildeki işlevlere bakarak neden bu şekilde tasarlandığını daha iyi anlayabilirsiniz.
Şekil sadece bir parçadır ve bazı gösterilmeyen işlevler (entegre ara katman yazılımı, Gösterge Tablosu, siyah ekran tanı penceresi, vb.) Vardır ve sonraki sürümlerde daha fazla işlev mevcut olacaktır.
Yüksek kullanılabilirlik
Yüksek kullanılabilirlik çözümü En popüler MySQL yüksek kullanılabilirlik çözümü MHA'yı kullanıyoruz. MHA'nın avantajları ve dezavantajları burada tartışılmayacaktır, DBA'ya sahip olanlar buna aşina olmalıdır. Burada Tongcheng'in işine göre yaptığımız ayarlamalar hakkında konuşacağım.
GTID
Çoğunlukla MariaDB kullanıyoruz, ancak MHA sürümü MariaDB'nin GTID anahtarını destekleyemiyor. Bu yüzden orijinal bazda iyileştirmeler yaptık ve MariaDB'nin GTID'sini destekledik. GTID'yi kullandıktan sonra esnek anahtarlama bir yöndür. Diğer bir yön ise sync_master_info ve sync_relay_log_info'nun 1'e ayarlanmasının gerekmemesidir (MariaDB, tablo yazmayı desteklemez, yalnızca dosyaları desteklemez), bu da kitaplık çoğaltmanın neden olduğu IOPS'yi büyük ölçüde azaltır.
Geçiş yaparken ilgili parametreleri ayarlayın
Geçiş yaparken sync_binlog ve innodb_flush_log_at_trx_commit parametrelerini ayarlıyoruz. Bu iki parametre veri yerleştirme yöntemini belirler. Varsayılan olarak herkes çift 1 ayarlar. Bu en güvenli göreceli verilerdir, ancak IO da daha yüksektir.
Bulut hizmetlerinin çok eşgörünümlü dağıtımı, fiziksel bir makinede hem ana hem de bağımlı ile sonuçlanacaktır. Aynı makinenin diğer slave'lerini etkilemeyecek kadar yüksek IO üretmesini kesinlikle istemiyoruz (IO izole edilebilmesine rağmen, gereksiz IO'yu azaltmaya öncelik vermek güvenilirdir). Teorik olarak konuşursak, çift 1 efendide ayarlanır, ancak köle başka türlü ayarlanabilir. Ancak orijinal merhem, geçişten sonra ustalaşabilir. Bu nedenle, varsayılan bağımlı birimimiz ikili 1 değildir ve yeni ana birimin bu iki parametresi, MHA değiştirildiğinde otomatik olarak 1'e ayarlanacaktır.
nöbetçi
Nöbetçi hizmetlerini birden çok noktada konuşlandırdık. Bu sentinel, basit bir API hizmetidir ve belirtilen örnek, yanıt parametreleriyle istenebilir. MHA yöneticisi, bir Master'ın bağlanamayacağını tespit ettiğinde, ikincil kontrol mekanizmasını tetikleyerek, sentinel düğümün API'sini master ile ilgili bilgilerle talep eder ve sentinel düğümün dönüş durumuna göre yarısından fazlası bağlanamazsa, değişecektir. Aksi takdirde, geçişten vazgeçin.
Yüksek kullanılabilirliğe sahip anahtarlama ve yerleştirme veritabanı ara yazılımı
DB ara yazılımı ve DB fiziksel IP üzerinden bağlanır. Bir yüksek kullanılabilirlik anahtarı oluştuğunda, Ana IP ve Ana bağlantı noktası bilgileri DB ara yazılım kontrol merkezine gönderilir ve DB ara yazılımı, yapılandırmayı aldıktan sonra hemen teslim eder ve yürürlüğe girer.
Örnek, kitaplık geçişi
Geçiş işlevinin asıl amacı, platform dışındaki örnekleri veya kitaplıkları platforma taşımaktı Daha sonra, kademeli kullanımla, bu işlevin, platformdaki kitaplık tablolarını bölme ihtiyacı gibi çok fazla alanda kullanılabileceği bulundu. Gerçekleştirme ilkesi de çok basittir. Mydumper ile belirtilen verileri yedekledikten sonra, belirtilen veritabanına geri yüklemek için myloader'ı kullanın.
Bu tam ölçekli bir süreçtir. Artımlı çoğaltma, kendi geliştirdiğimiz paralel çoğaltmayı destekleyen bir araç kullanır. Bu araç aynı zamanda idempotent işlemeyi destekler ve kullanımı daha esnektir. Yerel çoğaltmanın kullanılmamasının nedeni, kaynak örneğin birden çok kitaplığından biri hedef örneğe taşınacaksa, yerel çoğaltmanın binlog üzerinde yapılandırma değişikliği ve örnek yeniden başlatmayı içeren çoğaltma filtrelemesi gerçekleştirmesi gerektiğidir, bu nedenle kesin olarak yok sayılır .
Gerçekleşme süreci yüksek olmamakla birlikte ihtiyaçları tam olarak karşılar. Elbette, mydumper ve myloader'da da küçük değişiklikler yaptıktan sonra fark ettiğimiz bazı sorunlar var. Gelecekte, verileri dışa ve içe aktarmak için akışı kullanmayı planlıyoruz (Ali açık kaynaklı datax'e benzer).
Geçiş tamamlandığında ve artışta herhangi bir gecikme olmadığında, geçişten önce ve sonra herkes veri tutarlılığı konusunda endişelenecektir. Kendi geliştirdiğimiz bir veri doğrulama aracı sağlıyoruz. 300G'nin gerçek veri doğrulama süresi yaklaşık 2 ila 3 dakikadır ve hız, kaç iş parçacığının açıldığına bağlıdır.
Temel fiziksel kaynakları koruyun
Kullanıcılar için, platform bir veya bir grup veritabanı hizmeti sağlar ve arka uç örneğinin hangi makinede olduğu ile ilgili olması gerekmez. Kaynak hesaplama ve zamanlama, sistem algoritmaları tarafından yönetilir.
Kaynak kullanımını iyileştirin (CPU, bellek)
Tek bir makinenin birden çok örneği aracılığıyla, CPU kaynakları aşırı satılabilir ve CPU kaynaklarının kullanımını etkin bir şekilde artırır. Bellek kaynakları aşırı satılmaz, ancak her örneğin bellek kullanımı, her bir örneğin yeterli belleğe sahip olduğundan emin olmak için kontrol edilebilir. Kalan bellek varsa, kabı ayırmaya devam edin ve bellek kaynaklarını OOM olmadan sıkıştırın.
İşletme ve bakım verimliliğini artırın
Verimlilikteki artış, standardizasyonun getirdiği otomasyondan kaynaklanmaktadır. Toplu işlem ve bakım maliyeti çok düşüktür. Eskiden bir dizi parçalanmış kümeyi dağıtmak yaklaşık 6 saat sürüyordu (ara katman yazılımını bağlamak için 1 ila 2 saat hariç), ancak şimdi dağıtımı tamamlamak yalnızca 5 dakika sürüyor. Ve dağıtım tamamlandıktan sonra, bir dizi ara katman yazılımı + DB parça küme hizmetleri sağlanacaktır.
İyi yönetim
Platform çevrimiçi olduktan sonra, kaynak kullanımı etkili bir şekilde geliştirildi.Aynı zamanda, farklı kütüphanelerin eşit olmayan baskısının neden olduğu karşılıklı etki sorununu etkili bir şekilde önleyebilen 1 kütüphane 1 örnek yöntemini takip ettik. Ve performans izleme, kütüphane düzeyinde de doğru olabilir.
Sonuç
Yukarıdakiler sadece bir başlangıçtır ve hala geliştirilecek birçok işlev vardır.Aşağıdakiler, yakın gelecekte planlanan ve bazıları daha sonraki sürümlerde geliştirilmiş olan işlevlerden bazılarıdır. İşlevlerin sürekli yinelenmesiyle daha mükemmel bir özel bulut platformu oluşturacağız.
Veritabanı özel bulut platformunun piyasaya sürülmesi, Tongcheng DB için bir dönemin sonu ve bir dönemin başlangıcı anlamına geliyor. Son, geleneksel işletme ve bakımın düşük verimli ve yüksek maliyetli işletim ve bakım dönemidir ve düşük maliyetli, yüksek verimli ve yüksek garantili işletme ve bakım dönemi başlamıştır. Geleceğin daha iyi olacağına inanıyoruz!
