Rick Golba je inžinier riešení v spoločnosti Percona.
MongoDB je obľúbená databáza pre vývojárov. Ako možnosť NoSQL databázy poskytuje vývojárom databázové prostredie, ktoré má flexibilný návrh schémy, automatické prepnutie po zlyhaní a vstupný jazyk známy pre vývojárov, konkrétne JSON.
Existuje veľa rôznych typov databáz NoSQL. Obchody s kľúčom a hodnotou ukladajú a načítajú každú položku pomocou jej názvu (známeho tiež ako kľúč). Úložiská širokých stĺpcov sú druhom úložiska kľúč - hodnota, ktoré používa stĺpce a riadky (podobne ako relačná databáza), môžu sa líšiť iba názvy stĺpcov a riadkov v tabuľke. Databázy grafov používajú štruktúry grafov na ukladanie sietí údajov. Dokumentárne orientované databázy ukladajú údaje ako dokumenty, čo poskytuje väčšiu štrukturálnu flexibilitu ako iné databázy.
MongoDB je dokumentovo orientovaná databáza. Je to multiplatformová databáza, ktorá uchováva údaje v dokumentoch v binárne kódovanom formáte JSON (známy ako binárny JSON alebo BSON). Binárny formát zvyšuje rýchlosť a flexibilitu JSON a pridáva ďalšie dátové typy.
Replikačné mechanizmy MongoDB pomáhajú zabezpečiť vysokú dostupnosť a jeho mechanizmus rozdelenia umožňuje horizontálnu škálovateľnosť. Mnoho špičkových internetových spoločností ako Facebook a eBay používa MongoDB vo svojom databázovom prostredí.
Prečo monitorovať MongoDB?
Vaše databázové prostredie MongoDB môže byť jednoduché alebo komplikované, lokálne alebo distribuované, lokálne alebo v cloude. Ak chcete zabezpečiť výkonnú a dostupnú databázu, mali by ste sledovať a monitorovať analytiku s cieľom:
- Zistite aktuálny stav databázy
- Skontrolujte údaje o výkone a identifikujte akékoľvek neobvyklé správanie
- Poskytnite diagnostické údaje na vyriešenie zistených problémov
- Opravte malé problémy skôr, ako z nich vyrastú väčšie problémy
- Udržujte svoje prostredie v prevádzke a bez problémov
- Zaistite nepretržitú dostupnosť a úspech
Monitorovanie vášho databázového prostredia merateľným a pravidelným spôsobom zaručuje, že zistíte akékoľvek nezrovnalosti, zvláštne správanie alebo problémy skôr, ako ovplyvnia výkon. Správne sledovanie znamená, že môžete rýchlo spoznať spomalenie, obmedzenie zdrojov alebo iné aberantné správanie a tieto problémy vyriešiť skôr, ako vás postihnú následky pomalých webových stránok a aplikácií, nedostupných údajov alebo frustrovaných zákazníkov.
Čo by sme mali sledovať?
V prostredí MongoDB môžete sledovať veľa vecí, ale niekoľko kľúčových oblastí vás rýchlo upozorní, ak niečo nie je v poriadku. Mali by ste analyzovať nasledujúce metriky:
- Oneskorenie replikácie. Oneskorenie replikácie sa týka oneskorenia pri kopírovaní údajov z primárneho uzla do sekundárneho uzla.
- Štát repliky. Stav repliky je metóda sledovania, či sekundárne uzly zomreli a či došlo k voľbe nového primárneho uzla.
- Zamykací stav. Stav uzamknutia ukazuje, aké dátové zámky sú nastavené, a čas, ktorý boli v platnosti.
- Využitie disku. Využitie disku sa týka prístupu na disk.
- Využitie pamäte. Využitie pamäte sa vzťahuje na to, koľko pamäte sa používa a ako sa používa.
- Počet pripojení. Počet pripojení, ktoré má databáza otvorená, aby mohla vybavovať požiadavky čo najrýchlejšie.
Poďme sa venovať niektorým podrobnostiam.
Oneskorenie replikácie
MongoDB používa replikáciu na splnenie výziev a cieľov v oblasti dostupnosti. Replikácia je šírenie údajov z primárneho uzla do viacerých sekundárnych uzlov, pretože operácie na primárnom uzle menia údaje. Tieto uzly môžu byť umiestnené spoločne, na rôznych geografických miestach alebo virtuálne.
Ak je všetko rovnaké, replikácia dát by mala prebiehať rýchlo a bez problémov. Môže sa stať veľa vecí, ktoré zastaví plynulý priebeh procesu replikácie. Aj za najlepších podmienok obmedzujú fyzikálne vlastnosti siete rýchlosť replikácie údajov. Oneskorenie medzi spustením replikácie a jej dokončením sa označuje ako oneskorenie replikácie.
V hladko fungujúcej sade primárnych a sekundárnych uzlov (označovaných ako „sada replík“) sekundárne súbory rýchlo kopírujú zmeny na primárnom serveri a replikujú každú skupinu operácií z oplogu tak rýchlo, ako sa vyskytujú (alebo čo najbližšie) . Cieľom je udržať oneskorenie replikácie blízko nuly. Údaje načítané z ktoréhokoľvek uzla by mali byť konzistentné. Ak zvolený primárny uzol zlyhá alebo sa stane inak nedostupným, sekundárny môže prevziať primárnu rolu bez ovplyvnenia presnosti údajov pre klientov. Replikované údaje by mali byť v súlade s primárnymi údajmi pred poklesom primárnej hodnoty.
Oneskorenie replikácie je dôvod, prečo sa primárny a sekundárny uzol synchronizujú. Ak je sekundárny uzol zvolený za primárny a oneskorenie replikácie je vysoké, potom môže byť sekundárna verzia údajov zastaraná. Stav zvýšeného oneskorenia replikácie môže nastať z niekoľkých nestálych alebo nedefinovaných dôvodov a môže sa sám opraviť. Ak však oneskorenie replikácie zostane vysoké alebo sa začne pravidelne zvyšovať, je to známka systémového alebo environmentálneho problému. V obidvoch prípadoch platí, že čím je oneskorenie replikácie väčšie - a čím dlhšie zostáva vysoké - tým viac hrozí, že vaše dáta budú pre klientov zastarané.
Existuje iba jeden spôsob, ako analyzovať túto metriku: monitorovať ju! Toto je metrika, ktorá by mala byť monitorovaná 24x7x365, takže je najlepšie ju vykonať pomocou automatizácie a upozornení na spúšťanie, aby ste varovali správcov databáz alebo správcov systémov odpovedí, akonáhle dosiahnu nežiaduci prah. Konfigurácia tohto limitu závisí od tolerancie vašej aplikácie k oneskoreniu replikácie. Na určenie správnej prahovej hodnoty použite nástroj, ktorý grafy oneskoruje v priebehu času, napríklad Compass, MongoBooster, Studio 3T alebo Percona Monitoring and Management (PMM).
Štát repliky
Replikácia sa vybavuje prostredníctvom replík. Sada replík je sada uzlov so zvoleným primárnym uzlom a niekoľkými sekundárnymi uzlami. Primárny uzol je správcom najaktuálnejších údajov a tieto údaje sa replikujú do sekundárnych súborov, keď sa v primárnom systéme urobia zmeny.
Normálne je jeden člen sady replík primárny a všetci ostatní členovia sú sekundárni. Priradený stav sa zriedka mení. Ak sa tak stane, chceme o tom vedieť (zvyčajne okamžite). Zmena roly sa zvyčajne deje rýchlo a zvyčajne bezproblémovo, je však potrebné presne pochopiť, prečo sa stav uzla zmenil, pretože to mohlo byť spôsobené zlyhaním hardvéru alebo siete. Prepínanie medzi primárnym a sekundárnym stavom (tiež známe ako mávanie klapkami) nie je bežnou záležitosťou a v dokonalom svete by sa malo diať iba zo známych dôvodov (napríklad počas údržby prostredia, ako je napríklad aktualizácia softvéru alebo hardvéru, alebo počas konkrétneho incidentu, ako je napríklad ako výpadok siete).
Zamykací stav
Databázy sú veľmi súbežné a nestále prostredia. Viacero klientov zadáva požiadavky a iniciuje transakcie, ktoré sa na údajoch vykonávajú. Tieto žiadosti a transakcie sa neuskutočňujú postupne alebo v racionálnom poradí. Môžu nastať konflikty - napríklad ak sa transakcie pokúsia aktualizovať ten istý záznam alebo dokument, ak počas aktualizácie údajov dôjde k požiadavke na čítanie atď. Mnoho databáz sa zaoberá zaistením toho, že k údajom je organizovaný prístup, je „zamykanie“. “ Uzamknutie nastane, keď transakcia zabráni tomu, aby sa databázový záznam, dokument, riadok, tabuľka atď. Zmenili alebo prečítali, kým sa aktuálna transakcia nespracuje.
V MongoDB sa zamykanie vykonáva na úrovni kolekcie alebo dokumentu, aby sa zabránilo konfliktom medzi súbežnými transakciami. Niektoré operácie môžu tiež vyžadovať globálny zámok databázy (napríklad pri vynechaní kolekcie). Ak dôjde k uzamknutiu príliš často, ovplyvní to výkon uskutočňovaním transakcií (vrátane čítaní), ktoré čakajú na sprístupnenie uzamknutých častí databázy na čítanie alebo úpravy. Vysoké percento uzamknutia je znakom ďalších problémov v databáze: zlyhanie hardvéru, zlý dizajn schémy, zle nakonfigurované indexy, nepoužívanie indexov atď.
Je dôležité sledovať percento blokovania. Mali by ste vedieť, aké prijateľné percento je z hľadiska výkonu a ako dlho je možné toto percento udržať pred ovplyvnením výkonu. Ak sa výkon príliš zníži z dôvodu vysokého percenta uzamknutia, môže to spustiť zmenu stavu replikácie prostredníctvom nereagovania servera.
Využitie disku
Každý správca databáz by mal monitorovať dostupné miesto na disku na svojich databázových serveroch. Akonáhle databáza vyčerpá diskový priestor na hostiteľovi, server sa náhle zastaví. Proaktívne dimenzovanie údajov a sledovanie veľkostí súborov denníka sú vynikajúcimi technikami pre dimenzovanie databázy.
Možno bude potrebné, aby sa vaša databáza automaticky rozšírila. V týchto prípadoch musíte zaručiť, že to neprerastie hardvér. Pravidelná kontrola miesta na disku vám môže pomôcť zabrániť neočakávaným zastaveniam databázového servera a tiež vyhľadať problémy so zlým dizajnom (napríklad dotazy vyžadujúce úplné skenovanie zbierky).
Využitie pamäte
Uchovávanie všetkých údajov v pamäti RAM urýchľuje časy odozvy databázy. Čo to však znamená a ako viete, keď je niečo v pamäti RAM?
Spôsob, akým vaša databáza využíva pamäť, môže byť trochu nejasný. Veľká časť pamäte, ktorú server používa, je na oblasť vyrovnávacej pamäte (dáta). Môže byť ťažké zistiť, ktorá databáza využíva najväčšiu časť pamäte vyrovnávacej pamäte, a ešte ťažšie je zistiť, ktoré kolekcie alebo dokumenty sa v skutočnosti nachádzajú v pamäti vyrovnávacej pamäte. Poznanie týchto informácií je užitočné pri vyvažovaní záťaže vašej databázy medzi viacerými servermi (prostredníctvom zdieľania) alebo pri identifikácii údajov, ktoré sú optimálne na konsolidáciu do jednej inštancie servera.
Používanie nástrojov na určenie, ktoré inštancie najviac využívajú pamäť a na aké údaje, vám môžu pomôcť optimalizovať vaše prostredie.
Počet pripojení
Transakcie databázy sú zvyčajne iniciované aplikáciami a procesmi prostredníctvom „pripojení“. Počet otvorených pripojení môže mať vplyv na výkon databázy. Teoreticky by sa malo spojenie ukončiť po dokončení transakcie. V praxi však veľa spojení zostane otvorených. Je normálne, že databáza udržiava niektoré spojenia nažive, aby uľahčila určité transakcie, ale ak ich príliš veľa zostane otvorených, môže to obmedziť počet dostupných v oblasti pripojení.
Ako osvedčený postup by mala databáza udržiavať spojenie otvorené po čo najmenší čas potrebný na dokončenie žiadosti. To umožňuje malej skupine pripojení obsluhovať obrovské množstvo požiadaviek na transakcie. V opačnom prípade sa žiadosti o transakciu aplikácie zaseknú pri čakaní na otvorené pripojenie. Musíte monitorovať počet otvorených pripojení v databáze, aby ste overili, či sa zatvárajú a či vo fonde zostáva zdravý počet pripojení pre prichádzajúce požiadavky.
Nástroje poskytované s MongoDB
Teraz, keď vieme, čo by sme mali sledovať, je ďalšia otázka ako? Našťastie MongoDB prichádza s niekoľkými ľahko použiteľnými nástrojmi na sledovanie štatistík servera.
mongostat
Tento nástroj poskytuje globálne štatistické údaje o využití pamäte, stave sady replík a ďalšie informácie aktualizované každú sekundu (predvolené nastavenie).
The mongostat vám poskytne prehľad o inštancii servera MongoDB. Ak máte spustenú jednu inštanciu „mongod“, zobrazí sa štatistika tejto jednej inštancie. Ak používate klastrové prostredie MongoDB, vráti štatistiku inštancie „mongos“. mongostat sa najlepšie používa na sledovanie jednej inštancie pre konkrétnu udalosť (napríklad čo sa stane, keď príde požiadavka na konkrétnu aplikáciu). Tento príkaz môžete použiť na sledovanie základných štatistík servera:
- CPU
- Pamäť
- Disk IO
- Sieťová prevádzka
Prečítajte si dokumentáciu k MongoDB na mongostat pre bližšie informácie o použití.
mongotop
Tento nástroj poskytuje štatistiku o aktivite čítania a zápisu na úrovni zbierky.
The mongotop príkaz sleduje čas potrebný na dokončenie operácií čítania a zápisu na inštancii servera MongoDB. Poskytuje štatistiku na úrovni jednotlivých zbierok. mongotop predvolene vracia hodnoty každú sekundu, ale časový rámec môžete podľa potreby upraviť.
Všetky metriky za sekundu sú relatívne k konfigurácii vášho servera, ako aj k architektúre klastra. Pre jednotlivé inštancie spustené lokálne a pomocou predvoleného portu stačí zadať mongotop príkaz. Ak pracujete v klastrovanom prostredí s viacerými inštanciami mongod a mongos, budete musieť pomocou príkazu zadať názov hostiteľa a číslo portu.
Prečítajte si dokumentáciu k MongoDB na mongotop pre bližšie informácie o použití.
rs.status ()
Tento príkaz poskytuje stav sady replík.
Môžete použiť rs.status () príkaz na získanie informácií o spustenej replike. Tento príkaz je možné spustiť z konzoly ľubovoľného člena ľubovoľnej množiny a vráti stav množiny replík, ako ho vidí dotyčný člen.
Prečítajte si dokumentáciu k MongoDB na rs.status () pre bližšie informácie o použití.
