Prepis prednášky Brucea Momjiana z roku 2020 „Odomknutie správcu zámku Postgres“.
(Poznámka: Všetky SQL dotazy zo snímok je možné získať z tohto odkazu: )
Ahoj! Je skvelé byť opäť tu v Rusku. Je mi ľúto, že som nemohol prísť minulý rok, ale tento rok máme s Ivanom veľké plány. Dúfam, že tu budem oveľa častejšie. Rád prichádzam do Ruska. Navštívim Tyumen, Tver. Som veľmi rád, že tieto mestá budem môcť navštíviť.
Volám sa Bruce Momjian. Pracujem v EnterpriseDB a s Postgres spolupracujem už viac ako 23 rokov. Bývam vo Philadelphii, USA. Cestujem asi 90 dní v roku. A zúčastňujem sa asi 40 konferencií. môj , ktorý obsahuje snímky, ktoré vám teraz ukážem. Preto si ich po konferencii môžete stiahnuť z mojej osobnej webovej stránky. Obsahuje tiež asi 30 prezentácií. Sú tam aj videá a veľké množstvo blogových príspevkov, viac ako 500. Ide o pomerne informatívny zdroj. A ak máte záujem o tento materiál, potom vás pozývam, aby ste ho použili.
Predtým, ako som začal spolupracovať s Postgresom, som bol učiteľom, profesorom. A som veľmi rád, že vám teraz budem môcť povedať to, čo sa vám chystám povedať. Toto je jedna z mojich najzaujímavejších prezentácií. A táto prezentácia obsahuje 110 snímok. Začneme hovoriť o jednoduchých veciach a ku koncu bude správa čoraz zložitejšia a bude pomerne zložitá.
Toto je dosť nepríjemný rozhovor. Blokovanie nie je najobľúbenejšou témou. Chceme, aby to niekam zmizlo. Je to ako ísť k zubárovi.
- Zamykanie je problémom pre veľa ľudí, ktorí pracujú v databázach a majú spustených viacero procesov súčasne. Potrebujú blokovanie. To znamená, že dnes vám poskytnem základné znalosti o blokovaní.
- ID transakcií. Toto je dosť nudná časť prezentácie, ale treba im porozumieť.
- Ďalej budeme hovoriť o typoch blokovania. Toto je pomerne mechanická časť.
- A nižšie uvedieme niekoľko príkladov blokovania. A bude to dosť ťažké pochopiť.
Hovorme o blokovaní.
Naša terminológia je dosť zložitá. Koľkí z vás vedia, odkiaľ pochádza táto pasáž? Dvaja ľudia. Toto je z hry s názvom Colossal Cave Adventure. Myslím, že to bola textová počítačová hra v 80. rokoch. Tam ste museli ísť do jaskyne, do labyrintu a text sa zmenil, ale obsah bol zakaždým približne rovnaký. Takto si pamätám túto hru.
A tu vidíme názov zámkov, ktoré k nám prišli od spoločnosti Oracle. Používame ich.
Tu vidíme pojmy, ktoré ma mätú. Napríklad SHARE UPDATE ECXLUSIVE. Ďalej ZDIEĽAJ RAW ECXLUSIVE. Úprimne povedané, tieto mená nie sú príliš jasné. Pokúsime sa ich zvážiť podrobnejšie. Niektoré obsahujú slovo „zdieľať“, čo znamená oddeliť sa. Niektoré obsahujú slovo „exkluzívny“. Niektoré obsahujú obe tieto slová. Chcel by som začať tým, ako fungujú tieto zámky.
A slovo „prístup“ je tiež veľmi dôležité. A slová „riadok“ sú reťazec. Teda distribúcia prístupu, distribúcia riadkov.
Ďalším problémom, ktorý je potrebné pochopiť v Postgrese, ktorý bohužiaľ nebudem môcť pokryť v mojej prednáške, je MVCC. Na túto tému mám na svojom webe samostatnú prezentáciu. A ak si myslíte, že táto prezentácia je náročná, MVCC je pravdepodobne moja najťažšia. A ak máte záujem, môžete si ho pozrieť na stránke. Môžete si pozrieť video.
Ďalšia vec, ktorú musíme pochopiť, sú ID transakcií. Mnoho transakcií nemôže fungovať bez jedinečných identifikátorov. A tu máme vysvetlenie, čo je to transakcia. Postgres má dva systémy číslovania transakcií. Viem, že to nie je veľmi pekné riešenie.
Majte tiež na pamäti, že snímky budú dosť ťažko pochopiteľné, takže to, čo je zvýraznené červenou farbou, musíte venovať pozornosť.
Pozrime sa. Číslo transakcie je zvýraznené červenou farbou. Tu je zobrazená funkcia SELECT pg_back. Vráti moju transakciu a ID transakcie.
Ešte jedna vec, ak sa vám táto prezentácia páči a chcete ju spustiť vo svojej databáze, môžete prejsť na tento odkaz v ružovej farbe a stiahnuť si SQL pre túto prezentáciu. A môžete ho jednoducho spustiť vo svojom PSQL a celá prezentácia bude okamžite na obrazovke. Nebude obsahovať kvety, ale aspoň to vidíme.
V tomto prípade vidíme ID transakcie. Toto je číslo, ktoré sme jej pridelili. A v Postgrese existuje ďalší typ ID transakcie, ktorý sa nazýva virtuálne ID transakcie
A toto musíme pochopiť. Toto je veľmi dôležité, inak nebudeme schopní pochopiť zamykanie v Postgrese.
ID virtuálnej transakcie je ID transakcie, ktoré neobsahuje trvalé hodnoty. Ak napríklad spustím príkaz SELECT, tak databázu s najväčšou pravdepodobnosťou nezmením, nič nezamknem. Takže keď spustíme jednoduchý SELECT, nedávame tejto transakcii trvalé ID. Tam jej dávame len virtuálnu legitimáciu.
A to zlepšuje výkon Postgres, zlepšuje možnosti čistenia, takže ID virtuálnej transakcie pozostáva z dvoch čísel. Prvé číslo pred lomkou je ID servera. A na pravej strane vidíme len pult.
Preto, ak spustím požiadavku, zobrazí sa, že ID backendu je 2.
A ak spustím sériu takýchto transakcií, potom vidíme, že počítadlo sa zvyšuje vždy, keď spustím dotaz. Napríklad, keď spustím dotaz 2/10, 2/11, 2/12 atď.
Majte na pamäti, že tu sú dva stĺpce. Vľavo vidíme ID virtuálnej transakcie – 2/12. A na pravej strane máme trvalé ID transakcie. A toto pole je prázdne. A táto transakcia nemodifikuje databázu. Nedávam mu teda trvalé ID transakcie.
Hneď ako spustím príkaz analýzy ((ANALYZE)), rovnaký dotaz mi poskytne trvalé ID transakcie. Pozrite sa, ako sa to u nás zmenilo. Predtým som toto ID nemal, ale teraz ho mám.
Takže tu je ďalšia žiadosť, ďalšia transakcia. Číslo virtuálnej transakcie je 2/13. A ak požiadam o trvalé ID transakcie, potom keď spustím dotaz, dostanem ho.
Takže ešte raz. Máme virtuálne ID transakcie a trvalé ID transakcie. Stačí pochopiť tento bod, aby ste pochopili správanie Postgres.
Prejdeme k tretej časti. Tu jednoducho prejdeme rôznymi typmi zámkov v Postgres. Nie je to veľmi zaujímavé. Posledná časť bude oveľa zaujímavejšia. Musíme však zvážiť základné veci, pretože inak nepochopíme, čo bude ďalej.
Prejdeme si túto časť, pozrieme sa na každý typ zámku. A ukážem vám príklady, ako sa inštalujú, ako fungujú, ukážem vám niekoľko dotazov, pomocou ktorých môžete vidieť, ako funguje zamykanie v Postgrese.
Ak chcete vytvoriť dotaz a zistiť, čo sa deje v Postgrese, musíme dotaz zadať v systémovom zobrazení. V tomto prípade je pg_lock zvýraznený červenou farbou. Pg_lock je systémová tabuľka, ktorá nám hovorí, aké zámky sa momentálne používajú v Postgrese.
Je však pre mňa veľmi ťažké ukázať vám pg_lock samotný, pretože je dosť zložitý. Tak som vytvoril pohľad, ktorý ukazuje pg_locks. A tiež to pre mňa robí nejakú prácu, ktorá mi umožňuje lepšie porozumieť. To znamená, že vylučuje moje zámky, moju vlastnú reláciu atď. Je to len štandardné SQL a umožňuje vám lepšie ukázať, čo sa deje.
Ďalším problémom je, že tento pohľad je veľmi široký, takže musím vytvoriť druhý - lockview2.
A zobrazuje mi viac stĺpcov z tabuľky. A ešte jeden, ktorý mi ukazuje zvyšok stĺpcov. Je to dosť zložité, preto som sa to snažil podať čo najjednoduchšie.
Tak sme vytvorili tabuľku s názvom Lockdemo. A vytvorili sme tam jednu líniu. Toto je naša vzorová tabuľka. A budeme vytvárať sekcie len preto, aby sme vám ukázali príklady zámkov.
Takže jeden riadok, jeden stĺpec. Prvý typ zámku sa nazýva ACCESS SHARE. Toto je najmenej obmedzujúce blokovanie. To znamená, že prakticky nie je v rozpore s inými zámkami.
A ak chceme explicitne definovať zámok, spustíme príkaz „lock table“. A evidentne sa zablokuje, t.j. v režime ACCESS SHARE spustíme tabuľku zámkov. A ak spustím PSQL na pozadí, potom začnem druhú reláciu z mojej prvej relácie týmto spôsobom. To znamená, čo tu budem robiť? Idem na inú reláciu a poviem jej "ukážte mi zobrazenie zámku pre túto požiadavku." A tu mám v tejto tabuľke AccessShareLock. Presne toto som žiadal. A hovorí, že blok je pridelený. Veľmi jednoduché.
Ďalej, ak sa pozrieme na druhý stĺpec, potom tam nič nie je. Sú prázdne.
A ak spustím príkaz "SELECT", potom je to implicitný (explicitný) spôsob, ako požiadať o AccessShareLock. Takže uvoľním svoju tabuľku a spustím dotaz a dotaz vráti viacero riadkov. A v jednom z riadkov vidíme AccessShareLock. SELECT teda volá AccessShareLock na stole. A prakticky s ničím nekoliduje, pretože ide o zámok nízkej úrovne.
Čo ak spustím SELECT a mám tri rôzne tabuľky? Predtým som spúšťal iba jednu tabuľku, teraz mám spustené tri: pg_class, pg_namespace a pg_attribute.
A teraz, keď sa pozriem na dotaz, vidím 9 AccessShareLock v troch tabuľkách. prečo? Tri tabuľky sú zvýraznené modrou farbou: pg_attribute, pg_class, pg_namespace. Môžete však tiež vidieť, že všetky indexy, ktoré sú definované prostredníctvom týchto tabuliek, majú tiež AccessShareLock.
A to je zámok, ktorý prakticky nie je v rozpore s ostatnými. A všetko, čo robí, je jednoducho zabrániť nám v resetovaní tabuľky, kým ju vyberieme. To dáva zmysel. To znamená, že ak vyberieme tabuľku, v tom momente zmizne, potom je to nesprávne, takže AccessShare je zámok nízkej úrovne, ktorý nám hovorí „nezahadzujte túto tabuľku, keď pracujem“. V podstate to je všetko, čo robí.
PODIEL RIADKOV - Tento zámok je trochu iný.
Vezmime si príklad. SELECT ROW SHARE spôsob uzamknutia každého riadku jednotlivo. Takto ich nikto nemôže vymazať ani zmeniť, kým ich sledujeme.
Čo teda robí SHARE LOCK? Vidíme, že ID transakcie je 681 pre SELECT. A toto je zaujímavé. Čo sa tu stalo? Prvýkrát, keď číslo vidíme, je v poli „Uzamknúť“. Berieme ID transakcie a hovorí, že ju blokuje vo výhradnom režime. Všetko, čo robí, je, že hovorí, že mám riadok, ktorý je technicky uzamknutý niekde v tabuľke. Nehovorí však, kde presne. Pozrieme sa na to podrobnejšie o niečo neskôr.
Tu hovoríme, že zámok používame my.
Takže exkluzívny zámok výslovne hovorí, že je exkluzívny. A tiež, ak vymažete riadok v tejto tabuľke, stane sa to, ako vidíte.
SHARE EXCLUSIVE je dlhší zámok.
Toto je príkaz analyzátora (ANALYZE), ktorý sa použije.
SHARE LOCK – môžete explicitne uzamknúť v režime zdieľania.
Môžete tiež vytvoriť jedinečný index. A tam môžete vidieť SHARE LOCK, ktorý je ich súčasťou. A zamkne stôl a umiestni naň SHARE LOCK.
V predvolenom nastavení SHARE LOCK na tabuľke znamená, že iní ľudia môžu čítať tabuľku, ale nikto ju nemôže upravovať. A to je presne to, čo sa stane, keď vytvoríte jedinečný index.
Ak vytvorím jedinečný súbežný index, budem mať iný typ uzamykania, pretože, ako si pamätáte, použitie súbežných indexov znižuje požiadavku na uzamykanie. A ak použijem normálny zámok, normálny index, tak zabránim zápisu do indexu tabuľky pri jeho vytváraní. Ak používam súbežný index, musím použiť iný typ uzamknutia.
SHARE ROW EXCLUSIVE – opäť je možné nastaviť explicitne (explicitne).
Alebo môžeme vytvoriť pravidlo, t.j. zobrať konkrétny prípad, v ktorom sa použije.
EXKLUZÍVNE uzamykanie znamená, že nikto iný nemôže zmeniť stôl.
Tu vidíme rôzne typy zámkov.
ACCESS EXCLUSIVE je napríklad blokovací príkaz. Napríklad, ak áno CLUSTER table, potom to bude znamenať, že tam nikto nebude môcť písať. A uzamkne nielen samotnú tabuľku, ale aj indexy.
Toto je druhá stránka blokovania PRÍSTUPU EXCLUSIVE, kde v tabuľke vidíme, čo presne blokuje. Zamyká jednotlivé riadky tabuľky, čo je celkom zaujímavé.
To sú všetky základné informácie, ktoré som chcel uviesť. Hovorili sme o zámkoch, o ID transakcií, hovorili sme o ID virtuálnych transakcií, o trvalých ID transakcií.
A teraz si prejdeme niekoľko príkladov blokovania. Toto je najzaujímavejšia časť. Pozrieme sa na veľmi zaujímavé prípady. A mojím cieľom v tejto prezentácii je poskytnúť vám lepšie pochopenie toho, čo vlastne Postgres robí, keď sa snaží blokovať určité veci. Myslím, že je veľmi dobrý v blokovaní častí.
Pozrime sa na niekoľko konkrétnych príkladov.
Začneme tabuľkami a jedným riadkom v tabuľke. Keď niečo vložím, na stole sa zobrazí ExclusiveLock, Transaction ID a ExclusiveLock.
Čo sa stane, ak vložím ďalšie dva riadky? A teraz má naša tabuľka tri riadky. A vložil som jeden riadok a dostal som to ako výstup. A ak vložím ďalšie dva riadky, čo je na tom divné? Je tu zvláštnosť, pretože som do tejto tabuľky pridal tri riadky, ale stále mám dva riadky v tabuľke zámkov. A to je v podstate základné správanie Postgresu.
Mnoho ľudí si myslí, že ak v databáze uzamknete 100 riadkov, budete musieť vytvoriť 100 položiek zámku. Ak naraz zablokujem 1 000 riadkov, potom budem potrebovať 1 000 takýchto dopytov. A ak potrebujem milión alebo miliardu na zablokovanie. Ale ak to urobíme, nebude to fungovať dobre. Ak ste použili systém, ktorý vytvára blokovacie položky pre každý jednotlivý riadok, potom môžete vidieť, že je to komplikované. Pretože potrebujete okamžite definovať tabuľku zámkov, ktorá môže pretekať, ale Postgres to nerobí.
A čo je na tejto snímke naozaj dôležité, je to, že jasne ukazuje, že vo vnútri MVCC beží ďalší systém, ktorý zamyká jednotlivé riadky. Takže keď zamknete miliardy riadkov, Postgres nevytvorí miliardu samostatných zamykacích príkazov. A to má veľmi dobrý vplyv na produktivitu.
A čo aktualizácia? Riadok teraz aktualizujem a môžete vidieť, že vykonal dve rôzne operácie naraz. Zároveň zamkol tabuľku, ale zamkol aj index. A potreboval uzamknúť index, pretože v tejto tabuľke sú jedinečné obmedzenia. A chceme sa uistiť, že to nikto nezmení, preto to blokujeme.
Čo sa stane, ak chcem aktualizovať dva riadky? A vidíme, že sa správa rovnako. Vykonávame dvakrát toľko aktualizácií, ale presne rovnaký počet uzamykacích liniek.
Ak vás zaujíma, ako to Postgres robí, budete si musieť vypočuť moje rozhovory o MVCC, aby ste sa dozvedeli, ako Postgres interne označuje tieto riadky, že sa to mení. A Postgres má spôsob, akým to robí, ale nerobí to na úrovni uzamknutia stola, ale na nižšej a efektívnejšej úrovni.
Čo ak chcem niečo vymazať? Ak vymažem napríklad jeden riadok a stále mám svoje dva blokovacie vstupy a aj keď ich chcem vymazať všetky, stále tam sú.
A napríklad chcem vložiť 1 000 riadkov a potom buď vymazať alebo pridať 1 000 riadkov, potom tie jednotlivé riadky, ktoré pridám alebo zmením, sa tu nezaznamenajú. Sú napísané na nižšej úrovni v rámci samotnej série. A počas prejavu MVCC som o tom podrobne hovoril. Pri analýze zámkov je však veľmi dôležité, aby ste sa uistili, že sa zamykáte na úrovni tabuľky a že nevidíte, ako sa tu zaznamenávajú jednotlivé riadky.
A čo explicitné blokovanie?
Ak kliknem na obnoviť, mám uzamknuté dva riadky. A ak ich vyberiem všetky a kliknem na „aktualizovať všade“, stále mám dva blokujúce záznamy.
Nevytvárame samostatné záznamy pre každý jednotlivý riadok. Pretože potom produktivita klesá, môže jej byť priveľa. A môžeme sa ocitnúť v nepríjemnej situácii.
A to isté, ak zdieľame, môžeme to urobiť 30-krát.
Obnovíme našu tabuľku, vymažeme všetko a potom znova vložíme jeden riadok.
Ďalšie správanie, ktoré vidíte v Postgres a ktoré je veľmi dobre známe a žiadané, je, že môžete vykonať aktualizáciu alebo výber. A môžete to urobiť súčasne. A vyberte neblokuje aktualizáciu a to isté v opačnom smere. Hovoríme čitateľovi, aby neblokoval pisateľa, a pisateľ neblokoval čitateľa.
Ukážem vám to na príklade. Teraz si vyberiem. Potom urobíme INSERT. A potom môžete vidieť - 694. Môžete vidieť ID transakcie, ktorá vykonala toto vloženie. A takto to funguje.
A keď sa teraz pozriem na svoje ID koncového zariadenia, teraz je to 695.
A vidím, že sa v mojej tabuľke objavuje 695.
A ak tu aktualizujem takto, dostanem iný prípad. V tomto prípade je 695 exkluzívny zámok a aktualizácia má rovnaké správanie, ale medzi nimi nie je žiadny konflikt, čo je dosť nezvyčajné.
A môžete vidieť, že v hornej časti je to ShareLock a v dolnej časti je to ExclusiveLock. A obe transakcie vyšli.
A musíte si vypočuť moju prednášku na MVCC, aby ste pochopili, ako sa to deje. Ale toto je ilustrácia toho, že to môžete urobiť súčasne, t. j. urobiť SELECT a UPDATE súčasne.
Poďme resetovať a urobiť ešte jednu operáciu.
Ak sa pokúsite spustiť dve aktualizácie súčasne v rovnakom riadku, bude zablokovaný. A pamätajte, povedal som, že čitateľ neblokuje pisateľa a pisateľ neblokuje čitateľa, ale jeden pisateľ blokuje iného pisateľa. To znamená, že nemôžeme nechať dvoch ľudí aktualizovať ten istý riadok v rovnakom čase. Musíte počkať, kým jeden z nich skončí.
A aby som to ilustroval, pozriem sa na tabuľku Lockdemo. A pozrieme sa na jeden riadok. Za transakciu 698.
Aktualizovali sme to na 2. 699 je prvá aktualizácia. A bola úspešná alebo je v čakajúcej transakcii a čaká na naše potvrdenie alebo zrušenie.
Ale pozrite sa na niečo iné - 2/51 je naša prvá transakcia, naša prvá relácia. 3/112 je druhá požiadavka, ktorá prišla zhora a ktorá zmenila túto hodnotu na 3. A ak si všimnete, horná sa zamkla sama, čo je 699. Ale 3/112 zámok neudelil. Stĺpec Lock_mode hovorí, na čo čaká. Očakáva 699. A ak sa pozriete, kde je 699, je to vyššie. A čo urobilo prvé sedenie? Vytvorila exkluzívny zámok na svojom vlastnom ID transakcie. Takto to robí Postgres. Blokuje svoje vlastné ID transakcie. A ak chcete čakať, kým to niekto potvrdí alebo zruší, musíte počkať, kým bude prebiehať transakcia. A preto môžeme vidieť zvláštnu líniu.
Pozrime sa znova. Vľavo vidíme naše ID spracovania. V druhom stĺpci vidíme naše ID virtuálnej transakcie a v treťom vidíme lock_type. Čo to znamená? V podstate to hovorí, že blokuje ID transakcie. Všimnite si však, že všetky riadky v spodnej časti uvádzajú vzťah. A tak máte na stole dva typy zámkov. Existuje vzťahový zámok. A potom je tu blokovanie id transakcie, kde sa blokujete sami, čo je presne to, čo sa deje v prvom riadku alebo úplne dole, kde je id transakcie, kde čakáme, kým 699 dokončí svoju operáciu.
Uvidím, čo sa tu stane. A tu sa dejú dve veci súčasne. Pozeráte sa na zámok ID transakcie v prvom riadku, ktorý sa uzamkne. A blokuje sa, aby nechala ľudí čakať.
Ak sa pozriete na 6. riadok, je to rovnaký záznam ako prvý. A preto je transakcia 699 zablokovaná. 700 je tiež samosvorný. A potom v spodnom riadku uvidíte, že čakáme, kým 699 dokončí svoju činnosť.
A v lock_type, tuple, vidíte čísla.
Môžete vidieť, že je to 0/10. A toto je číslo strany a tiež posun tohto konkrétneho riadku.
A vidíte, že keď aktualizujeme, stane sa 0/11.
Ale v skutočnosti je to 0/10, pretože na túto operáciu sa čaká. Máme možnosť vidieť, že toto je séria, na potvrdenie ktorej čakám.
Keď to potvrdíme a stlačíme commit, a keď sa aktualizácia dokončí, opäť dostaneme toto. Transakcia 700 je jediný zámok, nečaká na nikoho iného, pretože bol spáchaný. Jednoducho čaká na dokončenie transakcie. Keď sa minie 699, už na nič nečakáme. A teraz transakcia 700 hovorí, že všetko je v poriadku, že má všetky potrebné zámky na všetkých povolených stoloch.
A aby sme to celé ešte viac skomplikovali, vytvárame si ďalší pohľad, ktorý nám tentokrát poskytne hierarchiu. Neočakávam, že túto požiadavku pochopíte. To nám však poskytne jasnejší pohľad na to, čo sa deje.
Toto je rekurzívny pohľad, ktorý má aj ďalšiu časť. A potom to všetko opäť spojí. Využime toto.
Čo ak urobíme tri súčasné aktualizácie a povieme, že rad je teraz tri. A zmeníme 3 na 4.
A tu vidíme 4. A transakciu ID 702.
A potom zmením 4 na 5. A z 5 na 6 a 6 na 7. A zoradím množstvo ľudí, ktorí budú čakať na koniec tejto jednej transakcie.
A všetko sa vyjasní. Aký je prvý riadok? Toto je 702. Toto je ID transakcie, ktoré pôvodne nastavilo túto hodnotu. Čo je napísané v mojom stĺpci Udelené? Mám známky f. Toto sú moje aktualizácie, ktoré (5, 6, 7) nemožno schváliť, pretože čakáme na ukončenie transakcie ID 702. Tam máme blokovanie ID transakcie. Výsledkom je 5 transakčných ID zámkov.
A keď sa pozriete na 704, na 705, ešte tam nebolo nič napísané, pretože ešte nevedia, čo sa deje. Jednoducho píšu, že netušia, čo sa deje. A jednoducho pôjdu spať, pretože čakajú, kým niekto skončí a zobudia sa, keď sa naskytne príležitosť zmeniť rad.
Takto to vyzerá. Je jasné, že všetci čakajú na 12. rad.
Toto sme tu videli. Tu je 0/12.
Takže po schválení prvej transakcie tu môžete vidieť, ako funguje hierarchia. A teraz je všetko jasné. Všetky sa stanú čistými. A vlastne stále čakajú.
Tu je to, čo sa deje. 702 záväzkov. A teraz 703 dostane tento zámok riadku a potom 704 začne čakať na potvrdenie 703. A na toto čaká aj 705-ka. A keď je toto všetko dokončené, upratujú sa. A rád by som podotkol, že všetci stoja v rade. A to je veľmi podobné situácii v zápche, keď všetci čakajú na prvé auto. Prvé auto zastaví a všetci sa zoradia do dlhého radu. Potom sa pohne, ďalšie auto môže ísť dopredu a získať svoj blok atď.
A ak sa vám to nezdalo dosť komplikované, potom sa s vami porozprávame o mŕtvom bode. Neviem, kto z vás sa s nimi stretol. Toto je pomerne častý problém v databázových systémoch. Ale uviaznutie je, keď jedna relácia čaká na ďalšiu reláciu, aby niečo urobila. A v tejto chvíli ďalšia relácia čaká na to, aby prvá relácia niečo urobila.
A napríklad, ak Ivan povie: „Daj mi niečo,“ a ja poviem: „Nie, dám ti to, len ak mi dáš niečo iné.“ A on hovorí: "Nie, nedám ti to, ak to nedáš mne." A skončíme v patovej situácii. Som si istý, že to Ivan neurobí, ale chápete význam, že máme dvoch ľudí, ktorí chcú niečo dostať a nie sú pripravení to dať, kým im ten druhý nedá to, čo chcú. A neexistuje žiadne riešenie.
A vaša databáza to musí v podstate zistiť. A potom musíte vymazať alebo zatvoriť jednu z relácií, pretože inak tam zostanú navždy. A vidíme to v databázach, vidíme to v operačných systémoch. A na všetkých miestach, kde máme paralelné procesy, sa to môže stať.
A teraz nainštalujeme dve uviaznutia. Dáme 50 a 80. V prvom riadku aktualizujem z 50 na 50. Dostanem transakciu číslo 710.
A potom zmením 80 na 81 a 50 na 51.
A takto to bude vyzerať. A tak 710 má zablokovaný riadok a 711 čaká na potvrdenie. Videli sme to, keď sme aktualizovali. 710 je vlastníkom našej série. A 711 čaká, kým 710 dokončí transakciu.
A dokonca hovorí, na ktorom riadku dochádza k zablokovaniu. A tu to začína byť divné.
Teraz aktualizujeme 80 na 80.
A tu začína patová situácia. 710 čaká na odpoveď od 711 a 711 čaká na 710. A toto neskončí dobre. A z toho niet východiska. A budú od seba očakávať odpoveď.
A len to začne všetko odďaľovať. A to nechceme.
A Postgres má spôsoby, ako si všimnúť, keď sa to stane. A keď sa to stane, dostanete túto chybu. A z toho je jasné, že taký a taký proces čaká na SHARE LOCK od iného procesu, t.j. ktorý je zablokovaný procesom 711. A ten proces čakal na SHARE LOCK, ktorý bude daný na také a také ID transakcie a bol zablokovaný takým a takým procesom. Preto je tu patová situácia.
Existujú trojcestné uviaznutia? Je to možné? Áno.
Tieto čísla zapíšeme do tabuľky. Meníme 40 na 40, robíme blokovanie.
Meníme 60 na 61, 80 na 81.
A potom zmeníme 80 a potom bum!
A 714 teraz čaká na 715. 716-ka čaká na 715-ku. A nedá sa s tým nič robiť.
Už tu nie sú dvaja ľudia, sú tu už traja ľudia. Ja chcem niečo od teba, tento chce niečo od tretej osoby a tretia osoba chce niečo odo mňa. A skončíme v trojstrannom čakaní, pretože všetci čakáme, kým ten druhý dokončí to, čo potrebuje.
A Postgres vie, na ktorom riadku sa to stane. A tak vám dá nasledujúcu správu, ktorá ukazuje, že máte problém, keď sa navzájom blokujú tri vstupy. A tu neexistujú žiadne obmedzenia. To môže byť prípad, keď sa navzájom blokuje 20 záznamov.
Ďalší problém je serializovateľný.
Ak je špeciálny serializovateľný zámok.
A vraciame sa k 719. Jeho výstup je celkom normálny.
A môžete kliknúť, aby sa transakcia stala serializovateľnou.
A uvedomíte si, že teraz máte iný typ zámku SA – to znamená serializovateľný.
A tak tu máme nový typ zámku s názvom SARieadLock, čo je sériový zámok a umožňuje vám zadávať seriály.
A tiež môžete vložiť jedinečné indexy.
V tejto tabuľke máme jedinečné indexy.
Takže ak sem dám číslo 2, tak mám 2. Ale úplne hore som dal ďalšie 2. A môžete vidieť, že 721 má exkluzívny zámok. Ale teraz 722 čaká, kým 721 dokončí svoju operáciu, pretože nemôže vložiť 2, kým nevie, čo sa stane s 721.
A ak urobíme subtransakciu.
Máme tu 723.
A ak bod uložíme a potom ho aktualizujeme, získame nové ID transakcie. Toto je ďalší vzorec správania, ktorý si musíte uvedomiť. Ak to vrátime, ID transakcie zmizne. 724 odchádza. Ale teraz ich máme 725.
Tak čo sa tu snažím robiť? Snažím sa vám ukázať príklady nezvyčajných zámkov, ktoré môžete nájsť: či už ide o serializovateľné zámky alebo SAVEPOINT, toto sú rôzne typy zámkov, ktoré sa objavia v tabuľke zámkov.
Toto je vytvorenie explicitných (explicitných) zámkov, ktoré majú pg_advisory_lock.
A vidíte, že typ blokovania je uvedený ako poradný. A tu je napísané „poradenstvo“ červenou farbou. A súčasne môžete blokovať takto pomocou pg_advisory_unlock.
A na záver by som vám rád ukázal ešte jednu vzrušujúcu vec. Vytvorím iný pohľad. Ale spojím tabuľku pg_locks s tabuľkou pg_stat_activity. A prečo to chcem robiť? Pretože to mi umožní pozrieť sa a vidieť všetky aktuálne relácie a presne vidieť, na aké zámky čakajú. A to je celkom zaujímavé, keď dáme dokopy tabuľku zámkov a tabuľku dotazov.
A tu vytvoríme pg_stat_view.
A aktualizujeme riadok o jeden. A tu vidíme 724. A potom aktualizujeme náš rad na tri. A čo tu teraz vidíš? Toto sú žiadosti, t. j. celý zoznam žiadostí, ktoré sú uvedené v ľavom stĺpci, vidíte. A potom na pravej strane môžete vidieť blokády a to, čo vytvárajú. A môže to byť pre vás prehľadnejšie, aby ste sa nemuseli zakaždým vracať ku každej relácii a zisťovať, či sa k nej potrebujete pripojiť alebo nie. Robia to pre nás.
Ďalšou veľmi užitočnou funkciou je pg_blocking_pids. Pravdepodobne ste o nej nikdy nepočuli. Čo ona robí? Umožňuje nám povedať, že pre túto reláciu 11740 na aké konkrétne ID procesu čaká. A vidíte, že 11740 čaká na 724. A 724 je úplne na vrchole. A 11306 je vaše ID procesu. Táto funkcia v podstate prechádza cez vašu tabuľku zámkov. A viem, že je to trochu komplikované, ale dokážete to pochopiť. Táto funkcia v podstate prechádza cez túto tabuľku zámkov a pokúša sa nájsť, kde je tomuto ID procesu priradené zámky, na ktoré čaká. A tiež sa snaží zistiť, aké ID procesu má proces, ktorý čaká na zámok. Takže môžete spustiť túto funkciu pg_blocking_pids.
A to môže byť veľmi užitočné. Pridali sme to až vo verzii 9.6, takže táto funkcia je stará len 5 rokov, ale je veľmi, veľmi užitočná. A to isté platí aj o druhej žiadosti. Ukazuje presne to, čo potrebujeme vidieť.
O tomto som sa s tebou chcel porozprávať. A ako som očakával, vyčerpali sme všetok čas, pretože tam bolo toľko šmykľaviek. A snímky sú k dispozícii na stiahnutie. Chcel by som sa vám poďakovať, že ste tu. Som si istý, že sa vám bude páčiť zvyšok konferencie, ďakujem veľmi pekne!
Otázky:
Napríklad, ak sa pokúšam aktualizovať riadky a druhá relácia sa pokúša odstrániť celú tabuľku. Pokiaľ som pochopil, malo by tam byť niečo ako intent lock. Existuje niečo také v Postgrese?
Vráťme sa na úplný začiatok. Možno si pamätáte, že keď robíte čokoľvek, napríklad keď robíte SELECT, vydávame AccessShareLock. A to zabraňuje spadnutiu stola. Ak teda chcete napríklad aktualizovať riadok v tabuľke alebo odstrániť riadok, potom niekto nemôže odstrániť celú tabuľku súčasne, pretože držíte tento AccessShareLock nad celou tabuľkou a nad riadkom. A keď skončíte, môžu to odstrániť. Ale kým tam niečo priamo zmeníte, oni to nedokážu.
Urobme to znova. Prejdime k príkladu odstránenia. A vidíte, ako je na rade nad celým stolom exkluzívny zámok.
Bude to vyzerať ako exkluzívny zámok, však?
Áno, vyzerá to tak. chápem, o čom hovoríš. Hovoríte, že ak urobím SELECT, potom mám ShareExclusive a potom to urobím Row Exclusive, stáva sa to problémom? Ale prekvapivo to nepredstavuje problém. Vyzerá to ako zvýšenie stupňa uzamknutia, ale v podstate mám zámok, ktorý zabraňuje vymazaniu. A teraz, keď urobím tento zámok silnejším, stále bráni vymazaniu. Takže to nie je tak, že idem hore. To znamená, že zabránil tomu, aby sa to stalo, keď bol na nižšej úrovni, takže keď zvýšim jeho úroveň, stále zabráni vymazaniu tabuľky.
chápem, o čom hovoríš. Neexistuje tu prípad eskalácie zámku, kde sa pokúšate vzdať jedného zámku a zaviesť silnejší. Tu len celoplošne zvyšuje túto prevenciu, takže nespôsobuje žiadny konflikt. Ale je to dobrá otázka. Veľmi pekne vám ďakujem, že ste sa na to pýtali!
Čo musíme urobiť, aby sme sa vyhli zablokovaniu, keď máme veľa relácií a veľký počet používateľov?
Postgres automaticky zaznamenáva zablokovanie. A automaticky odstráni jednu z relácií. Jediný spôsob, ako sa vyhnúť mŕtvemu blokovaniu, je blokovať ľudí v rovnakom poradí. Takže keď sa pozriete na vašu aplikáciu, často je dôvodom zablokovania... Predstavme si, že chcem zablokovať dve rôzne veci. Jedna aplikácia uzamkne tabuľku 1 a iná aplikácia uzamkne 2 a potom tabuľku 1. A najjednoduchší spôsob, ako sa vyhnúť zablokovaniu, je pozrieť sa na vašu aplikáciu a pokúsiť sa uistiť, že uzamykanie prebieha v rovnakom poradí vo všetkých aplikáciách. A to zvyčajne eliminuje 80% problémov, pretože tieto aplikácie píšu všetci ľudia. A ak ich zablokujete v rovnakom poradí, nenarazíte na patovú situáciu.
Ďakujeme veľmi pekne za váš výkon! Hovorili ste o vákuu plnom a ak tomu správne rozumiem, vákuum plné skresľuje poradie záznamov v samostatnom úložisku, takže aktuálne záznamy uchovávajú nezmenené. Prečo vákuum plné vyžaduje exkluzívny prístup k zámku a prečo je v konflikte s operáciami zápisu?
To je dobrá otázka. Dôvodom je, že plné vákuum zaberá stôl. A v podstate vytvárame novú verziu tabuľky. A stôl bude nový. Ukazuje sa, že toto bude úplne nová verzia tabuľky. A problém je, že keď to urobíme, nechceme, aby to ľudia čítali, pretože potrebujeme, aby videli novú tabuľku. A tak to súvisí s predchádzajúcou otázkou. Keby sme vedeli súčasne čítať, nedokázali by sme to presunúť a nasmerovať ľudí k novému stolu. Museli by sme počkať, kým všetci dočítajú túto tabuľku, takže ide v podstate o exkluzívnu situáciu.
Hovoríme len, že zamykáme od začiatku, pretože vieme, že na samom konci budeme potrebovať exkluzívny zámok, aby sme všetkých presunuli do novej kópie. Takže to môžeme potenciálne vyriešiť. A robíme to týmto spôsobom so súčasným indexovaním. To je však oveľa ťažšie. A to veľmi súvisí s vašou predchádzajúcou otázkou o exkluzívnom zámku.
Je možné do Postgresu pridať časový limit uzamknutia? V Oracle môžem napríklad napísať „select to update“ a počkať 50 sekúnd pred aktualizáciou. Bolo to dobré pre aplikáciu. Ale v Postgres to buď musím urobiť hneď a vôbec nečakať, alebo počkať na nejaký čas.
Áno, môžete si vybrať časový limit na svojich zámkoch, na svojich zámkoch. Môžete tiež vydať zakázaný príkaz, ktorý... ak nemôžete okamžite získať zámok. Preto buď časový limit zámku alebo niečo iné, čo vám to umožní. Toto sa nerobí na syntaktickej úrovni. Toto sa vykonáva ako premenná na serveri. Niekedy sa to nedá použiť.
Môžete otvoriť snímku 75?
Áno.
A moja otázka je nasledovná. Prečo oba procesy aktualizácie očakávajú 703?
A toto je skvelá otázka. Mimochodom, nerozumiem, prečo to Postgres robí. Ale keď bola vytvorená 703, očakávala 702. A keď sa objavia 704 a 705, zdá sa, že nevedia, čo očakávajú, pretože tam ešte nič nie je. A Postgres to robí takto: keď nemôžete získať zámok, napíše „Aký má zmysel vás spracovávať?“, pretože už na niekoho čakáte. Takže to necháme visieť vo vzduchu, nebude to vôbec aktualizovať. Ale čo sa tu stalo? Hneď ako 702 dokončil proces a 703 dostal svoj zámok, systém sa vrátil späť. A povedala, že teraz máme dvoch ľudí, ktorí čakajú. A potom ich spolu aktualizujme. A naznačme, že obaja sú v očakávaní.
Neviem, prečo to Postgres robí. Ale je tu problém s názvom f…. Zdá sa mi, že to nie je výraz v ruštine. Vtedy všetci čakajú na jeden hrad, aj keď na hrad čaká 20 úradov. A zrazu sa všetci zobudia v rovnakom čase. A všetci sa začnú snažiť reagovať. Ale systém to robí tak, že všetci čakajú na 703. Pretože všetci čakajú a my ich hneď všetkých zoradíme. A ak sa objaví nejaká ďalšia nová požiadavka, ktorá bola vygenerovaná po tomto, napríklad 707, potom tam bude opäť prázdno.
A zdá sa mi, že sa to robí preto, aby sme mohli povedať, že v tejto fáze čaká 702 na 703 a všetci, ktorí prídu potom, nebudú mať v tomto poli žiadny vstup. No len čo odíde prvý čašník, všetci, ktorí v tej chvíli čakali pred aktualizáciou, dostanú rovnaký token. A tak si myslím, že sa to robí preto, aby sme mohli spracovať v poriadku, aby boli riadne objednané.
Vždy som sa na to pozerala ako na dosť zvláštny jav. Pretože tu ich napríklad vôbec neuvádzame. Ale zdá sa mi, že vždy, keď dávame nový zámok, pozeráme sa na všetkých, ktorí sú v procese čakania. Potom ich všetky zoradíme. A potom každý nový, ktorý príde, sa dostane do frontu až vtedy, keď ďalšia osoba dokončí spracovanie. Veľmi dobrá otázka. Ďakujem veľmi pekne za otázku!
Zdá sa mi, že je oveľa logickejšie, keď 705 očakáva 704.
Ale problém je tu nasledujúci. Technicky môžete zobudiť jedno alebo druhé. A tak zobudíme jedno alebo druhé. Čo sa však deje v systéme? Môžete vidieť, ako 703 úplne hore zablokoval svoje vlastné ID transakcie. Takto funguje Postgres. A 703 je blokované vlastným ID transakcie, takže ak chce niekto čakať, tak si počká na 703. A v podstate 703 dokončí. A až po jeho skončení sa jeden z procesov prebudí. A nevieme, čo presne tento proces bude. Potom všetko postupne spracujeme. Nie je však jasné, ktorý proces sa prebudí ako prvý, pretože to môže byť ktorýkoľvek z týchto procesov. V podstate sme mali plánovač, ktorý hovoril, že teraz môžeme prebudiť ktorýkoľvek z týchto procesov. Náhodne vyberieme jednu. Takže je potrebné zaznamenať oboch, pretože jedného z nich môžeme prebudiť.
A problém je, že máme CP-nekonečno. A preto je dosť pravdepodobné, že toho neskoršieho dokážeme zobudiť. A ak napríklad zobudíme neskoršieho, počkáme na toho, kto práve dostal blok, takže neurčujeme, kto presne bude zobudený ako prvý. Jednoducho vytvoríme takúto situáciu a systém ich prebudí v náhodnom poradí.
K dispozícii je . Pozrite, sú tiež zaujímavé a užitočné. Téma je, samozrejme, strašne zložitá. Ďakujem veľmi pekne, Bruce!
Zdroj: hab.com