Home Arrow Icon Knowledge base Arrow Icon Global Arrow Icon Kaip galiu stebėti duomenų migracijos tarp skiautelių progresą MongoDB


Kaip galiu stebėti duomenų migracijos tarp skiautelių progresą MongoDB


Stebint duomenų migracijos tarp skiautelių MongoDB pažangą, reikia suprasti kelis aspektus, kaip „MongoDB“ valdo skaldytus klasterius, balansavimo proceso elgseną ir gabaliukų migracijų sekimo mechanizmus ir bendrą klasterio sveikatą.

„MongoDB Sharding“ paskirsto duomenis per kelias skiauteles, kad palaikytų horizontalų mastelį. Duomenų migracija tarp skiautelių pirmiausia vyksta per gabaliukų migracijas, kurias automatiškai valdo „MongoDB“ balanseris arba gali būti rankiniu būdu suaktyvinami. Šio migracijos proceso stebėjimas yra labai svarbus užtikrinant veiklos, prieinamumo ir subalansuoto duomenų paskirstymo klasteryje.

supratimas „MongoDB Sharding“ ir „Balancer“

„MongoDB“ skaidinimuose duomenys į gabalus. Šie gabaliukai yra paskirstomi per skiauteles pagal „Shard“ raktą. „Balancer“ yra foninis procesas, veikiantis pagrindiniame „Config Server“ replikos rinkinio rinkinyje ir aktyviai stebi duomenų paskirstymą, kad išlaikytų balansą tarp skiautelių. Balanceris nusprendžia, kada ir kuriuos gabaliukus reikia perkelti remiantis konkrečiomis slenksčiais, susijusiais su duomenų dydžio skirtumu tarp skiautelių. Migracija atsiranda siekiant užtikrinti net duomenų paskirstymą ir optimizuoti užklausos našumą.

Balanceris veikia skaidriai, tačiau gali būti sukonfigūruotas arba išjungtas pagal poreikį. Tai kontroliuojamai perkelia gabalus, leisdamas tik vieną migraciją vienu metu vienu metu, kad sumažintų poveikį našumui. Esant didelio disbalanso sąlygoms (pvz., Kai duomenų dydžio skirtumas tarp skiautelių viršija slenkstį pagal numatytuosius nustatymus, tris kartus daugiau nei sukonfigūruotas riekės dydis), migracija suaktyvėja.

Tikrinimo balansavimo ir perkėlimo būsena

Stebėti „Shard Migrations“ eigą, naudingos kelios komandos ir žurnalų patikrinimai:

- sh.status () arba db.printshardingStatus (): Šios komandos pateikia skardos būsenos apžvalgą, įskaitant gabaliuko pasiskirstymą per skiauteles kiekvienai apnuogintai kolekcijai. Nors jie nesuteikia tiesioginio migracijos pažangos procento, jų teikiamas gabaliuko paskirstymo kontekstas gali būti įgaliotinis norint suprasti, kokie yra subalansuoti duomenys ir ar vyksta migracijos.

- „Balancer“ veiklos žurnalai: „Balancer“ registruoja savo veiklą, įskaitant gabaliukų migracijas, „Config Servers“ ir „Mongos“ egzempliorių žurnaluose. Šių žurnalų stebėjimas gali atskleisti, kurie gabaliukai yra migruojami, kartu su jų šaltiniais ir paskirties skiautelėmis bei bet kokiomis klaidomis ar vėlavimais, atsirandančiais migracijos metu.

- Dabartinės migracijos: „MongoDB“ riboja skiautelę iki vienos migracijos vienu metu, tačiau su keliomis skiautelėmis jis gali vykdyti keletą migracijų lygiagrečiai klasteryje (iki pusės skiautelių skaičiaus). Stebėti aktyvią migraciją galima atlikti netiesiogiai apžiūrint balansavimo žurnalus arba naudojant administracines komandas konfigūracijos serveryje, kad pamatytumėte migracijos spynos ir su migracija susijusius skaitiklius.

Stebėjimo komandos ir metrikos

- „BalancerStatus“ komanda: paleisti „sh.getbalancerstate ()` arba apžiūrėti klasterį su komandomis, kurios atskleidžia balansavimo veiklą, padeda išsiaiškinti, ar balanseris yra įjungtas, ar šiuo metu aktyvus.

- „ChunkMigrationLockTimeout“ skaičius: „MongoDB“ seka konkrečią metriką, tokią kaip „ShardingStatistics.countdonormoveChunkLockTimeout“, kad suprastų, ar dėl spynų gali būti nurodytos gabaliukų migracijos, o tai gali reikšti migracijos problemas ar našumo trūkumus.

- „Mongos Connpoolstats“ komanda: Stebėjimas jungčių su skydelėmis, naudojant „db.runcommand“ ({connpoolstats: 1}) iš „Mongos“ egzemplioriaus, padeda patikrinti, ar migracijos padidina ryšio naudojimą ar kliūčių antspaudus ant „Shard“ pradmenų. Ryšio statistika rodo apkrovos pasiskirstymą.

- Stebėjimas Duomenų dydis vienam skiautrui: užklausant „Config“ duomenų bazės „Shard“ metaduomenis, galima patikrinti, kokį skiautelę priskirtų gabaliukų dydis ir skaičius. Didelis neatitikimas rodo nuolatines migracijas ar disbalansą.

rankinės migracijos stebėjimas

Kai rankinės gabaliukų migracijos suaktyvinamos naudojant tokias komandas kaip „movechunk“ arba „moverange“, operacijos blokuoja, kol perkėlimas bus baigtas. Šis sinchroninis elgesys leidžia nedelsiant patvirtinti migracijos sėkmę ar nesėkmę. Tačiau dėl ilgesnių automatinių migracijų, kurias valdo balansatorius, „MongoDB“ neatskleidžia tiesioginio pažangos procento.

Naudojant pakartotinius būsenos patikrinimus per „Sh.Status ()` tarp migracijos etapų, padeda nustatyti pažangą stebint, kaip sumažėja gabalėliai ant šaltinio šarnyro ir padidėjęs tiksliniame šarnyryje.

Įrankiai ir prietaisų skydeliai

„MongoDB Atlas“, valdoma debesies paslauga, teikia perkėlimo pagrindinį ekraną, skirtą migracijai sekti vizualiai, įskaitant jų būseną ir bet kokias istorines migracijas. Ši sąsaja gali padėti stebėti „Atlas“ aplinkoje.

Savarankiškai valdomuose diegimuose administratoriai dažnai nustato stebėjimo prietaisų skydelius, naudodamiesi „MongoDB“ stebėjimo priemonėmis, tokiomis kaip MMS („MongoDB Management Service“) arba trečiųjų šalių įrankiai, kurie analizuoja „MongoDB“ žurnalus ir metriką (pvz., Prometėjas su Grafana). Šios sąrankos gali sekti metriką, susijusią su balansavimo veikla, gabaliukų migracijomis, disko naudojimu ir tinklo pralaidumu, kurie netiesiogiai rodo migracijos eigą.

tvarkyti našlaičių dokumentus ir perskaityti nuoseklumą migracijos metu

Migracijos metu perkeliamosios dalies dokumentai yra nukopijuoti į „Target Shard“ ir, patvirtinus, šaltinio skiautelės dokumentai yra pažymėti kaip našlaičiai, kol sutvarkys. Šis valymo vėlavimas („OrphancLeanupDelaysecs“) yra skirtas užtikrinti, kad nepaveiktų nuolatinių užklausų.

Svarbu stebėti, ar nėra jokių praleistų dokumentų antriniuose skaitymuose, nes antriniai skaitymai migracijos metu gali praleisti dokumentus, jei klausimai apima migruojančius diapazonus. Suvokimas apie tokį elgesį yra būtinas vertinant migracijos pažangą ir skaityti nuoseklumą.

Stebėjimo veiksmų santrauka

1. Patikrinkite „Sharding“ būseną: naudokite „Sh.Status ()“.
2. Patikrinkite balansavimo būseną: Patikrinkite, ar balanseris yra įjungtas ir aktyvus per `sh.getbalancerstate ()`.
3. Monitoriaus žurnalai: stebėkite balansatorių ir su migracija susijusius žurnalus „Mongos“ ir „Config“ serveriuose.
4. „Track Cons“ skaičiavimas: užklausos konfigūracijos duomenų bazės metaduomenų kolekcijos (pvz., „Config.chunks“), kad būtų galima stebėti gabaliukus už skiautelę.
5. Išnagrinėkite ryšio statistiką: Norėdami aptikti neįprastus ryšio smaigalius migracijos metu, naudokite „connpoolstats“.
6. Žiūrėkite migracijos spynos ir metriką: nustatykite migracijos laiką arba užrakto problemas metrikoje.
7. Rankinės komandos: kontroliuojamam migracijai ir sinchroniniam grįžtamąjį ryšį naudokite „movechunk“ arba „moverange“.
8. Sverto stebėjimo įrankiai: naudokite „Atlas“ migracijos ekranus arba pasirinktines stebėjimo prietaisų skydelius.
9. Supraskite migracijos poveikį: našlaičių dokumentų valymo ir galimų antrinių skaitymo neatitikimų sąskaita.

Šiomis priemonėmis administratoriai gali veiksmingai stebėti ir įvertinti duomenų migracijos tarp skiautelių MongoDB pažangą, užtikrindami sklandžios balanso operacijas ir optimizuotą klasterio našumą. Šis stebėjimas yra labai svarbus didelėms grupėms, kuriose migracijos gali užtrukti daug laiko ir tinklo pralaidumo, tiesiogiai paveikdamos programos našumą ir prieinamumą.