Teknologian jakaminen

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Avoimen lähdekoodin ekosysteemi

Kuten me kaikki tiedämme, MySQL-ensisijainen ja toissijainen tietokanta (kaksi solmua) saavuttaa yleensä korkean tiedon saatavuuden asynkronisen replikoinnin ja puolisynkronisen replikoinnin (Semi-Sync) avulla ensisijaiset ja toissijaiset arkkitehtuurit kohtaavat vakavia ongelmia HA-vaihdon jälkeen. On todennäköistä, että tiedot ovat epäjohdonmukaisia ​​(viitataan nimellä RPO! = 0).Siksi niin kauan kuin liiketoimintatiedot ovat tärkeitä, sinun ei pitäisi valita tietokantatuotetta, jossa on ensisijainen ja toissijainen MySQL-arkkitehtuuri (kaksi solmua. On suositeltavaa valita monikopioarkkitehtuuri, jossa RPO=0).

MySQL-yhteisö, koskien monikopiotekniikan kehitystä RPO=0:lla:

• MySQL on virallisesti avoimen lähdekoodin, ja se on julkaissut MySQL Group Replication (MGR) korkean käytettävyyden ratkaisun, joka perustuu ryhmäreplikointiin. Paxos-protokolla on sisäisesti kapseloitu XCOM:n kautta tietojen johdonmukaisuuden varmistamiseksi.
• Ali Cloud PolarDB-X , joka on johdettu Alibaban sähköisen kaupankäynnin Double Elevenin liiketoiminnan hiomisesta ja todentamisesta sekä monitoimista eri paikoissa, se tulee avoimeen lähdekoodiin koko ytimessä lokakuussa 2021, ja se kattaa täysin MySQL avoimen lähdekoodin ekosysteemin. PolarDB-X on keskitetty ja hajautettu integroitu tietokanta. Sen datasolmu Data Node (DN) käyttää itse kehitettyä X-Paxos-protokollaa ja on erittäin yhteensopiva MySQL 5.7/8.0:n kanssa , mutta myös Sillä on erittäin skaalautuva tapahtumamoottori, joustava toiminta ja ylläpito katastrofipalautuksessa sekä edullinen tietojen tallennus.PolarDB-X Open Source |. Kolme kopiota Paxos-pohjaisesta MySQL:stä》。

PolarDB-X Keskitetyn ja hajautetun integraation käsite: tietosolmua DN voidaan käyttää itsenäisesti keskitettynä (vakioversiona) lomakkeena, joka on täysin yhteensopiva erillisen tietokantalomakkeen kanssa. Kun liiketoiminta kasvaa siihen pisteeseen, että tarvitaan hajautettua laajennusta, arkkitehtuuri päivitetään hajautettuun muotoon ja hajautetut komponentit yhdistetään saumattomasti alkuperäisiin tietosolmuihin. Sovelluspuolella ei tarvitse siirtää tietoja tai muokata , ja voit nauttia tämän kaavan tuomasta käytettävyydestä ja skaalautumisesta, arkkitehtuurin kuvaus:"Keskitetty hajautettu integraatio"

Sekä MySQL:n MGR että PolarDB-X:n standardiversio DN käyttävät Paxos-protokollaa alimmasta periaatteesta. Mitkä ovat siis erityiset suorituskyvyt ja erot todellisessa käytössä? Tässä artikkelissa käsitellään arkkitehtuurin vertailun näkökohtia, keskeisiä eroja ja testivertailua.

MGR/DN-lyhenteen kuvaus: MGR edustaa MySQL MGR:n teknistä muotoa ja DN edustaa PolarDB-X yksittäisen DN:n keskitettyä (vakioversio) teknistä muotoa.

TL;DR

Yksityiskohtainen vertaileva analyysi on suhteellisen pitkä, joten voit lukea yhteenvedon ja johtopäätöksen ensin.

MySQL MGR:ää ei suositella yleisille yrityksille ja yrityksille, koska se vaatii ammattimaista teknistä tietämystä sekä käyttö- ja huoltotiimiä. :

• Dark Pit 1: MySQL MGR- ja XCOM-protokollat ​​ottavat käyttöön täyden muistin Näytä ja määritä parametri sen varmistamiseksi. Tällä hetkellä MGR:n suunnittelu ei voi saavuttaa sekä suorituskykyä että RPO:ta.
• Sudenkuoppa 2: MySQL MGR:n suorituskyky on heikko, kun verkkoviive on olemassa. Artikkelissa testattiin 4 minuutin verkkoskenaarioiden vertailua (mukaan lukien kolme tietokonehuonetta samassa kaupungissa ja kolme keskustaa kahdessa paikassa). kaupungin suorituskykyparametrit, se on vain 1/5 samassa kaupungissa, jos RPO=0 on käytössä, suorituskyky on vielä huonompi.Siksi MySQL MGR soveltuu paremmin käytettäväksi samassa tietokonehuoneessa, mutta ei sovellu tietokoneiden väliseen katastrofipalautukseen.
• Sudenkuoppa 3: MySQL MGR:n monikopioarkkitehtuurissa valmiussolmun vika aiheuttaa pääsolmun Leader-liikenteen putoamisen nollaan, mikä ei ole terveen järjen mukaista. Artikkeli keskittyy yrittämään ottaa käyttöön MGR:n yhden johtajan tila (verrattuna MySQL:n aiempaan isäntä-orja-replika-arkkitehtuuriin), simuloimalla orjareplikan kaksi toimintoa seisokkeja ja palautusta node (Leader) ilmestyi Liikenne putosi nollaan (kesto noin 10 sekuntia), ja yleinen käytettävyys ja ylläpidettävyys oli suhteellisen huono.Siksi MySQL MGR:llä on suhteellisen korkeat vaatimukset isäntäkäytölle ja ylläpidolle, ja se vaatii ammattitaitoisen DBA-tiimin.

Verrattuna MySQL MGR:ään, PolarDB-X Paxosissa ei ole MGR:n kaltaisia ​​sudenkuoppia tietojen johdonmukaisuuden, tietokoneiden välisen katastrofipalautuksen sekä solmun toiminnan ja ylläpidon suhteen. Sillä on kuitenkin myös joitain pieniä puutteita ja etuja katastrofipalautuksessa:

• Saman tietokonehuoneen yksinkertaisessa skenaariossa vain luku -suorituskyky alhaisella samanaikaisuudella ja puhdas kirjoitussuorituskyky korkealla samanaikaisuudella ovat noin 5 % alhaisemmat kuin MySQL MGR. Useita kopioita lähetetään samanaikaisesti suorituskyvyssä on tilaa lisäoptimoinnille.
• Edut: 100 % yhteensopiva MySQL 5.7/8.0:n ominaisuuksien kanssa. Samaan aikaan on tehty tehokkaampia optimointeja monikopioisen tietokannan replikointi- ja vikasietopoluissa -Minuutin katastrofipalautusskenaario alalla kaikki toimivat hyvin ja voivat korvata puolisynkronoinnin (puolisynkronoinnin), MGR:n jne.

1. Arkkitehtuurin vertailu

Sanasto

MGR/DN-lyhenteen kuvaus:

1. MGR: MySQL MGR:n tekninen muoto, myöhemmän sisällön lyhenne: MGR
2. DN: Alibaba Cloud PolarDB-X on keskitetty (vakioversio) tekninen lomake. Hajautettua datasolmua voidaan käyttää itsenäisesti (vakioversiona) Se on täysin yhteensopiva erillisten tietokantojen kanssa kuten: DN

MGR

MGR tukee yhden isäntä- ja monen isännän tiloja ja käyttää täysin uudelleen MySQL:n replikointijärjestelmää, mukaan lukien Event, Binlog & Relaylog, Apply, Binlog Apply Recovery ja GTID. Keskeinen ero DN:stä on se, että MGR-tapahtumalokin enemmistö pääsee yhteisymmärrykseen ennen kuin päätietokantatapahtuma on sitoutunut.

• Johtaja:

1. 1. Ennen kuin tapahtuma on sitoutunut, kutsutaan ennen_commit-koukkufunktio group_replication_trans_before_commit syöttämään MGR:n enemmistöreplikaatio.
   2. MGR käyttää Paxos-protokollaa synkronoidakseen THD:llä välimuistissa olevat Binlog-tapahtumat kaikkiin online-solmuihin
   3. Saatuaan enemmistön vastauksen MGR päättää, että tapahtuma voidaan lähettää
   4. THD siirtyy tapahtumaryhmän lähetysprosessiin ja alkaa kirjoittaa paikallista Binlog-päivitystä Toista vastausasiakkaan OK -viesti

• Seuraaja:

1. 1. MGR:n Paxos Engine jatkaa johtajan protokollaviestien kuuntelemista
   2. Täydellisen Paxos-konsensusprosessin jälkeen on vahvistettu, että tämä (erä)tapahtuma on saavuttanut enemmistön klusterissa
   3. Kirjoita vastaanotettu tapahtuma välityslokiin, IO Thread Apply Relay Log
   4. Välityslokisovellus käy läpi täydellisen ryhmälähetysprosessin, ja valmiustilatietokanta luo lopulta oman binlog-tiedostonsa.

Syy siihen, miksi MGR ottaa käyttöön yllä olevan prosessin, johtuu siitä, että MGR on oletuksena monipäätilassa ja jokainen solmu voi kirjoittaa. Siksi yhden Paxos-ryhmän seuraajasolmun on muunnettava vastaanotettu loki ensin RelayLogiksi ja sitten yhdistettävä. sen kirjoitustapahtuman kanssa, jonka se vastaanottaa lähettäjänä, tuotetaan Binlog-tiedosto, joka lähettää lopullisen tapahtuman kaksivaiheisessa ryhmälähetysprosessissa.

DN

DN käyttää uudelleen MySQL:n perustietorakennetta ja toimintotason koodia, mutta integroi lokin replikoinnin, lokien hallinnan, lokien toiston ja kaatumispalautuksen tiiviisti X-Paxos-protokollan kanssa muodostaen oman joukon enemmistöreplikointia ja tilakonemekanismia. Keskeinen ero MGR:stä on se, että DN-tapahtumalokin enemmistö pääsee yhteisymmärrykseen päätietokantatapahtuman lähetysprosessin aikana.

• Johtaja:

1. 1. Siirry tapahtuman ryhmälähetysprosessiin Ryhmälähetyksen tyhjennysvaiheessa kunkin THD:n tapahtumat kirjoitetaan Binlog-tiedostoon, ja sitten loki lähetetään asynkronisesti kaikille seuraajille X-Paxosin kautta.
   2. Ryhmälähetyksen synkronointivaiheessa Binlog säilytetään ensin ja sitten päivitetään X-Paxosin pysyvyyssijainti.
   3. Ryhmälähetyksen Commit-vaiheessa sinun on ensin odotettava, että X-Paxos saa enemmistön vastauksen, lähetettävä sitten tapahtumaryhmä ja lopuksi vastataan asiakkaalta OK-viestillä.

• Seuraaja:

1. 1. X-Paxos jatkaa johtajan protokollaviestien kuuntelemista
   2. Vastaanota (ryhmä)tapahtumat, kirjoita paikalliseen Binlogiin ja vastaa
   3. Vastaanotetaan seuraava viesti, joka kuljettaa sen aseman Commit-indeksin, jossa enemmistö on saavutettu.
   4. SQL-päivityssäie jatkaa vastaanotetun Binlog-lokin käyttöä taustalla ja käyttää sitä enintään vain enemmistön asemaan.

Syynä tähän suunnitteluun on se, että DN tukee tällä hetkellä vain yhden pääkäyttäjän tilaa, joten X-Paxos-protokollan loki on itse Binlog-seuraaja, joka jättää pois myös välityslokin ja sen pysyvän lokin ja johtajan lokin ovat samat kuin Sama hinta.

2. Keskeiset erot

2.1. Paxos-protokollan tehokkuus

MGR

• MGR:n Paxos-protokolla on toteutettu Multi-Paxos-teoriaan kuuluvan Mencius-protokollan pohjalta. Erona on, että Mencius on tehnyt optimointiparannuksia pääsolmun kuormituksen vähentämisessä ja suorituskyvyn lisäämisessä.
• MGR:n Paxos-protokolla on toteutettu XCOM-komponenteilla, ja se tukee usean pääkäyttäjän ja yhden pääkäyttäjän tilan käyttöönottoa tavallinen Multi-Paxos-prosessi.
• Tyydyttääkseen suurimman osan tapahtumasta XCOM:n on käytävä läpi vähintään kolme viestivuorovaikutusta Accept+AckAccept+Learn, eliVähintään 1,5 RTT yläpuolella.Se vaatii enintään kolme viestivuorovaikutusta: Valmistele+AckPrepare+Accept+AckAccept+Learn.Eli yhteensä enintään 2,5 RTT:tä
• Koska Paxos-protokolla valmistuu XCOM-moduulissa suurella koheesiolla, eikä se ole tietoinen MySQL-replikointijärjestelmästä, johtajan on odotettava koko Paxos-prosessin valmistumista ennen kuin se suorittaa tapahtuman paikallisesti, mukaan lukien Binlogin pysyvyys ja ryhmälähetys.
• Kun seuraaja on suorittanut suurimman osan lähetyksestä, se säilyttää tapahtumat asynkronisesti välityslokiin, ja sitten SQL Thread -sovellus ja -ryhmä lähettää tuotantobinlogin.
• Koska Paxosin synkronoima loki on Binlog, jota ei lajiteta ennen ryhmälähetysprosessiin siirtymistä, Binlog-tapahtumien järjestys Leaderissa ei välttämättä ole sama kuin seuraajasolmun välityslokin tapahtumien järjestys.

DN

• DN:n Paxos-protokolla on toteutettu Raft-protokollan pohjalta ja se kuuluu myös Multi-Paoxs-teoriaan.
• DN:n Paxos-protokolla täydentää X-Paoxs-komponenttia. Oletus on yhden pään tilassa, Leaderin Binlog lähettää atomilähetyksen seuraajasolmuun .
• Tyydyttääkseen suurimman osan tapahtumasta X-Paoxsin tarvitsee vain käydä läpi kaksi viestivuorovaikutusta: Append+AckAppend, ja vain1 RTT yleiskustannukset
• Kun Leader on lähettänyt lokin seuraajalle, niin kauan kuin enemmistö on tyytyväinen, se sitoutuu tapahtumaan odottamatta Commit Index -lähetystä toisessa vaiheessa.
• Ennen kuin seuraaja voi suorittaa enemmistön lähettämisen, kaikki tapahtumalokit on säilytettävä. Tämä eroaa merkittävästi MGR:n XCOM-muistista.
• Commit-indeksi tuodaan esiin myöhemmissä viesteissä ja sykeviesteissä, ja seuraaja suorittaa Apply-tapahtuman sen jälkeen, kun CommitIndex on nostettu ylös.
• Leaderin ja Followerin Binlog-sisällöt ovat samassa järjestyksessä, Raft-lokeissa ei ole reikiä, ja Batching/Pipeline-mekanismia käytetään lisäämään lokin replikoinnin suorituskykyä.
• MGR:ään verrattuna Leaderilla on aina vain yksi edestakainen viive, kun tapahtuma on sitoutunut., erittäin kriittinen viiveherkille hajautetuille sovelluksille

2.2. RPO

Teoriassa sekä Paxos että Raft voivat varmistaa tietojen johdonmukaisuuden ja kaatumispalautuksen jälkeen enemmistön saavuttaneet lokit eivät katoa, mutta yksittäisissä projekteissa on silti eroja.

MGR

XCOM kapseloi Paxos-protokollan kokonaan, ja kaikki sen protokollatiedot tallennetaan ensin välimuistiin. Oletuksena enemmistön saavuttaminen ei vaadi lokin pysyvyyttä. Siinä tapauksessa, että suurin osa piirakoista on alhaalla ja Leader epäonnistuu, syntyy vakava ongelma RPO != 0.Oletetaan äärimmäinen skenaario:

1. MGR-klusteri koostuu kolmesta solmusta ABC, joista AB on itsenäinen tietokonehuone samassa kaupungissa ja C on kaupunkien välinen solmu. A on johtaja, BC on seuraajasolmu
2. Aloita tapahtuma 001 Leader A -solmussa. Johtaja A lähettää tapahtumalokin 001 BC-solmulle, jos suurin osa on tyytyväinen Paxos-protokollan kautta, tapahtuma voidaan katsoa lähetetyksi. Osio AB muodosti enemmistön, eikä solmu C saanut tapahtumalokia 001 kaupunkien välisen verkon viiveen vuoksi.
3. Seuraavalla hetkellä johtaja A lähettää tapahtuman 001 ja palauttaa Asiakkaan onnistumisen, mikä tarkoittaa, että tapahtuma 001 on lähetetty tietokantaan.
4. Tällä hetkellä solmun B seuraajassa tapahtuman 001 loki on edelleen XCOM-välimuistissa, eikä sitä ole ehtinyt tyhjentää RelayLogiin tällä hetkellä, solmun C seuraaja ei ole vieläkään vastaanottanut tapahtumaa 001 loki solmun A johtajalta.
5. Tällä hetkellä solmu AB ei toimi, solmu A epäonnistuu eikä sitä voida palauttaa pitkään aikaan, solmu B käynnistyy uudelleen ja palautuu nopeasti, ja solmut BC tarjoavat edelleen luku- ja kirjoituspalveluita.
6. Koska tapahtumalokia 001 ei säilytetty solmun B RelayLogissa seisokkiajan aikana, eikä solmu C vastaanottanut sitä, joten tällä hetkellä BC-solmu on todella menettänyt tapahtuman 001 eikä voi hakea sitä.
7. Tässä skenaariossa, jossa enemmistöpuolue on kaatunut, RPO!=0

Yhteisön oletusparametreilla suurin osa tapahtumista ei vaadi lokin pysyvyyttä eikä takaa RPO=0:a Tätä voidaan pitää kompromissina XCOM-projektin toteutuksessa. Varmistaaksesi absoluuttisen RPO = 0, sinun on määritettävä parametri group_replication_consistency, joka ohjaa luku- ja kirjoitusyhteensopivuutta kohtaan AFTER. Tässä tapauksessa tapahtuma vaatii kuitenkin 1,5 RTT-verkon ylimääräisen lisäkulun saavuttaakseen suurimman osan. ja suorituskyky tulee olemaan erittäin huono.

DN

PolarDB-X DN käyttää X-Paxosta hajautetun protokollan toteuttamiseen ja on syvästi sidottu MySQL:n ryhmäsitoumusprosessiin. Suurin osa levyn sijoittelusta viittaa tässä pääkirjaston Binlog-sijoitteluun. Valmiustilassa olevan kirjaston IO-säie vastaanottaa pääkirjaston lokin ja kirjoittaa sen omaan Binlogiin pysyvyyttä varten. Siksi, vaikka kaikki solmut epäonnistuvat äärimmäisissä skenaarioissa, tietoja ei menetetä ja RPO=0 voidaan taata.

2.3. RTO

RTO-aika liittyy läheisesti itse järjestelmän kylmäkäynnistykseen kuluvaan aikaan, mikä näkyy erityisissä perustoiminnoissa:Vian havaitsemismekanismi -> kaatumispalautusmekanismi -> päävalintamekanismi -> lokin tasapainotus

2.3.1 Vian havaitseminen

MGR

• Jokainen solmu lähettää ajoittain sykepaketteja muille solmuille tarkistaakseen, ovatko muut solmut terveet. Sykejakso on kiinteä 1 sekuntia, eikä sitä voi säätää.
• Jos nykyinen solmu havaitsee, että muut solmut eivät ole vastanneet group_replication_member_expel_timeout (oletus 5s) jälkeen, sitä pidetään epäonnistuneena solmuna ja se poistetaan klusterista.
• Poikkeustapauksissa, kuten verkkokatkos tai epänormaali uudelleenkäynnistys, verkon palauttamisen jälkeen yksi epäonnistunut solmu yrittää automaattisesti liittyä klusteriin ja sitoa sitten lokin.

DN

• Leader-solmu lähettää ajoittain sykepaketteja muille solmuille tarkistaakseen, ovatko muut solmut terveet. Sykejakso on 1/5 valinnan aikakatkaisusta. Valinnan aikakatkaisua ohjaa parametri consensus_election_timeout Oletusarvo on 5 s, joten johtosolmun sykejakson oletusarvo on 1 s.
• Jos johtaja havaitsee, että muut solmut ovat offline-tilassa, se jatkaa ajoittain sykepakettien lähettämistä kaikille muille solmuille varmistaakseen, että muut solmut pääsevät käsiksi ajoissa kaatumisen ja palautumisen jälkeen.Leader-solmu ei kuitenkaan enää lähetä tapahtumalokeja offline-solmuun.
• Ei-johtajasolmut eivät lähetä sydämenlyöntien tunnistuspaketteja, mutta jos ei-johtajasolmu havaitsee, että se ei ole vastaanottanut sykettä johtajasolmulta consensus_election_timeout jälkeen, uudelleenvalinta käynnistyy.
• Poikkeustapauksissa, kuten verkkokatkos tai epänormaali uudelleenkäynnistys, viallinen solmu liittyy automaattisesti klusteriin verkon palauttamisen jälkeen.
• Siksi DN tarjoaa vian havaitsemisen kannalta enemmän käyttö- ja ylläpitomääritysliittymiä, ja vikojen tunnistaminen kaupunkien välisissä käyttöönottoskenaarioissa on tarkempaa.

2.3.2 Kaatumisista palautuminen

MGR

• • XCOM:n toteuttama Paxos-protokolla on muistitilassa. Enemmistön saavuttaminen ei vaadi pysyvyyttä.Jos kaikki solmut katkaisevat puhelun, protokollaa ei voida palauttaa Kun klusteri on käynnistetty uudelleen, sen palauttaminen edellyttää manuaalista toimenpidettä.
  • Jos vain yksi solmu kaatuu ja se palautetaan, mutta seuraajasolmu jää jäljessä Leader-solmusta, jolla on enemmän tapahtumalokeja, ja Leaderin XCOM-välimuistissa olevat tapahtumalokit on tyhjennetty, ainoa vaihtoehto on käyttää Global Recovery- tai Clone -prosessia.
  • XCOM-välimuistin kokoa ohjaa group_replication_message_cache_size, oletusarvo on 1 Gt
  • Global Recovery tarkoittaa, että kun solmu liittyy uudelleen klusteriin, se palauttaa tiedot hankkimalla tarvittavat puuttuvat tapahtumalokit (binaariloki) muilta solmuilta.Tämä prosessi perustuu vähintään yhteen klusterin solmuun, joka säilyttää kaikki vaaditut tapahtumalokit
  • Clone luottaa Clone Pluginiin, jota käytetään palautukseen, kun tietomäärä on suuri tai monet lokit puuttuvat.Se toimii kopioimalla tilannekuvan koko tietokannasta kaatuneeseen solmuun, minkä jälkeen suoritetaan lopullinen synkronointi viimeisimmän tapahtumalokin kanssa.
  • Global Recovery- ja Clone-prosessit ovat yleensä automatisoituja, mutta joissain erikoistapauksissa, kuten verkkoongelmissa tai kahden muun solmun XCOM-välimuistin tyhjennyksenä, tarvitaan manuaalista toimenpiteitä.

DN

• • X-Paxos-protokolla käyttää Binlogin pysyvyyttä Kun kaatumisesta palautuu, lähetetyt tapahtumat palautetaan ensin. Odottavat tapahtumat odottavat, että XPaxos-protokollakerros pääsee sopimukseen master-backup-suhteen määrittämiseksi, ennen kuin sitoudut tai peruutat tapahtuman. Koko prosessi on täysin automatisoitu.Vaikka kaikki solmut ovat alhaalla, klusteri voi palautua automaattisesti uudelleenkäynnistyksen jälkeen.
  • Skenaarioissa, joissa seuraajasolmu on jäljessä Leader-solmun jälkeen monissa tapahtumalokeissa, niin kauan kuin Leaderin Binlog-tiedostoa ei poisteta, Seuraaja-solmu saavuttaa varmasti.
  • Siksi DN ei vaadi kaatumisen palauttamisen kannalta manuaalista puuttumista ollenkaan.

2.3.3 Johtajan valinta

Single-master-tilassa MGR:n XCOM ja DN X-Paxos, vahva johtajatila, noudattavat samaa perusperiaatetta johtajan valinnassa - klusterin sopimia lokeja ei voi peruuttaa. Mutta mitä tulee yksimielisyyteen, siinä on eroja

MGR

• Leader-valinta kertoo enemmän siitä, mikä solmu toimii Leader-palveluna seuraavaksi.Tällä Leaderilla ei välttämättä ole viimeisintä konsensuslokia, kun se valitaan, joten sen on synkronoitava uusimmat lokit muista klusterin solmuista ja tarjottava luku- ja kirjoituspalveluita lokien sidottua.
• Tämän etuna on, että itse Leaderin valinta on strateginen tuote, kuten paino ja järjestys. MGR ohjaa kunkin solmun painoa group_replication_member_weight -parametrin kautta
• Haittapuolena on, että vastikään valitulla johtajalla itsellään voi olla suuri replikointiviive, ja sen on edelleen päästävä kiinni lokiin tai sillä voi olla suuri sovellusviive, ja sen on edelleen saatava kiinni lokisovellukseen, ennen kuin se voi tarjota luku- ja kirjoituspalvelut.Tämä johtaa pidemmän RTO-ajan

DN

• Johtajan valinta on pöytäkirjan merkityksessä se, missä solmussa on kaikkien klusterin enemmistöpuolueiden lokit, voidaan valita johtajaksi, joten tämä solmu on voinut olla seuraaja tai kirjailija.
• Loggeri ei voi tarjota luku- ja kirjoituspalveluita Synkronoituaan lokit muihin solmuihin, se luopuu aktiivisesti johtajan roolista.
• Varmistaakseen, että nimetystä solmusta tulee johtaja, DN käyttää optimistista painostrategiaa + pakollista painostrategiaa rajoittaakseen johtajaksi tulemisen järjestystä ja käyttää strategista enemmistömekanismia varmistaakseen, että uusi isäntä voi välittömästi tarjota luku- ja kirjoitustoiminnot. palvelut ilman viivettä.
• Siksi johtajan valinnassa DN ei vain tue samaa strategista valintaa kuin MGR, vaan tukee myös pakollisia painostrategioita.

2.3.4 Lokin sovitus

Lokin tasaus tarkoittaa, että lokeissa on lokien replikointiviive ensisijaisen ja toissijaisen tietokannan välillä, ja toissijaisen tietokannan on tasattava lokit. Uudelleenkäynnistetyille ja palautetuille solmuille palautus aloitetaan yleensä valmiustilatietokannasta, ja lokin replikointiviive on jo tapahtunut päätietokantaan verrattuna, ja lokit on saatava päätietokantaan. Niille solmuille, jotka ovat fyysisesti kaukana Leaderista, enemmistön saavuttamisella ei yleensä ole mitään tekemistä niiden kanssa. Niillä on aina replikointilokin viive ja ne saavuttavat aina lokin. Nämä tilanteet edellyttävät erityistä suunnittelutoteutusta lokin replikointiviiveiden oikea-aikaisen ratkaisemisen varmistamiseksi.

MGR

• Tapahtumalokit ovat kaikki XCOM-välimuistissa, ja välimuisti on oletuksena vain 1G. Siksi välimuisti on helppo tyhjentää, kun seuraajasolmu on paljon jäljessä pyyntölokien kopioinnissa.
• Tällä hetkellä jäljessä oleva seuraaja potkaistaan ​​automaattisesti ulos klusterista ja käyttää sitten yllä mainittua Global Recovery- tai Clone-prosessia kaatumisista palautumiseen ja liittyy sitten automaattisesti klusteriin, kun se on kiinni.Jos kohtaatEsimerkiksi verkko-ongelmat tai kahden muun solmun XCOM-välimuisti tyhjennetään, jolloin ongelman ratkaiseminen edellyttää manuaalista puuttumista.
• Miksi meidän on poistettava klusteri ensin, koska viallinen solmu monikirjoitustilassa vaikuttaa suuresti suorituskykyyn, eikä Leaderin välimuistilla ole vaikutusta siihen. Se täytyy lisätä asynkronisen yhdistämisen jälkeen.
• Miksi emme voi lukea suoraan Leaderin paikallista Binlog-tiedostoa Koska aiemmin mainittu XCOM-protokolla on täydessä muistissa, eikä Binlogissa ja välityslokissa ole protokollatietoja?

DN

• Kaikki tiedot ovat Binlog-tiedostossa Niin kauan kuin Binlogia ei puhdisteta, ne voidaan lähettää pyynnöstä, eikä sitä ole mahdollista potkaista ulos klusterista.
• Vähentääkseen IO-värinää, jonka aiheuttaa pääkirjasto, joka lukee vanhoja tapahtumalokeja Binlog-tiedostosta, DN antaa etusijalle viimeksi välimuistissa olevien tapahtumalokien lukemisen FIFO-välimuistista. FIFO-välimuistia ohjaa parametri consensus_log_cache_size ja oletusarvo on 64 miljoonaa
• Jos päivitetty tapahtumaloki on poistanut vanhan tapahtumalokin FIFO-välimuistista, DN yrittää lukea aiemmin välimuistissa olevan tapahtumalokin Prefetch-välimuistista. Prefetch-välimuistia ohjaa parametri consensus_prefetch_cache_size, ja oletusarvo on 64M.
• Jos esihaun välimuistissa ei ole vaadittua vanhaa tapahtumalokia, DN yrittää käynnistää asynkronisen IO-tehtävän, lukee useita peräkkäisiä lokeja ennen ja jälkeen määritettyä tapahtumalokia Binlog-tiedostosta erissä, sijoittaa ne Prefetch-välimuistiin ja odottaa. DN:n seuraavaa uudelleenlukemista varten
• Siksi DN ei vaadi lainkaan manuaalista puuttumista lokin tasapainottamiseen.

2.4 Valmiustilan tietokannan toistoviive

Valmiustilatietokannan toistoviive on viive ajankohdan välillä, jolloin sama tapahtuma suoritetaan päätietokannassa, ja aika, jolloin tapahtuma otetaan käyttöön valmiustilatietokannassa. Tässä testataan valmiustilatietokannan Apply-lokin suorituskyky. Se vaikuttaa siihen, kuinka kauan valmiustilassa oleva tietokanta suorittaa tietosovelluksensa ja tarjoaa luku- ja kirjoituspalveluita poikkeuksen sattuessa.

MGR

• MGR-valmiustietokanta vastaanottaa RelayLog-tiedoston päätietokannasta Kun sovellusta käytetään, sen täytyy lukea RelayLog uudelleen, käydä läpi täydellinen kaksivaiheinen ryhmälähetysprosessi ja tuottaa vastaavat tiedot ja Binlog-tiedostot.
• Tapahtumasovelluksen tehokkuus tässä on sama kuin tapahtuman lähetyksen tehokkuus päätietokannassa. Oletusarvoinen double-one-kokoonpano (innodb_flush_log_at_trx_commit, sync_binlog) aiheuttaa sen, että valmiustilan tietokantasovelluksen resurssit ovat suuret.

DN

• DN-varmuuskopiotietokanta vastaanottaa Binlog-tiedoston päätietokannasta Hakemuksen yhteydessä Binlog-tiedosto on luettava uudelleen. Sen tarvitsee vain käydä läpi yksivaiheinen ryhmälähetysprosessi ja tuottaa vastaavat tiedot.
• Koska DN tukee täydellistä Crash Recover -toimintoa, valmiustilassa olevan tietokantasovelluksen ei tarvitse ottaa käyttöön innodb_flush_log_at_trx_commit=1, joten double-one-kokoonpano ei itse asiassa vaikuta siihen.
• Siksi valmiustilatietokannan toistoviiveen suhteen DN-valmiustilatietokannan toistotehokkuus on paljon suurempi kuin MGR.

2.5 Suurten tapahtumien vaikutukset

Suuret tapahtumat eivät vaikuta vain tavallisten tapahtumien lähettämiseen, vaan vaikuttavat myös koko hajautetun protokollan vakauteen hajautetussa järjestelmässä.

MGR

• MGR:ssä ei ole optimointia suurten tapahtumien tukemiseksi. Se vain lisää parametrin group_replication_transaction_size_limit suurten tapahtumien ylärajan hallitsemiseksi.
• Kun tapahtumaloki ylittää suuren tapahtumarajan, virhe raportoidaan suoraan eikä tapahtumaa voida lähettää.

DN

• Suurten tapahtumien aiheuttaman hajautettujen järjestelmien epävakausongelman ratkaisemiseksi DN ottaa käyttöön ratkaisun suurten tapahtumien jakamisesta + suuren objektin jakamisesta ongelman ratkaisemiseksi jakaa tapahtumalokin loogisesti + fyysisesti pieniä lohkoja, jokainen pieni tapahtumalokin lohko käyttää täyttä Paxos-sitoumustakuuta
• Suurten tapahtumien jakamisen ratkaisun perusteella DN ei aseta rajoituksia suurten tapahtumien koolle. Käyttäjät voivat käyttää niitä halutessaan ja voivat myös varmistaa, että RPO = 0.
• Katso tarkemmat ohjeet"PolarDB-X Storage Engine -ydintekniikka | Suuren tapahtuman optimointi"
• Siksi DN voi hoitaa suuria asioita ilman, että suuret asiat vaikuttavat siihen.

2.6 Käyttöönottolomake

MGR

• MGR tukee yhden isäntä- ja usean isännän käyttöönottotiloja Multi-master-tilassa jokaista solmua voidaan lukea ja kirjoittaa. vain.
• Korkean käytettävyyden MGR-käyttöönotto vaatii vähintään kolme solmun käyttöönottoa, eli vähintään kolme kopiota tiedoista ja lokeista. Lokikopiointitilaa ei tueta.
• MGR ei tue vain luku -solmujen laajentamista, mutta se tukee MGR + master-slave -replikointitilan yhdistelmää samanlaisen topologian laajennuksen saavuttamiseksi.

DN

• DN tukee yhden pääkäyttäjän tilan käyttöönottoa. Yhden pääkäyttäjän tilassa päätietokanta voidaan lukea ja kirjoittaa, ja valmiustilatietokanta voi olla vain luku -tilassa.
• DN:n korkean käytettävyyden käyttöönotto vaatii vähintään kolmea solmua, mutta tukee lokikopiointia, eli Leader ja Follower ovat täydellisiä kopioita Loggeriin verrattuna siinä on vain lokit eikä tietoja, eikä sillä ole oikeutta olla valittu. Tässä tapauksessa kolmen solmun korkean käytettävyyden käyttöönotto vaatii vain 2 datakopion + 3 lokikopion tallennuksen, mikä tekee siitä edullisen käyttöönoton.
• DN tukee vain luku -solmun käyttöönottoa ja vain luku -kopiointia. Verrattuna täysimittaisiin kopioihin, sillä ei ole äänioikeuksia vain Learner-kopioiden kautta.

2.7 Ominaisuuden yhteenveto

3. Testivertailu

MGR otettiin käyttöön MySQL 5.7.17:ssä, mutta enemmän MGR:ään liittyviä ominaisuuksia on saatavilla vain MySQL 8.0:ssa, ja MySQL 8.0.22:ssa ja uudemmissa versioissa yleinen suorituskyky on vakaampi ja luotettavampi. Siksi valitsimme molempien osapuolten uusimman version 8.0.32 vertailutestaukseen.

Ottaen huomioon, että PolarDB-X DN:n ja MySQL MGR:n vertailutestauksen aikana on eroja testiympäristöissä, käännösmenetelmissä, käyttöönottomenetelmissä, toimintaparametreissa ja testausmenetelmissä, mikä voi johtaa epätarkkoihin testivertailutietoihin, tässä artikkelissa keskitytään erilaisiin yksityiskohtiin. Toimi seuraavasti:

Huomautus:

• MGR on oletuksena käytössä, kun taas PolarDB-X DN on oletuksena pois päältä.Siksi MGR:n group_replication_flow_control_mode konfiguroidaan erikseen, jotta MGR:n suorituskyky on paras.
• MGR:llä on ilmeinen lukemisen pullonkaula luettelon aikana, joten MGR:n replication_optimize_for_static_plugin_config konfiguroidaan ja otetaan käyttöön erikseen, jotta MGR:n vain luku -suorituskyky on paras.

3.1 Suorituskyky

Suorituskykytestaus on ensimmäinen asia, johon jokainen kiinnittää huomiota tietokantaa valitessaan. Täällä käytämme virallista sysbench-työkalua rakentamaan 16 taulukkoa, joissa kussakin on 10 miljoonaa dataa, suorittamaan suorituskykytestauksia OLTP-skenaarioissa sekä testaamaan ja vertaamaan näiden kahden suorituskykyä eri samanaikaisissa olosuhteissa eri OLTP-skenaarioissa.Ottaen huomioon todellisen käyttöönoton eri tilanteet, simuloimme seuraavat neljä käyttöönottoskenaariota:

1. Samassa tietokonehuoneessa on käytössä kolme solmua. Verkon viive on 0,1 ms, kun koneet pingaavat toisiaan.
2. Kolme keskusa samassa kaupungissa ja kolme tietokonehuonetta samalla alueella käyttävät kolmea solmua Tietokonehuoneiden välisessä pingissä on 1 ms:n viive (esimerkiksi kolme tietokonehuonetta Shanghaissa).
3. Kolme keskusta kahdessa paikassa, kolme solmua kolmessa tietokonehuoneessa kahdessa paikassa, 1 ms verkon ping saman kaupungin tietokonehuoneiden välillä, 30 ms verkon viive saman kaupungin ja toisen paikan välillä (esimerkiksi Shanghai/Shanghai/Shenzhen)
4. Kolme keskusta kolmessa paikassa, kolme solmua kolmessa tietokonehuoneessa kolmessa paikassa (esimerkiksi: Shanghai/Hangzhou/Shenzhen), verkon viive Hangzhoun ja Shanghain välillä on noin 5ms ja kauimpana etäisyys Hangzhousta/Shanghaista Shenzheniin on 30ms. .

havainnollistaa:

a. Harkitse neljän käyttöönottoskenaarion suorituskyvyn horisontaalista vertailua. Kolme keskusa kahdessa paikassa ja kolme keskusa ottavat käyttöön 3 kopion käyttöönottotilan.

b. Ottaen huomioon tiukat rajoitukset RPO=0:lle käytettäessä korkean käytettävyyden tietokantatuotteita, MGR on määritetty oletuksena RPO<>0:lla. Tässä jatkamme vertailutestien lisäämistä MGR RPO<>0:n ja RPO=0:n välillä käyttöönoton skenaario.

• MGR_0 edustaa dataa tapauksessa MGR RPO = 0
• MGR_1 edustaa dataa tapaukselle MGR RPO <> 0
• DN edustaa dataa tapauksessa DN RPO = 0

3.1.1 Sama tietokonehuone

Se näkyy testituloksista:

• Vain luku -skenaariossa, verrataanpa sitten MGR_1 (RPO<>0) tai MGR_0 (RPO=0), ero DN:n ja MGR:n välillä on vakaa välillä -5 % ja 10 %, jota voidaan pitää periaatteessa samana. Se, onko RPO yhtä suuri kuin 0, ei vaikuta vain luku -tapahtumiin
• Sekaisessa luku-kirjoitus- ja vain kirjoitustapahtumissa DN:n (RPO=0) suorituskyky paranee 5 %:lla 47 %:iin verrattuna MGR_1:een (RPO<>0), ja DN:n suorituskykyetu on ilmeinen, kun Samanaikaisuus on alhainen, ja etu, kun samanaikaisuus on korkea Ei-ilmeisiä ominaisuuksia. Tämä johtuu siitä, että DN:n protokollatehokkuus on korkeampi, kun samanaikaisuus on alhainen, mutta DN:n ja MGR:n suorituskykypisteet korkean samanaikaisuuden aikana ovat kaikki puhdistuksessa.
• Samassa lähtökohdassa RPO=0, luku-kirjoitus- ja vain kirjoitustapahtumissa, DN:n suorituskyky paranee 2 kertaa 46-kertaiseksi verrattuna MGR_0:aan, ja samanaikaisuuden kasvaessa DN:n suorituskykyetu paranee. Ei ihme, että MGR hylkää oletuksena myös RPO=0:n suorituskyvyn vuoksi.

3.1.2 Kolme keskustaa samassa kaupungissa

Se näkyy testituloksista:

• Vain luku -skenaariossa, verrataanpa sitten MGR_1 (RPO<>0) tai MGR_0 (RPO=0), ero DN:n ja MGR:n välillä on vakaa välillä -7 % ja 5 %, jota voidaan pitää periaatteessa samana. Se, onko RPO yhtä suuri kuin 0, ei vaikuta vain luku -tapahtumiin
• Sekaisessa luku-kirjoitus- ja vain kirjoitustapahtumien skenaariossa DN:n (RPO=0) suorituskyky paranee 30–120 % verrattuna MGR_1:een (RPO<>0), ja DN:n suorituskykyetu on ilmeinen samanaikaisesti on alhainen, ja kun samanaikaisuus on korkea, suorituskyky on parempi Ei-ilmeisiä ominaisuuksia. Tämä johtuu siitä, että DN:n protokollatehokkuus on korkeampi, kun samanaikaisuus on alhainen, mutta DN:n ja MGR:n suorituskykypisteet korkean samanaikaisuuden aikana ovat kaikki puhdistuksessa.
• Samassa lähtökohdassa RPO=0, luku-kirjoitus- ja vain kirjoitustapahtumissa, DN:n suorituskyky paranee 1-14 kertaa verrattuna MGR_0:aan, ja samanaikaisuuden kasvaessa DN:n suorituskykyetu paranee. Ei ihme, että MGR hylkää oletuksena myös RPO=0:n suorituskyvyn vuoksi.

3.1.3 Kaksi paikkaa ja kolme keskustaa

Se näkyy testituloksista:

• Vain luku -skenaariossa, verrataanpa sitten MGR_1 (RPO<>0) tai MGR_0 (RPO=0), ero DN:n ja MGR:n välillä on vakaa välillä -4 % ja 7 %, jota voidaan pitää periaatteessa samana. Se, onko RPO yhtä suuri kuin 0, ei vaikuta vain luku -tapahtumiin
• Sekaisessa luku-kirjoitus- ja vain kirjoitustapahtumien skenaariossa DN:n (RPO=0) suorituskyky paranee 2-16-kertaiseksi verrattuna MGR_1:een (RPO<>0), ja DN:n suorituskykyetu on ilmeinen samanaikaisissa on alhainen, ja etu samanaikaisuuden ollessa korkea Ei-ilmeisiä ominaisuuksia. Tämä johtuu siitä, että DN:n protokollatehokkuus on korkeampi, kun samanaikaisuus on alhainen, mutta DN:n ja MGR:n suorituskykypisteet korkean samanaikaisuuden aikana ovat kaikki puhdistuksessa.
• Samassa lähtökohdassa RPO=0, luku-kirjoitus- ja vain kirjoitustapahtumissa, DN:n suorituskyky paranee 8 kertaa 29-kertaiseksi verrattuna MGR_0:aan, ja samanaikaisuuden kasvaessa DN:n suorituskykyetu paranee. Ei ihme, että MGR hylkää oletuksena myös RPO=0:n suorituskyvyn vuoksi.

3.1.4 Kolme paikkaa ja kolme keskusta

Se näkyy testituloksista:

• Vain luku -skenaariossa, verrataanpa sitten MGR_1 (RPO<>0) tai MGR_0 (RPO=0), ero DN:n ja MGR:n välillä on vakaa välillä -5 % ja 0 %, jota voidaan pitää periaatteessa samana. Se, onko RPO yhtä suuri kuin 0, ei vaikuta vain luku -tapahtumiin
• Sekoitettu luku-kirjoitus- ja vain kirjoitustapahtumien skenaariossa DN:n (RPO=0) suorituskyky paranee 2-5-kertaiseksi verrattuna MGR_1:een (RPO<>0), ja DN:n suorituskykyetu on ilmeinen samanaikaisuudessa. on alhainen, ja etu samanaikaisuuden ollessa korkea Ei-ilmeisiä ominaisuuksia. Tämä johtuu siitä, että DN:n protokollatehokkuus on korkeampi, kun samanaikaisuus on alhainen, mutta DN:n ja MGR:n suorituskykypisteet korkean samanaikaisuuden aikana ovat kaikki puhdistuksessa.
• Samassa lähtökohdassa RPO=0, luku-kirjoitus- ja vain kirjoitustapahtumissa, DN:n suorituskyky paranee 2 kertaa 17-kertaiseksi verrattuna MGR_0:aan, ja samanaikaisuuden kasvaessa DN:n suorituskykyetu paranee. Ei ihme, että MGR hylkää oletuksena myös RPO=0:n suorituskyvyn vuoksi.

3.1.5 Käyttöönoton vertailu

Vertaaksemme selkeästi suorituskyvyn muutoksia eri käyttöönottomenetelmissä, valitsimme yllä olevassa testissä MGR:n ja DN:n TPS-tiedot eri käyttöönottomenetelmien oltp_write_only 256 -skenaariossa vertaili eri käyttöönottomenetelmien TPS-tietoja perusarvoon havaitakseen eron suorituskyvyn muutoksissa kaupunkien välisen käyttöönoton aikana

Se näkyy testituloksista:

• Käyttöönottomenetelmän laajentamisen myötä MGR_1:n TPS (RPO<>0) laski merkittävästi verrattuna samaan tietokonehuoneeseen, tietokoneiden välisen käyttöönoton suorituskyky samassa kaupungissa laski 27,5 % kaupunkien välisen käytön (kolme keskusta kahdessa paikassa, kolme keskusta kolmessa paikassa) käyttöönotto Lasku 77 % ~ 82 %, mikä johtuu RT:n käytön lisääntymisestä eri kaupunkien välillä.
• DN (RTO=0) on suhteellisen vakaa Verrattuna samaan tietokonehuoneeseen, tietokoneiden välisten huoneiden käyttöönoton suorituskyky samassa kaupungissa ja kolmen keskuksen käyttöönotossa kahdessa paikassa laski 4 %:lla 12 %:iin. Kolmen keskuksen käyttöönoton tehokkuus laski 37 % korkean verkkoviiveen vuoksi.DN:n Batch&Pipeline-mekanismin ansiosta kaupunkien väliset vaikutukset voidaan kuitenkin ratkaista lisäämällä samanaikaisuutta. Esimerkiksi kolmen paikan ja kolmen keskuksen arkkitehtuurissa >=512 samanaikaisuuden suoritustehoa samassa kaupungissa ja kahdessa. paikat ja kolme keskustaa voidaan periaatteessa kohdistaa.
• Voidaan nähdä, että kaupunkien välisellä käyttöönotolla on suuri vaikutus MGR_1:een (RPO<>0)

3.1.6 Suorituskyky Jitter

Varsinaisessa käytössä emme kiinnitä huomiota vain suorituskykytietoihin, vaan meidän on kiinnitettävä huomiota myös suorituskyvyn tärinään. Loppujen lopuksi, jos värinä on kuin vuoristorata, todellinen käyttökokemus on erittäin huono. Tarkkailemme ja näytämme TPS:n reaaliaikaisia ​​lähtötietoja Koska sysbenc-työkalu ei itse tue suorituskyvyn värinän tulosseurantatietoja, käytämme matemaattista variaatiokerrointa vertailuindikaattorina:

• Variaatiokerroin (CV): Variaatiokerroin on keskihajonna jaettuna keskiarvolla. Sitä käytetään yleensä eri tietojoukkojen vaihteluiden vertaamiseen, varsinkin kun keskimääräiset erot ovat suuria. Mitä suurempi CV, sitä suurempi on datan vaihtelu suhteessa keskiarvoon.

Ottamalla 256 samanaikaisen oltp_read_write -skenaarion esimerkkinä analysoimme tilastollisesti MGR_1 (RPO<>0) ja DN (RPO=0) TPS:t samassa tietokonehuoneessa, kolmessa keskustassa samassa kaupungissa, kolmessa keskustassa kahdessa paikassa ja kolme keskustaa kolmessa paikassa. Varsinainen värinäkaavio on seuraava, ja kunkin skenaarion varsinaiset värinäindikaattoritiedot ovat seuraavat:

Se näkyy testituloksista:

• MGR:n TPS on epävakaassa tilassa oltp_read_write-skenaariossa, ja se putoaa äkillisesti ilman syytä. Tämä ilmiö on havaittu useissa testeissä useissa käyttöönottoskenaarioissa. Vertailun vuoksi DN on erittäin vakaa.
• Variaatiokertoimen CV:tä laskettaessa MGR:n CV on erittäin suuri, 6 % - 10 % ja saavuttaa jopa maksimiarvon 10 %, kun viive samassa tietokonehuoneessa on minimaalinen, kun taas DN:n CV on suhteellisen vakaa, 2 % - 4 %, ja DN:n suorituskyky on vakaampi kuin MGR:n Sex on periaatteessa kaksi kertaa korkeampi
• Voidaan nähdä, että MGR_1:n (RPO<>0) suorituskykyvärinä on suhteellisen suuri

3.2. RTO

Hajautetun tietokannan ydinominaisuus on korkea käytettävyys. Klusterin minkään solmun vika ei vaikuta yleiseen saatavuuteen. Tyypillisessä käyttöönottomuodossa, jossa on kolme solmua, joissa on yksi isäntä ja kaksi varmuuskopiota samassa tietokonehuoneessa, yritimme suorittaa käytettävyystestejä seuraavissa kolmessa skenaariossa:

• Keskeytä päätietokanta, käynnistä se sitten uudelleen ja tarkkaile RTO-aikaa, jonka kuluessa klusteri palauttaa saatavuuden prosessin aikana.
• Keskeytä mikä tahansa valmiustilassa oleva tietokanta ja käynnistä se sitten uudelleen tarkkaillaksesi ensisijaisen tietokannan käytettävyyttä prosessin aikana.

3.2.1 Päätietokannan seisokki + uudelleenkäynnistys

Kun kuormaa ei ole, lopeta johtaja ja seuraa klusterin jokaisen solmun tilamuutoksia ja sitä, onko se kirjoitettava.

Testituloksista voidaan nähdä, että ilman paineita:

• DN:n RTO on 8-15 s, kestää 8 sekuntia pienentää 2 solmuun ja 15 sekuntia palauttaa 3 solmua;
• MGR:n RTO on 23–37 sekuntia, jotta se laskee 2 solmuun ja 37 sekuntia palauttaa 3 solmua.
• RTO-suorituskyky DN on kaiken kaikkiaan parempi kuin MGR

3.2.2 Standby-tietokannan seisokki + uudelleenkäynnistys

Käytä sysbenchiä suorittaaksesi samanaikaisen 16 säikeen stressitestin oltp_read_write-skenaariossa. Tapa kuvan 10. sekunti manuaalisesti valmiustilasolmu ja tarkkaile sysbenchin reaaliaikaisia ​​TPS-tietoja.

Se näkyy testitulostaulukosta:

• Valmiustilatietokannan keskeytymisen jälkeen MGR:n päätietokannan TPS putosi merkittävästi ja kesti noin 20 sekuntia ennen kuin palautui normaalille tasolle. Lokianalyysin mukaan tässä on kaksi prosessia: viallisen solmun havaitseminen ja viallisen solmun poistaminen MGR-klusterista. Tämä testi vahvisti virheen, joka on kiertänyt MGR-yhteisössä pitkään, vaikka vain yksi solmu 3:sta ei olisi käytettävissä.Koko klusteri koki voimakasta värinää jonkin aikaa, eikä se ollut käytettävissä.
• Ratkaisekseen ongelman, jossa yhden pään MGR:ssä on yksi solmuvirhe ja koko ilmentymä ei ole käytettävissä, yhteisö otti käyttöön MGR paxos single leader -toiminnon versiosta 8.0.27 ongelman ratkaisemiseksi, mutta se on oletuksena pois päältä. Tässä otamme käyttöön group_replication_paxos_single_leader-toiminnon ja jatkamme varmistusta, kun tällä kertaa keskeytettiin päätietokannan suorituskyky ja se on hieman parantunut.
• DN:lle valmiustilan tietokannan keskeytymisen jälkeen päätietokanta TPS kasvoi välittömästi noin 20 % ja pysyi sitten vakaana, ja klusteri oli aina käytettävissä.Tämä on päinvastoin kuin MGR. Syynä on, että valmiustilatietokannan keskeyttämisen jälkeen päätietokannan tarvitsee lähettää vain lokit jäljellä olevaan valmiustilatietokantaan, ja verkkopakettien lähetys- ja vastaanottoprosessi on tehokkaampi.

Jatkamme testiä, käynnistämme uudelleen ja palautamme valmiustilatietokannan ja tarkkailemme muutoksia päätietokannan TPS-tiedoissa.

Se näkyy testitulostaulukosta:

• MGR palautui 2 solmusta 3 solmuun 5 sekunnissa.Mutta on myös tilanne, jossa pääkirjasto ei ole käytettävissä, mikä kestää noin 12 sekuntia.Vaikka valmiussolmu vihdoin liittyi klusteriin, MEMBER_STATE-tila on aina ollut PALAUTTAA, mikä osoittaa, että tietoja jaetaan tällä hetkellä.
• Skenaariossa, kun group_replication_paxos_single_leader on otettu käyttöön, myös valmiustilan tietokannan uudelleenkäynnistys varmistetaan. Tämän seurauksena MGR palautuu 2 solmusta 3 solmuun 10 sekunnissa.Mutta vielä oli noin 7 sekuntia käyttämätön aika.Näyttää siltä, ​​​​että tämä parametri ei voi täysin ratkaista ongelmaa, jossa yhden pään MGR:ssä on yksi solmuvirhe ja koko ilmentymä ei ole käytettävissä.
• DN:ssä valmiustilassa oleva tietokanta palautuu 2 solmusta 3 solmuun 10 sekunnissa, ja ensisijainen tietokanta pysyy käytettävissä. TPS:ssä tulee olemaan lyhytaikaisia ​​vaihteluita. Tämä johtuu siitä, että uudelleenkäynnistetyn valmiustilatietokannan lokin replikointiviive on jäljessä, ja viivästyneet lokit on poistettava päätietokannasta päätietokanta Lokin tarkastelun jälkeen kokonaissuorituskyky on vakaa.

3.3. RPO

MGR-enemmistövika RPO<>0 -skenaarion rakentamiseksi käytämme yhteisön omaa MTR Case -menetelmää virheen injektiotestien suorittamiseen MGR:ssä. Suunniteltu tapaus on seuraava:

--echo
--echo ############################################################
--echo # 1. Deploy a 3 members group in single primary mode.
--source include/have_debug.inc
--source include/have_group_replication_plugin.inc
--let $group_replication_group_name= aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
--let $rpl_group_replication_single_primary_mode=1
--let $rpl_skip_group_replication_start= 1
--let $rpl_server_count= 3
--source include/group_replication.inc
 
--let $rpl_connection_name= server1
--source include/rpl_connection.inc
--let $server1_uuid= `SELECT @@server_uuid`
--source include/start_and_bootstrap_group_replication.inc
 
--let $rpl_connection_name= server2
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
--source include/start_group_replication.inc
 
--echo
--echo ############################################################
--echo # 2. Init data
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
 
--source include/rpl_sync.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
 
--echo
--echo ############################################################
--echo # 3. Mock crash majority members
 
--echo # server 2 wait before write relay log
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
--echo # server 3 wait before write relay log
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
 
 
--echo # server 1 commit new transaction
--let $rpl_connection_name = server1
--source include/rpl_connection.inc
INSERT INTO t1 VALUES(2);
# server 1 commit t1(c1=2) record
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 1 crash
--source include/kill_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 3 check
--let $rpl_connection_name = server3
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
SELECT * FROM t1;
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 crash and restart
--source include/kill_and_restart_mysqld.inc
 
--echo # sleep enough time for electing new leader
sleep 60;
 
--echo
--echo ############################################################
--echo # 4. Check alive members, lost t1(c1=2) record
 
--echo # server 3 check
--let $rpl_connection_name= server3
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 3 lost t1(c1=2) record
SELECT * FROM t1;
 
--echo 
--echo # server 2 check
--let $rpl_connection_name = server2
--source include/rpl_connection.inc
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
--echo # server 2 lost t1(c1=2) record
SELECT * FROM t1;

!include ../my.cnf
 
[mysqld.1]
loose-group_replication_member_weight=100
 
[mysqld.2]
loose-group_replication_member_weight=90
 
[mysqld.3]
loose-group_replication_member_weight=80
 
[ENV]
SERVER_MYPORT_3=		@mysqld.3.port
SERVER_MYSOCK_3=		@mysqld.3.socket

Asian käsittelyn tulokset ovat seuraavat:

 
############################################################
# 1. Deploy a 3 members group in single primary mode.
include/group_replication.inc [rpl_server_count=3]
Warnings:
Note	####	Sending passwords in plain text without SSL/TLS is extremely insecure.
Note	####	Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
[connection server1]
[connection server1]
include/start_and_bootstrap_group_replication.inc
[connection server2]
include/start_group_replication.inc
[connection server3]
include/start_group_replication.inc
 
############################################################
# 2. Init data
[connection server1]
CREATE TABLE t1 (c1 INT PRIMARY KEY);
INSERT INTO t1 VALUES(1);
include/rpl_sync.inc
SELECT * FROM t1;
c1
1
[connection server2]
SELECT * FROM t1;
c1
1
[connection server3]
SELECT * FROM t1;
c1
1
 
############################################################
# 3. Mock crash majority members
# server 2 wait before write relay log
[connection server2]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 3 wait before write relay log
[connection server3]
SET GLOBAL debug = '+d,wait_in_the_middle_of_trx';
# server 1 commit new transaction
[connection server1]
INSERT INTO t1 VALUES(2);
SELECT * FROM t1;
c1
1
2
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13000	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13002	ONLINE	SECONDARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 1 crash
# Kill the server
# sleep enough time for electing new leader
 
# server 3 check
[connection server3]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	ONLINE	SECONDARY	8.0.32	XCom
# server 3 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
# server 2 check
[connection server2]
SELECT * FROM t1;
c1
1
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier	127.0.0.1	13002	ONLINE	PRIMARY	8.0.32	XCom
group_replication_applier	127.0.0.1	13004	UNREACHABLE	SECONDARY	8.0.32	XCom
# server 2 crash and restart
# Kill and restart
# sleep enough time for electing new leader
 
############################################################
# 4. Check alive members, lost t1(c1=2) record
# server 3 check
[connection server3]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 3 lost t1(c1=2) record
SELECT * FROM t1;
c1
1
 
# server 2 check
[connection server2]
select CHANNEL_NAME,MEMBER_HOST,MEMBER_PORT,MEMBER_STATE,MEMBER_ROLE,MEMBER_VERSION,MEMBER_COMMUNICATION_STACK from performance_schema.replication_group_members order by MEMBER_PORT;
CHANNEL_NAME	MEMBER_HOST	MEMBER_PORT	MEMBER_STATE	MEMBER_ROLE	MEMBER_VERSION	MEMBER_COMMUNICATION_STACK
group_replication_applier		NULL	OFFLINE			
# server 2 lost t1(c1=2) record
SELECT * FROM t1;
c1
1

Puuttuvat numerot toistavan tapauksen likimääräinen logiikka on seuraava:

1. MGR koostuu 3 solmusta yhden pääkäyttäjän tilassa, palvelin 1/2/3, jossa palvelin 1 on päätietokanta ja alustaa 1 tietueen c1=1
2. Vikailmoitus Palvelin 2/3 jumittuu, kun kirjoitetaan välityslokia
3. Yhdistetty palvelin 1 -solmuun, kirjoitti tietueen c1=2, ja myös tapahtumasitoumus palautti onnistumisen.
4. Sitten Mock server1 kaatuu epänormaalisti (konevika, sitä ei voida palauttaa, eikä sitä voida käyttää Tällä hetkellä palvelin 2/3 on jätetty muodostamaan enemmistö).
5. Käynnistä palvelin 2/3 uudelleen normaalisti (nopea palautus), mutta palvelin 2/3 ei voi palauttaa klusteria käyttökelpoiseen tilaan.
6. Muodosta yhteys palvelin 2/3 -solmuun ja tee kysely tietokannan tietueista Vain tietue c1=1 näkyy (palvelin 2/3 on menettänyt c1=2).

Yllä olevan tapauksen mukaan MGR:n tapauksessa, kun suurin osa palvelimista on poissa käytöstä ja päätietokanta ei ole käytettävissä, valmiustilan tietokanta on palautettu, tiedot menetetään RPO<>0 ja onnistuneen toimituksen tietue. alun perin palautettu asiakkaalle on kadonnut.

DN:lle enemmistön saavuttaminen edellyttää, että lokit säilyvät enemmistössä, joten edes yllä olevassa skenaariossa tietoja ei menetetä ja RPO=0 voidaan taata.

3.4 Valmiustilan tietokannan toistoviive

Perinteisessä MySQL:n aktiivisessa valmiustilassa valmiustilatietokanta sisältää yleensä IO-säikeitä ja Apply-säikeitä Paxos-protokollan käyttöönoton jälkeen IO-säie synkronoi pääasiassa valmiustilatietokannan replikointiviiveen riippuu valmiustilatietokannan Apply playbackin kulusta, tässä meistä tulee valmiustilatietokannan toistoviive.

Testaamme sysbenchin avulla oltp_write_only-skenaariota ja valmiustilatietokannan toiston viiveen kestoa alle 100 samanaikaisuuden ja erilaisten tapahtumien lukumäärän.Valmiustilatietokannan toiston viiveaika voidaan määrittää tarkkailemalla performance_schema.replication_applier_status_by_worker-taulukon APPLYING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP-saraketta nähdäkseen, työskentelevätkö jokainen työntekijä reaaliajassa, jotta voidaan määrittää, onko toisinnus päättynyt.
 

Se näkyy testitulostaulukosta:

• Samalla määrällä kirjoitettua dataa DN:n valmiustilatietokannan kaikkien lokien toiston valmistumisaika on paljon parempi kuin MGR:n ajankulutus on vain 3–4 % MGR:stä. Tämä on kriittistä aktiivisen/valmiustilan vaihtamisen oikea-aikaisuuden kannalta.
• Kun kirjoitusten määrä kasvaa, DN:n valmiustilan tietokannan toistolatenssietu MGR:ään verrattuna säilyy edelleen ja on erittäin vakaa.
• Analysoimalla valmiustilatietokannan toistoviiveen syitä MGR:n valmiustilatietokannan toistostrategia ottaa käyttöön group_replication_consistency-arvon EVENTUAL-oletusarvon kanssa, eli RO- ja RW-tapahtumat eivät odota aikaisempien tapahtumien soveltamista ennen suorittamista. Tämä voi varmistaa päätietokannan maksimaalisen kirjoitussuorituskyvyn, mutta valmiustilan tietokannan viive on suhteellisen suuri (uhraamalla valmiustilan tietokannan viive ja RPO=0 vastineeksi päätietokannan tehokkaasta kirjoitussuorituskyvystä, kytkemällä päälle nykyinen rajoittava toiminto MGR voi tasapainottaa suorituskykyä ja valmiustilatietokanta viivästyy, mutta päätietokannan suorituskyky vaarantuu)

3.5 Testin yhteenveto

4. Yhteenveto

Perusteellisen teknisen analyysin ja suorituskyvyn vertailun jälkeenPolarDB-X Itse kehittämällä X-Paxos-protokollalla ja useilla optimoiduilla malleilla DN on osoittanut monia etuja MySQL MGR:ään verrattuna suorituskyvyn, oikeellisuuden, käytettävyyden ja resurssien suhteen. MGR on kuitenkin myös tärkeässä asemassa MySQL-ekosysteemissä , on otettava huomioon erilaiset tilanteet, kuten valmiustilan tietokannan katkokset, konehuoneiden väliset katastrofipalautussuorituskyvyn vaihtelut ja vakaus. Siksi, jos haluat hyödyntää MGR:ää hyvin, sinun on oltava varustettu ammattitaitoisella teknisellä sekä käyttö- ja huoltotiimällä tuki.

Kun PolarDB-X-tallennusmoottorilla on suuria, korkean samanaikaisuuden ja korkean käytettävyyden vaatimuksia, sillä on ainutlaatuisia teknisiä etuja ja erinomainen suorituskyky MGR:ään verrattuna.PolarDB-XDN-pohjaisessa keskitetyssä (vakioversiossa) on hyvä tasapaino toimintojen ja suorituskyvyn välillä, mikä tekee siitä erittäin kilpailukykyisen tietokantaratkaisun.