Prezentácia Brucea Momjiana "Odomknutie Postgres Lock Managera" z roku 2020.
(Poznámka: Všetky SQL príkazy zo snímok si môžete stiahnuť na tomto odkaze: )
Ahojte! Je skvelé byť opäť tu v Rusku. Ospravedlňujem sa, že som sa nemohol prísť minulý rok, ale tento rok máme s Ivanom veľké plány. Dúfam, že budem tu oveľa častejšie. Milujem prichádzať do Ruska. Navštívim Tjumeň a Tver. Veľmi sa teším, že sa mi podarí navštíviť tieto mestá.
Volám sa Bruce Momjian. Pracujem v EnterpriseDB a pracujem s Postgresom viac ako 23 rokov. Žijem vo Philadelphii v USA. Cestujem približne 90 dní v roku a navštevujem 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 stránky. Obsahuje tiež približne 30 prezentácií, videá a množstvo blogových príspevkov, viac ako 500. Je to pomerne obsahový zdroj. A ak vás tento materiál zaujíma, pozývam vás, aby ste ho využili.
Predtým som bol učiteľom, profesorom, než som začal pracovať s Postgresom. A som veľmi rád, že vám teraz môžem povedať to, čo vám chcem povedať. Toto je jedna z najzaujímavejších mojich prezentácií a táto prezentácia obsahuje 110 snímok. Začneme s jednoduchými vecami a na konci bude prezentácia čoraz zložitejšia a zložitejšia.
Je to dosť nepríjemná diskusia. Blokovanie nie je najobľúbenejší predmet. Chceme, aby to niekam zmizlo. Je to ako ísť k zubárovi.
- Blokovanie je problém pre mnohých ľudí, ktorí pracujú s databázami a majú viacero procesov bežiacich súčasne. Potrebujú blokovanie. To znamená, že dnes vám poskytnem základné znalosti o blokovaní.
- Identifikátory transakcií. Toto je pomerne nudná časť prezentácie, ale je potrebné ich pochopiť.
- Potom budeme hovoriť o typoch blokovania. Toto je dosť mechanická časť.
- A neskôr prinesieme niektoré príklady blokovania. A to bude dosť ťažké na pochopenie.
Poďme hovoriť o blokovaniach.
Terminológia je u nás dosť zložitá. Koľko z vás vie, odkiaľ je tento úryvok? Dvaja ľudia. Je to z hry, ktorá sa volá „Kolosálne dobrodružstvo v jaskyni“. Bola to textová počítačová hra v 80-tych rokoch, myslím. Museli ste vojsť do jaskyne, do labyrintu a text sa menil, ale obsah zostával približne rovnaký každýkrát. Takto si pamätám túto hru.
A tu vidíme názvy blokád, ktoré k nám prišli z Oracle. Používame ich.
Tu vidíme termíny, ktoré ma mýlia. Napríklad, SHARE UPDATE EXCLUSIVE. Ďalej SHARE RAW EXCLUSIVE. Úprimne povedané, tieto názvy nie sú veľmi zrozumiteľné. Pokúsime sa ich preskúmať podrobnejšie. Niektoré obsahujú slovo „share“, ktoré znamená – oddeliť sa. Niektoré obsahujú slovo „exclusive“ — exkluzívny. V niektorých sú oba tieto výrazy. Chcel by som začať tým, ako tieto blokády fungujú.
A takisto je veľmi dôležité slovo „prístup“ — access. A slovo „row“ — riadok. T. j. rozdelenie prístupu, rozdelenie riadkov.
Ešte jedna otázka, ktorú je potrebné pochopiť v Postgres, o ktorej, žiaľ, nebudem môcť hovoriť vo svojom vystúpení, je MVCC. Mám na túto tému samostatnú prezentáciu na svojej webovej stránke. A ak si myslíte, že táto prezentácia je zložitá, tak MVCC je pravdepodobne moja najzložitejšia. A ak vás to zaujíma, môžete si ju pozrieť na webe. Môžete si pozrieť video.
Ešte jeden bod, ktorý musíme pochopiť – sú identifikátory transakcií. Mnohé transakcie nemôžu fungovať bez jedinečných identifikátorov. A tu máme vysvetlenie toho, čo je transakcia. V Postgres sú dva systémy číslovania transakcií. Viem, že to nie je veľmi pekné riešenie.
Takisto si pamätajte, že snímky budú dosť zložité na pochopenie, takže na to, čo je zvýraznené červenou farbou, by sa mala venovať zvýšená pozornosť.
Pozrime sa. Červenou farbou je zvýraznené číslo transakcie. Tu je zobrazená funkcia SELECT pg_back. Vracia moju transakciu a ID tejto 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 označený ružovou farbou a stiahnuť SQL pre túto prezentáciu. A môžete ju jednoducho spustiť vo vašom PSQL a celá prezentácia sa objaví na vašej obrazovke okamžite. Nebude obsahovať farby, ale aspoň ju budeme môcť vidieť.
V tomto prípade vidíme ID transakcie. To je číslo, ktoré sme mu priradili. A existuje aj iný typ ID transakcie v Postgres, ktorý sa nazýva virtuálne ID transakcie.
A musíme to pochopiť. Je to veľmi dôležité, inak nebudeme schopní porozumieť blokovaniu v Postgres.
Virtuálne ID transakcie je ID transakcie, ktoré neobsahuje trvalé hodnoty. Napríklad, ak spustím príkaz SELECT, pravdepodobne nebudem meniť databázu, nič nebudem blokovať. Preto, keď spúšťame jednoduchý SELECT, nedávame tejto transakcii trvalé ID. Dávame jej len virtuálne ID.
A to zvyšuje výkon Postgres, zlepšuje možnosti čistenia, preto virtuálne ID transakcie pozostáva z dvoch čísel. Prvé číslo pred lomkou je ID backendu. A napravo vidíme jednoducho čítač.
Preto ak spúšťam dotaz, hovorí, že ID backendu je 2.
A ak spúšťam sériu takýchto transakcií, vidíme, že čítač sa zakaždým zvyšuje, keď spúšťam dotaz. Napríklad, keď spúšťam dotaz 2/10, 2/11, 2/12 a tak ďalej.
Majte na pamäti, že tu sú dve stĺpce. Vľavo vidíme virtuálne ID transakcie – 2/12. A napravo máme trvalé ID transakcie. A toto pole je prázdne. A táto transakcia nemodifikuje databázu. Preto jej nepriraďujem trvalé ID transakcie.
Hneď ako spustím príkaz analyzovať (ANALYZE), rovnaký dotaz mi dá trvalé ID transakcie. Pozrite sa, ako sa to zmenilo. Predtým som nemal toto ID, teraz sa objavilo.
Takže tu je ďalší dotaz, ďalšia transakcia. Virtuálne číslo transakcie – 2/13. A ak požiadam o trvalé ID transakcie, tak keď spustím dotaz, získam ho.
Takže ešte raz. Máme virtuálne ID transakcie a trvalé ID transakcie. Len pochopte túto vec, aby ste mohli pochopiť správanie Postgres.
Prejdeme k tretej sekcii. Tu si prejdeme rôzne typy zámkov v Postgres. Nie je to veľmi zaujímavé. Posledná sekcia bude oveľa zaujímavejšia. Ale musíme sa pozrieť na základné veci, inak nepochopíme, čo bude ďalej.
Prejdeme touto sekciou a pozrieme sa na každý typ zámku. Ukážem vám príklady, ako sa nastavujú, ako fungujú a predvediem niektoré dotazy, ktoré môžete použiť na zobrazenie zámkov v Postgres.
Aby sme vytvorili dotaz a zistili, čo sa deje v Postgres, musíme spustiť dotaz v systémovom zobrazení. V tomto prípade je červenou farbou vyznačený pg_lock. Pg_lock je systémová tabuľka, ktorá nám hovorí, aké zámky sú momentálne používané v Postgres.
Napriek tomu je pre mňa veľmi ťažké ukázať vám pg_lock samotný, pretože je to dosť zložité. Preto som vytvoril zobrazenie, ktoré ukazuje pg_locks. A tiež vykonáva pre mňa niektoré úlohy, ktoré mi umožňujú lepšie porozumieť. To znamená, že vylučuje moje zámky, moju vlastnú reláciu atď. Je to len štandardný SQL a umožňuje mi lepšie ukázať, čo sa deje.
Ďalším problémom je, že toto zobrazenie je veľmi široké, a preto musím vytvoriť druhé – lockview2.
A ukazuje mi ďalšie stĺpce z tabuľky. A ešte jeden, ktorý mi ukazuje ostatné stĺpce. Je to dosť zložité, takže som sa snažil to predstaviť čo najjednoduchšie.
Takže sme vytvorili tabuľku s názvom Lockdemo. A vytvorili sme tam jeden riadok. Toto je naša vzorová tabuľka. A budeme vytvárať sekcie, aby sme vám jednoducho ukázali príklady zámkov.
Takže jeden riadok, jeden stĺpec. Prvý typ zámku sa volá ACCESS SHARE. Je to najmenej obmedzujúci zámok. To znamená, že prakticky nekoliduje s ostatnými zámkami.
A ak chceme výslovne definovať blokovanie, spustíme príkaz „lock table“. To jasne zamkne, teda v režime ACCESS SHARE spúšťame lock table. A ak spustím PSQL na pozadí, tak mám druhú reláciu z mojej prvej relácie. Teda, čo tu spravím? Prejdem k inej relácii a hovorím jej „ukáž mi lockview pre tento dotaz“. A tu mám AccessShareLock v tejto tabuľke. To je presne to, čo som požadoval. A hovorí, že blokovanie bolo priradené. Veľmi jednoduché.
Ďalej, ak sa pozrieme na druhý stĺpec, tak tam nič nie je. Sú prázdne.
A ak spustím príkaz „SELECT“, tak je to implicitný (výslovný) spôsob, ako požiadať o AccessShareLock. Preto uvoľním svoju tabuľku a spustím dotaz, a dotaz vráti niekoľko riadkov. A v jednom z riadkov vidíme AccessShareLock. Takto SELECT vyvoláva AccessShareLock v tabuľke. A prakticky nezmieta s ničím, pretože je to nízke blokovanie.
Čo ak spustím SELECT a budem mať tri rôzne tabuľky? Predtým som spúšťal len jednu tabuľku, teraz spúšťam tri: pg_class, pg_namespace a pg_attribute.
A teraz, keď sa pozriem na dotaz, vidím 9 AccessShareLocks v troch tabuľkách. Prečo? Modro sú zvýraznené tri tabuľky: pg_attribute, pg_class, pg_namespace. Ale tiež môžete vidieť, že všetky indexy, ktoré sú definované cez tieto tabuľky, majú tiež AccessShareLock.
A toto je blokovanie, ktoré prakticky nekonfliktuje s inými. A všetko, čo robí, je, že nám jednoducho nedovoľuje uvoľniť tabuľku, kým ju vyberáme. To dáva zmysel. Teda, ak vyberáme tabuľku, táto okamžite nezmizne, to by bolo nesprávne, pretože AccessShare – to je nízke blokovanie, ktoré nám hovorí "nevymazávajte túto tabuľku, kým s ňou pracujem".. To je v podstate všetko, čo robí.
ROW SHARE – to je blokovanie, ktoré je trochu odlišné.
Zoberme príklad. SELECT ROW SHARE spôsob blokovania každej jednotlivé riadku. Takže nikto ich nemôže vymazať alebo zmeniť, kým ich sledujeme.
Takže, čo robí SHARE LOCK? Vidíme, že ID transakcie 681 pre SELECT. A to je zaujímavé. Čo sa tu stalo? Po prvý raz vidíme číslo v poli „Lock“. Berieme ID transakcie, a hovorí, že ju uzamkne v exkluzívnom režime. Všetko, čo robí, je, že hovorí, že mám riadok, ktorý je technicky uzamknutý niekde v tabuľke. Ale nehovorí kde konkrétne. O niečo neskôr sa na to podrobnejšie pozrieme.
Tu hovoríme, že uzamknutie používame my.
Takže exkluzívne uzamknutie explicitne (jasne) hovorí, že je exkluzívne. A ak odstránite riadok v tejto tabuľke, to sa aj stane, ako môžete vidieť.
SHARE EXCLUSIVE – to je dlhšie uzamknutie.
Toto je (ANALYZE) príkaz analyzátora, ktorý sa bude používať.
SHARE LOCK – môžete explicitne uzamknúť v režime share.
Môžete tiež vytvoriť jedinečný index. A tam môžete vidieť SHARE LOCK, ktorý je jeho súčasťou. A uzamkne tabuľku a nastaví na ňu uzamknutie SHARE LOCK.
Predvolené SHARE LOCK na tabuľke znamená, že iní môžu tabuľku čítať, ale nikto ju nemôže modifikovať. A presne to sa deje, keď vytvárate jedinečný index.
Ak vytváram jedinečný concurrently index, budem mať iný typ uzamknutia, pretože, ako si pamätáte, použitie concurrently indexov znižuje požadovane uzamknutie. A ak používam normálne uzamknutie, normálny index, takto zabránim zápisu do indexu tabuľky počas jeho vytvárania. Ak používam concurrently index, musím použiť iný typ uzamknutia.
SHARE ROW EXCLUSIVE – opäť ho možno nastaviť explicitne (jasne).
Alebo môžeme vytvoriť pravidlo, t.j. vziať nejaký konkrétny prípad, pri ktorom sa bude používať.
EXCLUSIVE uzamknutie znamená, že nikto iný nemôže meniť tabuľku.
Tu vidíme rôzne typy uzamknutí.
ACCESS EXCLUSIVE, napríklad, je príkaz uzamknutia. Napríklad, ak robíte CLUSTER table, znamená to, že nikto nebude môcť zapisovať dovnútra. A uzamkne nielen samotnú tabuľku, ale aj indexy.
Toto je druhá stránka uzamknutia ACCESS EXCLUSIVE, kde vidíme konkrétne, čo uzamkne v tabuľke. Uzamkne jednotlivé riadky tabuľky, čo je dosť zaujímavé.
Toto sú všetky základné informácie, ktoré som chcel poskytnúť. Hovorili sme o blokovaniach, o ID transakcií, o virtuálnych ID transakcií a o trvalých ID transakcií.
A teraz si prejdeme prípadmi blokovania. Toto je najzaujímavejšia časť. Pozrieme sa na veľmi zaujímavé situácie. A mojím cieľom v tejto prezentácii je poskytnúť vám lepšie pochopenie toho, čo Postgres naozaj robí, keď sa pokúša blokovať rôzne veci. Myslím, že má veľmi dobrú schopnosť blokovať jednotlivé časti.
Poďme sa pozrieť na konkrétne príklady.
Začneme s tabuľkami a s jedným riadkom v tabuľke. Keď niečo vložím, zobrazuje sa mi ExclusiveLock, ID transakcie a ExclusiveLock na tabuľke.
A čo sa stane, ak vložím ďalšie dva riadky? A teraz máme v našej tabuľke tri riadky. Vložil som jeden riadok a dostal som toto ako výstup. A ak vložím ďalšie dva riadky, čo je tu zvláštne? Tu je zvláštnosť, pretože som pridal tri riadky k tejto tabuľke, ale mám stále dva riadky v tabuľke blokovania. A to je v zásade základné správanie Postgresu.
Mnohí si myslia, že ak v databáze zablokujete 100 riadkov, budete musieť vytvoriť 100 vstupov blokovania. Ak by som blokoval naraz 1 000 riadkov, potom by som potreboval 1 000 takýchto požiadaviek. A ak potrebujem zablokovať milión alebo miliardu. Ale ak budeme robiť veci takto, nebude to veľmi efektívne. Ak ste používali systém, ktorý vytvára vstupy blokovania pre každý jednotlivý riadok, uvidíte, že je to zložité. Pretože musíte určiť tabuľku blokovania, ktorá sa môže zaplniť, ale Postgres to nerobí.
A na tomto slajde je veľmi dôležité, že tu je jasne demonštrované, že existuje ďalší systém, ktorý pracuje v rámci MVCC, ktorý blokuje jednotlivé riadky. Takže, keď zablokujete miliardy riadkov, Postgres nevytvára miliardu samostatných príkazov na blokovanie. A to veľmi dobre ovplyvňuje výkon.
A čo aktualizácie? Momentálne aktualizujem rad, a môžete si všimnúť, že vykonal dve rôzne operácie. Súčasne zablokoval tabuľku, ale taktiež zablokoval index. A musel zablokovať index, pretože na tejto tabuľke sú unikátne obmedzenia. Chceme sa uistiť, že nikto ho nemá možnosť meniť, takže ho zablokujeme.
A čo sa stane, ak chcem aktualizovať dva rady? Vidíme, že sa správa rovnako. Robíme dvakrát viac aktualizácií, ale presne rovnaký počet zablokovaných riadkov.
Ak vás zaujíma, ako to Postgres robí, musíte si vypočuť moje prednášky o MVCC, aby ste sa dozvedeli, ako Postgres interné označuje tie rady, ktoré mení. Postgres má spôsob, ako to robí, ale nerobí to na úrovni blokovania tabuliek, robí to na nižšej a efektívnejšej úrovni.
A čo ak chcem niečo odstrániť? Ak odstránim napríklad jeden rad a stále mám svoje dva vstupné blokády, a aj keby som chcel odstrániť všetky, stále tam budú.
A povedzme, že chcem vložiť 1 000 riadkov, a potom ich buď odstrániť, alebo pridať ďalších 1 000 riadkov, individuálne riadky, ktoré pridávam alebo mením, sa tu nezapíšu. Zapíšu sa na nižšej úrovni v rámci samotného radu. A počas mojej prednášky o MVCC som o tom hovoril podrobne. Ale je veľmi dôležité, keď analyzujete blokácie, uistiť sa, že máte blokáciu na úrovni tabuľky a že tu nevidíte, ako sa zapisujú jednotlivé rady.
A čo explicitná blokácia?
Ak kliknem na ‚aktualizovať‘, mám dva zablokované rady. A ak ich všetky označím a kliknem na ‚aktualizovať všade‘, stále mi zostanú dve záznamy blokácie.
Nevytvárame samostatné záznamy pre každý jednotlivý rad. Pretože by to znížilo výkon, mohlo by ich byť príliš veľa. A mohli by sme sa ocitnúť v nepríjemnej situácii.
A to isté, ak robíme zdieľané, môžeme robiť pre všetkých 30-krát.
Obnovujeme našu tabuľku, všetko odstraňujeme a potom znova vkladáme jeden rad.
In PostgreSQL, another type of behavior you observe is well-known and desirable—namely, that you can conduct updates or selects simultaneously. The selects do not block updates, and vice versa. We are saying that a reader does not block a writer while a writer does not block a reader.
I will show you an example of this. I will make a selection now. We will then perform an INSERT. You will later see—694. You will see the transaction ID that performed this insertion. This is how it works.
And if I look at my backend ID now, it has become—695.
And I can see that 695 appears in my table.
If I conduct an update here like this, I encounter a different case. In this situation, 695 has an exclusive lock, while the update behaves similarly, but there is no conflict between them, which is rather unusual.
You can notice that at the top is a ShareLock and at the bottom is an ExclusiveLock. Both transactions have been executed.
You need to listen to my MVCC presentation to understand how this happens. But this illustrates that you can do this simultaneously, i.e., perform SELECT and UPDATE at the same time.
Let's reset and perform another operation once again.
If you try to run two updates simultaneously on the same row, it will get locked. Remember, I said that a reader does not block a writer, while a writer blocks a reader, but one writer can block another writer. This means we cannot have two people updating the same row at the same time. One must wait until the other finishes.
To illustrate this, I will look at the Lockdemo table. We will examine one row. Regarding transaction 698.
We updated it to 2. 699 is the first update. It has either completed successfully or is in a pending transaction awaiting confirmation or cancellation.
Pozrite sa na iné – 2/51 – to je náš prvý transakčný dopyt, naša prvá relácia. 3/112 – to je druhý dopyt, ktorý sa objavil hore a ktorý zmenil túto hodnotu na 3. A ak si všimnete, horný dopyt zablokoval sám seba, čo bolo 699. Ale 3/112 neposkytli zablokovanie. V stĺpci Lock_mode je napísané, že čaká. Čaká na 699. A ak sa pozriete, kde je 699, je vyššie. A čo urobila prvá relácia? Vytvorila exkluzívne zablokovanie na svojom vlastnom transakčnom ID. Takto to robí Postgres. Zablokuje svoje vlastné transakčné ID. A ak chcete čakať, kým niekto potvrdí alebo zruší, musíte čakať, kým existuje čakajúca transakcia. A preto môžeme vidieť zvláštny riadok.
Pozrime sa ešte raz. Vľavo vidíme naše spracovateľské ID. V druhom stĺpci vidíme našu virtuálnu ID transakcie, a v treťom vidíme lock_type. Čo to znamená? V podstate hovorí, že zablokuje transakčné ID. Ale všimnite si, že vo všetkých radoch dole je napísané relation. A preto máte dva druhy zablokovania v tabuľke. Existuje zablokovanie relation. A tiež existuje zablokovanie transactionid, kde sa zablokujete sami, to je presne to, čo sa deje v prvom riadku alebo úplne dole, kde transationid, kde čakáme, aby 699 dokončil svoju operáciu.
Sledujem, čo sa tu deje. A tu sa súčasne dejú dve veci. Pozeráte sa na zablokovanie podľa transakčného ID v prvom riadku, ktoré sa blokuje samo. A blokuje samo seba, aby donútilo ľudí čakať.
Ak sa pozriete na 6. riadok, tak tam je rovnaký záznam ako prvý. A preto je transakcia 699 zablokovaná. 700 sa tiež samoblokuje. A potom v dolnom riadku uvidíte, že čakáme, kým 699 dokončí svoju operáciu.
A v lock_type, tuple vidíte čísla.
Môžete vidieť, že to je 0/10. A to je číslo stránky, a tiež offset tohto konkrétneho riadu.
A vidíte, že sa to stáva 0/11, keď aktualizujeme.
Ale v skutočnosti – je to 0/10, pretože sa očakáva táto operácia. Môžeme sa pozrieť, čo je ten riadok, ktorý čakám na potvrdenie.
Keď sme to potvrdili a klikli na commit, a keď sa aktualizácia skončila, toto je to, čo znovu dostaneme. Transakcia 700 je jediná blokáda, na ktorú nikto nečaká, pretože bola zakomitovaná. Iba čaká, kým sa transakcia dokončí. Hneď ako 699 skončí, už na nič nečakáme. A teraz transakcia 700 hovorí, že všetko je v poriadku, že všetky blokácie, ktoré potrebuje, má vo všetkých povolených tabuľkách.
A aby sme to všetko ešte viac skomplikovali, vytvárame ďalší pohľad, ktorý tentoraz poskytne hierarchiu. Neočakávam, že tento dotaz pochopíte. Ale to nám dá jasnejší pohľad na to, čo sa deje.
Toto je rekurzívny pohľad, ktorý má tiež ďalšiu sekciu. A potom opäť vracia všetko dokopy. Poďme to využiť.
Čo ak urobíme tri súbežné aktualizácie a povieme, že rad je teraz rovný trom. A zmeníme 3 na 4.
A teraz vidíme 4. A transakčný ID 702.
A potom zmením 4 na 5. A 5 na 6, a 6 na 7. A zapisujem do radu ľudí, ktorí budú čakať na to, aby táto jedna transakcia skončila.
A všetko je zrozumiteľné. Aký je prvý rad? Je to 702. To je transakčný ID, ktoré pôvodne nastavilo túto hodnotu. A čo mám napísané v stĺpci Granted? Mám tam poznámky f. To sú moje aktualizácie, ktoré (5, 6, 7) nemôžu byť schválené, pretože čakáme, kým sa transakčný ID 702 dokončí. Tam máme blokáciu transakčného ID. A máme 5 transakčných blokácií ID.
A ak sa pozriete na 704, na 705, tam ešte nič nie je napísané, pretože ešte nevedia, čo sa deje. Iba píšu, že nemajú tušenie, čo sa deje. A proste zaspia, pretože čakajú, kým niekto skončí a prebudia ich, keď sa objaví príležitosť zmeniť rad.
Toto je, ako to vyzerá. Je jasné, že všetci čakajú na 12. riadok.
Toto je to, čo sme videli tu. Tu je 0/12.
Takže, keď je prvá transakcia schválená, môžete tu vidieť, ako funguje hierarchia. A teraz je všetko jasné. Všetci sú čistý. A v skutočnosti stále čakajú.
Tu sa deje. 702 sa ukláda. Teraz 703 dostáva túto zamknutú položku a potom 704 začína čakať, kým sa 703 uloží. A 705 tiež čaká. A keď sa to celé skončí, tak si to všetko vyčistia. Chcel by som poukázať na to, že všetci stojí v rade. A je to veľmi podobné situácii s dopravnou zápchou, keď všetci čakajú na prvé auto. Prvé auto sa zastavilo a všetci sa zoradia do dlhého radu. Potom sa pohne, potom môže ísť ďalšie auto dopredu a získať svoju uzamknutú položku a tak ďalej.
A ak vám to nepripadalo dostatočne zložité, teraz si povieme o deadlockoch. Neviem, kto z vás sa s nimi stretol. Je to dosť bežný problém v databázových systémoch. Deadlocky sú situácie, keď jedna relácia čaká na to, aby niečo vykonala iná relácia. A v tejto chvíli druhá relácia čaká, aby prvá relácia vykonala niečo.
A napríklad, ak Ivan povie: „Daj mi niečo“, a ja poviem: „Nie, dám ti to len vtedy, ak mi dáš niečo iné“. A on povie: „Nie, nedám ti to, ak mi to nedáš“. A dostávame sa do situácie mŕtvej blokácie. Som si istý, že Ivan to neurobí, ale rozumiete podstate, že dvaja ľudia chcú niečo získať a nie sú ochotní to dať, pokým im druhý človek nedá to, čo chcú. A tu nie je riešenie.
A v podstate, vaša databáza to musí odhaliť. A potom je potrebné odstrániť alebo zavrieť 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 v všetkých miestach, kde máme paralelné procesy, sa to môže diať.
A teraz nastavíme dve deadlocky. Nastavíme 50 a 80. V prvom riadku vykonám aktualizáciu z 50 na 50. Budem mať číslo transakcie 710.
A potom zmením 80 na 81 a 50 na 51.
A takto to bude vyzerať. A preto má 710 zamknutú položku a 711 čaká na potvrdenie. Videli sme to, keď sme aktualizovali. 710 je vlastníkom našej položky. A 711 čaká, kým 710 dokončí transakciu.
A dokonca je tam napísané na akom konkrétnom riadku sa nám deje deadlock. A tu to začína byť zvláštne.
Teraz aktualizujeme 80 na 80.
A tu začínajú deadlocky. 710 čaká na odpoveď od 711, a 711 čaká na 710. A toto neskočí dobre. A nie je z toho žiadne východisko. A budú si navzájom čakať na odpoveď.
A to len všetko začne oneskorenie. A toho sa nechceme dočkať.
A v Postgres sú spôsoby ako si všimnúť, keď k tomu dôjde. A keď k tomu dôjde, dostanete takúto chybu. A jasne z toho vyplýva, že takýto proces čaká na SHARE LOCK od iného procesu, t.j. ktorý je blokovaný procesom 711. A ten proces čakal, aby mu bol poskytnutý SHARE LOCK na určitý transakčný ID a bol blokovaný určitým procesom. Preto je tu situácia s mŕtvym zápisom.
Existuje trojstranný deadlock? Je to možné? Áno.
Vkladáme tieto čísla do tabuľky. Meníme 40 za 40, robíme uzamknutie.
Meníme 60 za 61, 80 za 81.
A potom meníme 80, a potom – bum!
A 714 teraz čaká na 715. 716 čaká na 715. A s tým už nič neurobíte.
Tu už nie sú dvaja ľudia, je tu už tri osoby. Chcem niečo od teba, tento chce niečo od tretej osoby, a tretia osoba chce niečo odo mňa. A dostávame sa do trojstranného čakania, pretože všetci čakáme, kým druhý splní to, čo má robiť.
A Postgres vie, na ktorom riadku to prebieha. A preto vám dá nasledujúcu správu, ktorá ukazuje, že máte problém, kde tri vstupy vzájomne blokujú jeden druhého. A tu nie sú obmedzenia. Môže to byť situácia, kde 20 záznamov navzájom blokuje jeden druhého.
Ďalší problém – to je serializable.
Ak ide o špeciálne serializable uzamknutie.
A vraciame sa k 719. Má úplne normálny výstup.
A môžete kliknúť, aby ste vykonali transakciu zo serializable.
A rozumiete, že teraz máte iný typ uzamknutia SA – to znamená serializable.
A preto máme nový typ uzamknutia, ktorý sa nazýva SARieadLock, čo je sériové uzamknutie a umožňuje vkladať sériové čísla.
A tiež môžete vkladať jedinečné indexy.
V tejto tabuľke máme jedinečné indexy.
Takže, ak sem vložím číslo 2, preto mám 2. Ale na vrchu vkladám ešte jedno 2. A môžete vidieť, že 721 má výlučné uzamknutie. Ale teraz 722 čaká, aby 721 dokončil svoju operáciu, pretože nemôže vložiť 2, kým nevie, čo sa stane s 721.
A ak robíme subtransaction.
Tu máme 723.
A ak zachováme bod a potom ho aktualizujeme, dostaneme nový transakčný ID. Toto je ďalší charakter správania, ktorý by ste mali vedieť. Ak to vrátime, transakčný ID zanikne. 724 zaniká. Ale teraz sa objaví 725.
A čo sa snažím urobiť? Snažím sa vám ukázať príklady nezvyčajných zámkov, ktoré môžete nájsť: či už sú to serializable zámky alebo SAVEPOINT – to sú rôzne druhy zámkov, ktoré sa zobrazia v tabuľke zámkov.
Ide o vytvorenie explicitných zámkov, ktoré majú pg_advisory_lock.
A vidíte, že typ zámku je tu uvedený ako advisory. A tu je červeným písmom napísané „advisory“. A môžete to súčasne takto zamknúť s pg_advisory_unlock.
A na záver by som vám chcel ukázať ešte jednu fascinujúcu vec. Vytvorím ďalší typ. Ale spojím tabuľku pg_locks s tabuľkou pg_stat_activity. A prečo to chcem urobiť? Pretože mi to umožní vidieť všetky aktuálne relácie a zistiť, akých zámkov sa obávajú. A to je dosť zaujímavé, keď spojíme tabuľku zámkov s tabuľkou požiadaviek.
A tu vytvárame pg_stat_view.
A aktualizujeme riadok na jeden. A tu vidíme 724. A potom aktualizujeme náš riadok na tri. A čo tu teraz vidíte? To sú požiadavky, t.j. vidíte celý zoznam požiadaviek, ktoré sú uvedené v ľavom stĺpci. A potom na pravej strane môžete vidieť zámky a to, čo vytvárajú. A to môže byť pre vás zrozumiteľnejšie, aby ste nemuseli zakaždým prechádzať každú reláciu a pozerať sa – či sa k nej pripojiť alebo nie. To sa deje za nás.
Ďalšia funkcia, ktorá je veľmi užitočná – je to pg_blocking_pidsMožno ste o tom nikdy nepočuli. Čo to robí? Umožňuje nám to povedať, aké ID procesov očakáva tento session 11740. A môžete vidieť, že 11740 očakáva 724. A 724 je na vrchu. A 11306 je váš ID proces. V podstate táto funkcia prechádza vašou tabulkou zamknutí. A viem, že je to trochu zložité, ale vy to chápete. V podstate táto funkcia prechádza touto tabulkou zamknutí a snaží sa nájsť, kde je tento proces ID, berúc do úvahy zamknutia, ktoré očakáva. A tiež sa snaží vypočítať, ktorý presne proces ID má ten proces, ktorý čaká zamknutie. Preto môžete spustiť túto funkciu. pg_blocking_pids.
A to môže byť veľmi užitočné. Pridali sme to iba s verziou 9.6, takže táto funkcia má len 5 rokov, ale je veľmi a veľmi užitočná. A to isté platí pre druhý dotaz. Zobrazuje presne to, čo potrebujeme vidieť.
To je to, o čom som chcel s vami hovoriť. A ako som očakával, strávili sme celý náš čas, pretože bolo veľa snímok. A snímky sú k dispozícii na stiahnutie. Chcel by som vám poďakovať, že ste tu boli. Som si istý, že si užijete zvyšok konferencie, ďakujem vám!
Otázky:
Napríklad, ak sa snažím aktualizovať riadky, a druhá session sa snaží odstrániť celú tabuľku. Ako rozumiem, malo by tam byť niečo ako intent lock. Existuje niečo také v Postgres?
Vrátime sa na začiatok. Možno si pamätáte, že keď robíte čokoľvek, napríklad keď robíte SELECT, poskytujeme AccessShareLock. A to zabraňuje odstráneniu tabuľky. Preto ak chcete napríklad aktualizovať riadok v tabuľke alebo odstrániť riadok, niekto nemôže odstrániť celú tabuľku súčasne s tým, pretože držíte tento AccessShareLock nad celou tabuľkou a nad riadkom. A keď ste skončili, môžu to odstrániť. Ale pokiaľ niečo meníte, nemôžu to spraviť.
Poďme ešte raz. Poďme na príklad s odstraňovaním. A vidíte, ako je na riadku exkluzívny lock nad celou tabuľkou.
Bude to vyzerať ako lock exclusive, správne?
Áno, to vyzerá takto. Rozumiem, o čom hovoríte. Hovoríte, že ak vykonám SELECT, dostanem ShareExclusive a potom to pretransformujem do stavu Row Exclusive, stáva sa to problémom? Ale prekvapujúco to nespôsobuje problém. Vyzerá to ako zvýšenie stupňa blokovania, ale v podstate mám uzamknutie, ktoré bráni mazaniu. A teraz, keď túto zámku posilňujem, stále bráni mazaniu. Takže nejde o to, že by som sa posúval vyššie. T. j. to bránilo tomuto už na nižšej úrovni, takže keď zvyšujem jeho úroveň, stále to bráni odstráneniu tabuľky.
Rozumiem, o čom hovoríte. Tu nejde o situáciu zvýšenia stupňa blokovania, kde sa snažíte zbaviť jednej zámky, aby ste zaviedli silnejšiu. Tu to jednoducho všade zvyšuje toto bránenie, takže to nespôsobuje žiadny konflikt. Ale je to dobrá otázka. Veľká vďaka, že ste ju položili!
Čo musíme urobiť, aby sme sa vyhli situácii deadlocku, keď máme veľa relácií a veľký počet používateľov?
Postgres automaticky rozpoznáva situácie deadlocku. A automaticky odstráni jednu z relácií. Jediný spôsob, ako sa vyhnúť situácii s mŕtvymi blokádami, je blokovať ľudí v rovnakom poradí. Takže, keď sa pozriete na vašu aplikáciu, často je príčina deadlockov… Predstavte si, že chcem zablokovať dve rôzne veci. Jedna aplikácia blokuje tabuľku 1, a druhá aplikácia blokuje 2 a potom tabuľku 1. A najjednoduchší spôsob, ako sa vyhnúť deadlockom, je pozrieť sa na vašu aplikáciu a pokúsiť sa zabezpečiť, aby blokovanie prebiehalo v rovnakom poradí vo všetkých aplikáciách. A to obvykle odstráni 80 % problémov, pretože rôzni ľudia píšu tieto aplikácie. A ak ich blokujete v rovnakom poradí, tak nečelíte situácii deadlocku.
Veľká vďaka za vaše vystúpenie! Hovorili ste o vacuum full a, ak správne chápem, vacuum full deformuje poradie záznamov v samostatnom úložisku, takže súčasné záznamy zostávajú nezmenené. A prečo vacuum full vyžaduje exkluzívnu zámku a prečo konfliktuje so zápisovými operáciami?
To je dobrá otázka. Dôvodom je, že príkaz vacuum full preberá tabuľku. Tým v podstate vytvárame novú verziu tabuľky. A tabuľka bude nová. To bude úplne nová verzia tabuľky. Problém je v tom, že keď to robíme, nechceme, aby to ľudia čítali, pretože potrebujeme, aby videli novú tabuľku. Preto to súvisí s predchádzajúcou otázkou. Keby sme mohli čítať súčasne, nemohli by sme ju presunúť a nasmerovať ľudí na novú tabuľku. Museli by sme čakať, až každý skončí s čítaním tejto tabuľky, a preto je to v podstate situácia lock exclusive.
Len hovoríme, že od začiatku blokujeme, pretože vieme, že na konci budeme potrebovať exkluzívnu blokáciu, aby sme presunuli všetkých na novú kópiu. Preto to potenciálne môžeme povoliť. A robíme to zároveň s indexovaním. Ale je to oveľa zložitejšie. A veľmi to súvisí s vašou predchádzajúcou otázkou o lock exclusive.
Je možné pridať locking timeout v Postgres? V Oracle môžem napríklad napísať 'select for update' a čakať 50 sekúnd na aktualizáciu. To bolo dobré pre aplikáciu. Ale v Postgres buď musím urobiť okamžite a vôbec nečakať, alebo čakať do určitého okamihu.
Áno, môžete si vybrať timeout pre vaše zámky, pre vaše locks. Môžete tiež vydať príkaz no way, ktorý bude... ak okamžite nezískate zámok. Takže buď lock timeout, alebo niečo iné, čo vám to umožní. To sa nerobí na syntaktickej úrovni. Robí sa to ako premenná na serveri. Niekedy to nie je možné použiť.
Môžete otvoriť 75. snímku?
Áno.
A moja otázka je nasledovná. Prečo oba procesy aktualizácie čakajú na 703?
A to je skvelá otázka. Nechápem, prečo to Postgres robí. Ale keď bol 703 vytvorený, očakával 702. A keď sa objavia 704 a 705, zdá sa, že nevedia, na čo čakajú, 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 aj tak čakáte na niekoho. Takže ho necháme visieť vo vzduchu, vôbec to neaktualizuje. Ale čo sa tu stalo? Hneď ako 702 dokončil proces a 703 získal svoj zámok, systém sa vrátil späť. A povedal, že teraz máme dvoch ľudí, ktorí sú v čakacej línii. A potom poďme ich spolu aktualizovať. A ukážeme, že obaja čakajú.
Neviem, prečo to Postgres robí. Ale je tu problém, ktorý sa nazýva f…. Myslím, že to nie je termín v slovenčine. To je, keď všetci čakajú na jeden zámok, aj keď je 20 inštancií, ktoré čakajú na zámok. A zrazu sa všetci prebudia naraz. A všetci sa pokúšajú reagovať. Ale systém robí tak, že všetci čakajú na 703. Pretože všetci čakajú a hneď ich zoradíme do frontu. A ak sa objaví akákoľvek iná nová požiadavka, ktorá bola vytvorená po tomto, napríklad 707, tak tam znova bude prázdnota.
A mám pocit, že to sa robí, aby sme mohli povedať, že v tomto štádiu 702 čaká na 703, a všetci tí, ktorí prídu po ňom, nebudú mať žiadny záznam v tomto poli. Ale hneď ako prvý čakajúci odíde a všetci, ktorí čakali v tom okamihu pred aktualizáciou, získajú ten istý identifikátor. A preto si myslím, že to je urobené, aby sme mohli spracovávať v poriadku, aby boli správne zoradení.
Vždy som sa na to pozeral ako na dosť zvláštny fenomén. Pretože tu, napríklad, ich vôbec nevymenúvame. Ale myslím, že zakaždým, keď dáme nový zámok, sa pozeráme na všetkých tých, ktorí sú v procese čakania. Potom ich všetkých zoradíme do frontu. A potom akýkoľvek nový, ktorý príde, sa dostane do frontu až keď ďalší človek dokončil spracovanie. Veľmi dobrá otázka. Ďakujem vám veľmi pekne za otázku!
Myslím, že je oveľa logickejšie, keď 705 čaká na 704.
Problém je v tom, že technicky môžete prebudiť buď jeden, alebo druhý. A preto prebúdime ten alebo iný. Čo sa však deje v systéme? Vidíte, ako 703 zablokoval svoj vlastný transakčný ID na vrchu. Takto funguje Postgres. A 703 je zablokovaný svojím vlastným transakčným ID, takže ak niekto čaká, čaká na 703. V podstate, 703 sa ukončuje. A až po jeho ukončení sa nejaký z procesov prebúdza. A nevieme, ktorý proces to bude. Potom postupne spracovávame všetko. Ale nie je jasné, ktorý proces sa prebúdza prvý, pretože to môže byť ktorýkoľvek z týchto procesov. V podstate sme mali plánovača, ktorý povedal, že teraz môžeme prebudiť ktorýkoľvek z týchto procesov. Jednoducho si náhodne vyberieme jeden. Preto obaja musia byť označení, pretože môžeme prebudiť ktorýkoľvek z nich.
A problém je v tom, že máme CP-nekonečno. A preto je dosť pravdepodobné, že môžeme prebudiť neskorší. A ak, napríklad, prebúdzame neskorší, budeme čakať na niekoho, kto práve získal zámok, a preto neurčujeme, kto presne bude prebudený prvý. Vytvárame jednoducho takú situáciu a systém ich prebúdza v náhodnom poradí.
Existuje . Pozrite sa, sú tiež zaujímavé a užitočné. Téma je samozrejme strašne zložitá. Veľmi pekne ďakujem, Bruce!
Zdroj: habr.com
