Bruce Momjian 2020-as „A Postgres Lock Manager feloldása” című előadásának átirata.
(Megjegyzés: A diák összes SQL-lekérdezése letölthető erről a linkről: )
Helló! Nagyon jó újra itt lenni Oroszországban. Sajnálom, hogy tavaly nem tudtam eljönni, de idén nagy terveink vannak Ivánnal. Remélem, hogy sokkal gyakrabban leszek itt. Szeretek Oroszországba jönni. Meglátogatom Tyumen, Tver. Nagyon örülök, hogy meglátogathatom ezeket a városokat.
A nevem Bruce Momjian. Az EnterpriseDB-nél dolgozom, és több mint 23 éve dolgozom a Postgres-nél. Philadelphiában, az Egyesült Államokban élek. Évente körülbelül 90 napot utazom. És körülbelül 40 konferencián veszek részt. Az én , amely azokat a diákat tartalmazza, amelyeket most megmutatok. Ezért a konferencia után letöltheti őket személyes honlapomról. Körülbelül 30 előadást is tartalmaz. Vannak videók és számos blogbejegyzés is, több mint 500. Ez egy meglehetősen informatív forrás. És ha érdekli ez az anyag, akkor felkérem, hogy használja.
Tanár voltam, professzor, mielőtt elkezdtem dolgozni a Postgres-szel. És nagyon örülök, hogy most elmondhatom neked, amit el fogok mondani. Ez az egyik legérdekesebb előadásom. Ez a bemutató pedig 110 diát tartalmaz. Egyszerű dolgokkal kezdünk beszélgetni, és a végére a jelentés egyre összetettebb lesz, és meglehetősen összetett lesz.
Ez egy meglehetősen kellemetlen beszélgetés. A blokkolás nem a legnépszerűbb téma. Azt akarjuk, hogy ez valahol eltűnjön. Mintha fogorvoshoz mennék.
- A zárolás sok olyan ember számára jelent problémát, akik adatbázisokban dolgoznak, és több folyamat fut egyszerre. Blokkolásra van szükségük. Vagyis ma alapismereteket adok a blokkolással kapcsolatban.
- Tranzakcióazonosítók. Ez egy meglehetősen unalmas része az előadásnak, de meg kell érteni őket.
- Ezután a blokkolás típusairól fogunk beszélni. Ez egy meglehetősen mechanikus alkatrész.
- Az alábbiakban néhány példát adunk a blokkolásra. És elég nehéz lesz megérteni.
Beszéljünk a blokkolásról.
A terminológiánk meglehetősen összetett. Hányan tudják, honnan származik ez a szövegrész? Két ember. Ez a Colossal Cave Adventure nevű játékból származik. Azt hiszem, egy szöveges számítógépes játék volt a 80-as években. Ott be kellett menni egy barlangba, egy labirintusba, és változott a szöveg, de a tartalom minden alkalommal megközelítőleg ugyanaz volt. Így emlékszem erre a játékra.
És itt látjuk azoknak a záraknak a nevét, amelyek az Oracle-től kerültek hozzánk. Használjuk őket.
Itt olyan kifejezéseket látunk, amelyek összezavarnak. Például: SHARE UPDATE EXXLUSIVE. Következő MEGOSZTÁS RAW EXXLUSIVE. Őszintén szólva ezek a nevek nem túl világosak. Megpróbáljuk részletesebben megvizsgálni őket. Néhányan a „share” szót tartalmazzák, ami azt jelenti, hogy elválasztjuk. Néhányan az „exkluzív” szót tartalmazzák. Néhányan mindkét szót tartalmazzák. Szeretném kezdeni azzal, hogyan működnek ezek a zárak.
És a „hozzáférés” szó is nagyon fontos. A „sor” szavak pedig egy karakterlánc. Vagyis hozzáférési elosztás, sorelosztás.
Egy másik probléma, amit a Postgres-ben meg kell érteni, és amelyre sajnos nem fogok tudni kitérni az előadásomban, az az MVCC. Erről a témáról külön előadásom van a honlapomon. És ha úgy gondolja, hogy ez a bemutató nehéz, akkor valószínűleg az MVCC a legnehezebb. Akit pedig érdekel, a honlapon meg is nézheti. Megnézheti a videót.
Egy másik dolog, amit meg kell értenünk, a tranzakcióazonosítók. Sok tranzakció nem működhet egyedi azonosítók nélkül. És itt van egy magyarázat arra vonatkozóan, hogy mi a tranzakció. A Postgres két tranzakciószámozási rendszerrel rendelkezik. Tudom, hogy ez nem túl szép megoldás.
Ne feledje azt is, hogy a diák meglehetősen nehezen érthető lesz, ezért ami pirossal van kiemelve, arra oda kell figyelni.
Lássuk. A tranzakció száma pirossal van kiemelve. Itt látható a SELECT pg_back függvény. Visszaadja a tranzakciómat és a tranzakció azonosítóját.
Még egy dolog, ha tetszik ez a prezentáció és szeretnéd futtatni az adatbázisodban, akkor erre a linkre léphetsz rózsaszínnel és letöltheted az SQL-t ehhez a bemutatóhoz. Egyszerűen futtathatja a PSQL-ben, és a teljes prezentáció azonnal megjelenik a képernyőn. Nem lesz benne virág, de legalább láthatjuk.
Ebben az esetben a tranzakcióazonosítót látjuk. Ezt a számot adtuk neki. És van egy másik típusú tranzakcióazonosító a Postgresben, amelyet virtuális tranzakcióazonosítónak neveznek
És ezt meg kell értenünk. Ez nagyon fontos, különben nem fogjuk megérteni a zárolást a Postgres-ben.
A virtuális tranzakcióazonosító olyan tranzakcióazonosító, amely nem tartalmaz állandó értékeket. Például, ha lefuttatok egy SELECT parancsot, akkor nagy valószínűséggel nem fogom megváltoztatni az adatbázist, nem zárolok semmit. Tehát amikor egy egyszerű SELECT-et futtatunk, nem adunk állandó azonosítót a tranzakciónak. Ott csak virtuális azonosítót adunk neki.
Ez pedig javítja a Postgres teljesítményét, javítja a tisztítási képességeket, így a virtuális tranzakcióazonosító két számból áll. A perjel előtti első szám a háttérazonosító. A jobb oldalon pedig csak egy számlálót látunk.
Ezért ha lefuttatok egy kérést, azt írja ki, hogy a háttérazonosító 2.
És ha egy sor ilyen tranzakciót futtatok, akkor azt látjuk, hogy a számláló minden alkalommal növekszik, amikor lekérdezek. Például amikor a 2/10, 2/11, 2/12 stb. lekérdezést futtatom.
Ne feledje, hogy itt két oszlop található. A bal oldalon a virtuális tranzakcióazonosító látható – 2/12. A jobb oldalon pedig van egy állandó tranzakcióazonosítónk. És ez a mező üres. És ez a tranzakció nem módosítja az adatbázist. Tehát nem adok neki állandó tranzakcióazonosítót.
Amint futtatom az elemzés parancsot ((ANALYZE)), ugyanaz a lekérdezés állandó tranzakcióazonosítót ad. Nézze meg, hogyan változott ez nálunk. Korábban nem volt nálam ez az azonosító, de most megvan.
Tehát itt egy újabb kérés, egy újabb tranzakció. A virtuális tranzakciószám 2/13. És ha állandó tranzakciós azonosítót kérek, akkor a lekérdezés futtatásakor megkapom.
Szóval mégegyszer. Van egy virtuális tranzakcióazonosítónk és egy állandó tranzakciós azonosítónk. Csak értse meg ezt a pontot, hogy megértse a Postgres viselkedését.
Továbblépünk a harmadik szakaszra. Itt egyszerűen végigjárjuk a Postgres különböző típusú zárait. Nem túl érdekes. Az utolsó rész sokkal érdekesebb lesz. De figyelembe kell vennünk az alapvető dolgokat, mert különben nem fogjuk megérteni, mi lesz ezután.
Végigmegyünk ezen a szakaszon, és megvizsgáljuk az egyes zártípusokat. És mutatok példákat a telepítésükre, működésükre, mutatok néhány lekérdezést, amelyek segítségével megtudhatja, hogyan működik a zárolás a Postgresben.
Lekérdezés létrehozásához és megnézéséhez, hogy mi történik a Postgresben, ki kell adnunk a lekérdezést a rendszernézetben. Ebben az esetben a pg_lock piros színnel van kiemelve. A Pg_lock egy rendszertábla, amely megmondja, hogy jelenleg milyen zárak vannak használatban a Postgresben.
Azonban nagyon nehéz megmutatnom a pg_lock-ot önmagában, mert meglehetősen összetett. Ezért létrehoztam egy nézetet, amely a pg_locks-t mutatja. És ez is segít számomra, hogy jobban megértsem. Vagyis kizárja a zárolásaimat, a saját munkamenetemet stb. Ez csak a szabványos SQL, és lehetővé teszi, hogy jobban megmutassa, mi történik.
Egy másik probléma, hogy ez a nézet nagyon széles, ezért létre kell hoznom egy másodikat - a lockview2-t.
És további oszlopokat mutat a táblázatból. És egy másik, amely megmutatja a többi oszlopot. Ez elég összetett, ezért igyekeztem a lehető legegyszerűbben bemutatni.
Így létrehoztunk egy Lockdemo nevű táblázatot. És ott létrehoztunk egy sort. Ez a minta táblázatunk. És szakaszokat fogunk létrehozni, hogy példákat mutassunk a zárakra.
Tehát egy sor, egy oszlop. Az első típusú zár az úgynevezett ACCESS SHARE. Ez a legkevésbé korlátozó blokkolás. Ez azt jelenti, hogy gyakorlatilag nem ütközik más zárakkal.
És ha explicit módon szeretnénk definiálni egy zárat, akkor futtatjuk a „lock table” parancsot. És nyilván blokkolni fog, azaz ACCESS SHARE módban elindítjuk a zártáblát. És ha a háttérben futtatom a PSQL-t, akkor a második munkamenetet az első munkamenetemből indítom így. Vagyis mit fogok itt csinálni? Egy másik munkamenetre megyek, és azt mondom neki: "mutasd meg a kérés zárnézetét". És itt van ebben a táblázatban az AccessShareLock. Pontosan ezt kértem. És azt mondja, hogy a blokk hozzá van rendelve. Nagyon egyszerű.
Továbbá, ha a második oszlopot nézzük, akkor ott nincs semmi. Üresek.
És ha futtatom a "SELECT" parancsot, akkor ez az AccessShareLock kérésének implicit (explicit) módja. Tehát felszabadítom a táblámat, lefuttatom a lekérdezést, és a lekérdezés több sort ad vissza. És az egyik sorban az AccessShareLockot látjuk. Így a SELECT meghívja az AccessShareLock-ot az asztalon. És gyakorlatilag semmivel nem ütközik, mert ez egy alacsony szintű zár.
Mi van, ha egy SELECT-et futtatok, és három különböző táblám van? Korábban csak egy táblát futtattam, most hármat: pg_class, pg_namespace és pg_attribute.
És most, amikor megnézem a lekérdezést, 9 AccessShareLockot látok három táblázatban. Miért? Három tábla van kékkel kiemelve: pg_attribute, pg_class, pg_namespace. De azt is láthatja, hogy az ezeken a táblákon keresztül meghatározott összes index rendelkezik AccessShareLock-kal is.
És ez egy olyan zár, amely gyakorlatilag nem ütközik másokkal. És ez csak annyit tesz, hogy megakadályozza, hogy visszaállítsuk a táblázatot, miközben kiválasztjuk. Van értelme. Vagyis ha kiválasztunk egy táblát, az abban a pillanatban eltűnik, akkor ez rossz, tehát Az AccessShare egy alacsony szintű zár, amely azt mondja nekünk, hogy "ne ejtsd le ezt az asztalt, amíg dolgozom". Lényegében csak ennyit csinál.
SORMEGOSZTÁS – Ez a zár egy kicsit más.
Vegyünk egy példát. SELECT ROW SHARE módszer az egyes sorok egyenkénti zárolására. Így senki sem tudja törölni vagy módosítani őket, amíg nézzük őket.
Tehát mit csinál a SHARE LOCK? Látjuk, hogy a SELECT tranzakcióazonosítója 681. És ez érdekes. Mi történt itt? Először látjuk a számot a „Zárolás” mezőben. Felvesszük a tranzakcióazonosítót, és azt mondja, hogy kizárólagos módban blokkolja. Csak annyit tesz, hogy van egy sorom, amely technikailag le van zárva valahol a táblázatban. De nem mondja meg, hogy pontosan hol. Ezt kicsit később részletesebben is megvizsgáljuk.
Itt azt mondjuk, hogy a zárat mi használjuk.
Tehát egy exkluzív zár kifejezetten azt mondja, hogy kizárólagos. És ha töröl egy sort ebben a táblázatban, akkor ez fog történni, amint láthatja.
A SHARE EXCLUSIVE egy hosszabb zár.
Ez az (ANALYZE) elemző parancs, amelyet használni fog.
SHARE LOCK – kifejezetten zárolható megosztási módban.
Létrehozhat egyedi indexet is. És ott láthatod a SHARE LOCK-ot, ami ezek része. És lezárja az asztalt, és egy SHARE LOCK-ot tesz rá.
Alapértelmezés szerint a SHARE LOCK egy asztalon azt jelenti, hogy mások elolvashatják a táblázatot, de senki nem módosíthatja azt. És pontosan ez történik, ha egyedi indexet hoz létre.
Ha létrehozok egy egyedi párhuzamos indexet, akkor más típusú zárolást fogok használni, mert emlékszik, hogy az egyidejű indexek használata csökkenti a zárolási követelményeket. És ha normál zárolást, normál indexet használok, akkor ezzel megakadályozom, hogy a táblaindexbe írjak, amíg annak létrehozása van. Ha egyidejűleg indexet használok, akkor más típusú zárolást kell használnom.
SHARE ROW EXCLUSIVE – ismét kifejezetten (explicit) állítható be.
Vagy létrehozhatunk egy szabályt, azaz vegyünk egy konkrét esetet, amikor azt használni fogják.
Az EXKLUZÍV zár azt jelenti, hogy senki más nem cserélheti ki az asztalt.
Itt különböző típusú zárakat látunk.
Az ACCESS EXCLUSIVE például egy blokkoló parancs. Például ha igen CLUSTER table, akkor ez azt jelenti, hogy senki nem fog tudni oda írni. És nem csak magát a táblát zárolja, hanem az indexeket is.
Ez az ACCESS EXCLUSIVE blokkolás második oldala, ahol pontosan azt látjuk, hogy mit blokkol a táblázatban. Az egyes táblázatsorokat zárolja, ami elég érdekes.
Ez az összes alapvető információ, amit szerettem volna megadni. Beszéltünk zárakról, tranzakcióazonosítókról, virtuális tranzakcióazonosítókról, állandó tranzakcióazonosítókról.
És most végigmegyünk néhány blokkoló példán. Ez a legérdekesebb rész. Nagyon érdekes eseteket fogunk megvizsgálni. Ezzel az előadással az a célom, hogy jobban megértsem, mit csinál a Postgres valójában, amikor megpróbál blokkolni bizonyos dolgokat. Szerintem nagyon jól tudja blokkolni a részeket.
Nézzünk néhány konkrét példát.
Kezdjük táblázatokkal és egy sorral a táblázatban. Amikor beszúrok valamit, ExclusiveLock, Tranzakcióazonosító és ExclusiveLock jelenik meg az asztalon.
Mi történik, ha beszúrok még két sort? És most a táblázatunk három soros. És beszúrtam egy sort, és ezt kaptam kimenetként. És ha beszúrok még két sort, mi ebben a furcsa? Van itt egy furcsa dolog, mert három sort adtam hozzá ehhez a táblázathoz, de még mindig van két sorom a zártáblázatban. És ez lényegében Postgres alapvető viselkedése.
Sokan úgy gondolják, hogy ha egy adatbázisban 100 sort zárol, akkor 100 zárolási bejegyzést kell létrehoznia. Ha egyszerre 1 sort blokkolok, akkor 000 ilyen lekérdezésre lesz szükségem. És ha kell egy millió vagy egy milliárd blokkolni. De ha ezt tesszük, az nem fog túl jól működni. Ha olyan rendszert használt, amely minden egyes sorhoz blokkoló bejegyzéseket hoz létre, akkor láthatja, hogy ez bonyolult. Mert azonnal meg kell határozni egy zártáblát, ami túlcsordulhat, de a Postgres ezt nem teszi meg.
És ami igazán fontos ebben a diában, az az, hogy egyértelműen bemutatja, hogy van egy másik rendszer, amely az MVCC-n belül fut, és zárolja az egyes sorokat. Tehát amikor több milliárd sort zárol, a Postgres nem hoz létre egymilliárd különálló zárolási parancsot. Ez pedig nagyon jó hatással van a termelékenységre.
Mi a helyzet egy frissítéssel? Most frissítem a sort, és láthatod, hogy egyszerre két különböző műveletet hajtott végre. Egyszerre zárta az asztalt, de az indexet is. És az indexet zárolnia kellett, mert egyedi megszorítások vannak ezen a táblán. És szeretnénk biztosítani, hogy senki ne változtassa meg, ezért letiltjuk.
Mi történik, ha két sort akarok frissíteni? És látjuk, hogy ő is hasonlóan viselkedik. Kétszer annyi frissítést végzünk, de pontosan ugyanannyi zársort.
Ha kíváncsi arra, hogy a Postgres hogyan csinálja ezt, meg kell hallgatnia az MVCC-ről szóló előadásaimat, hogy megtudja, hogyan jelöli meg a Postgres belsőleg ezeket a vonalakat, amelyeket megváltoztat. És a Postgres-nek van egy módja, hogy ezt megteszi, de nem az asztalzárás szintjén teszi, hanem alacsonyabb és hatékonyabb szinten.
Mi van, ha törölni akarok valamit? Ha például kitörölök egy sort, és továbbra is megvan a két blokkoló bemenetem, és még ha törölni is szeretném az összeset, akkor is ott vannak.
És például 1 sort akarok beszúrni, majd törölni vagy hozzáadni 000 sort, majd azokat az egyes sorokat, amiket hozzáadok vagy módosítok, azok itt nem kerülnek rögzítésre. Magán a sorozaton belül alacsonyabb szinten íródnak. Az MVCC beszédében pedig részletesen beszéltem erről. De nagyon fontos a zárolások elemzésekor, hogy megbizonyosodjon arról, hogy a zárolás a táblázat szintjén történik, és hogy nem látja, hogyan rögzítik az egyes sorokat itt.
Mi a helyzet az explicit letiltással?
Ha a frissítésre kattintok, két sorom zárolva van. És ha mindegyiket kijelölöm, és rákattintok a „frissítés mindenhol” lehetőségre, akkor is két blokkoló rekordom van.
Nem hozunk létre külön rekordot minden egyes sorhoz. Mert akkor csökken a termelékenység, túl sok lehet belőle. És kellemetlen helyzetbe kerülhetünk.
És ugyanez, ha megosztjuk, megtehetjük 30 alkalommal.
Visszaállítjuk a táblázatunkat, mindent törölünk, majd ismét beszúrunk egy sort.
Egy másik, a Postgresben látható, nagyon jól ismert és kívánt viselkedés az, hogy frissíthet vagy kiválaszthat. És ezt megteheti egyszerre. És válassza nem blokkolja a frissítést, és ugyanaz a dolog az ellenkező irányba. Azt mondjuk az olvasónak, hogy ne blokkolja az írót, és az író nem blokkolta az olvasót.
Mutatok erre egy példát. most választok. Ezután elvégezzük az INSERT-et. És akkor láthatja - 694. Láthatja annak a tranzakciónak az azonosítóját, amely ezt a beillesztést végrehajtotta. És ez így működik.
És ha most megnézem a háttérazonosítómat, akkor most 695.
És látom, hogy a 695 megjelenik a táblázatomban.
És ha itt így frissítek, akkor más esetet kapok. Ebben az esetben a 695 egy exkluzív zárolás, és a frissítés is ugyanúgy viselkedik, de nincs köztük konfliktus, ami meglehetősen szokatlan.
És láthatod, hogy felül a ShareLock, alul pedig az ExclusiveLock. És mindkét tranzakció sikerült.
És meg kell hallgatnia a beszédemet az MVCC-nél, hogy megértse, hogyan történik ez. De ez egy szemléltetés, hogy ezt egyszerre is megteheti, azaz egy SELECT-et és egy UPDATE-et egyszerre.
Állítsuk alaphelyzetbe, és végezzünk még egy műveletet.
Ha két frissítést próbál meg egyszerre futtatni ugyanabban a sorban, a rendszer blokkolja. És ne feledd, azt mondtam, hogy az olvasó nem blokkolja az írót, és az író nem blokkolja az olvasót, hanem az egyik író blokkolja a másik írót. Vagyis két ember nem frissítheti egyszerre ugyanazt a sort. Meg kell várni, amíg valamelyik befejezi.
És ennek szemléltetésére megnézem a Lockdemo táblázatot. És megnézünk egy sort. Tranzakciónként 698.
Ezt frissítettük 2-re. A 699 az első frissítés. És sikeres volt, vagy függőben van, és megerősítésre vagy visszavonásra vár.
De nézzünk mást – 2/51 az első tranzakciónk, az első munkamenetünk. A 3/112 a második felülről érkező kérés, amely ezt az értéket 3-ra változtatta. És ha észreveszi, a felső zárolta magát, ami 699. De a 3/112 nem engedélyezte a zárolást. A Lock_mode oszlopban szerepel, hogy mire vár. 699-et vár. És ha megnézed, hol van a 699, akkor az magasabb. És mit csinált az első ülés? Exkluzív zárat hozott létre saját tranzakcióazonosítójára. A Postgres így csinálja. Letiltja saját tranzakcióazonosítóját. És ha meg akarja várni, hogy valaki megerősítse vagy törölje, akkor meg kell várnia, amíg van egy függőben lévő tranzakció. És ezért láthatunk egy furcsa vonalat.
Nézzük újra. A bal oldalon a feldolgozási azonosítónkat látjuk. A második oszlopban a virtuális tranzakcióazonosítónkat látjuk, a harmadikban pedig a lock_type. Mit is jelent ez? Lényegében azt mondja, hogy blokkolja a tranzakcióazonosítót. De figyelje meg, hogy az összes sor alján relációt ír. Így kétféle zár van az asztalon. Van kapcsolatzár. És akkor ott van a tranzakcióazonosító blokkolás, ahol saját maga blokkolja, ami pontosan az első sorban vagy a legalsó sorban történik, ahol a tranzakcióazonosító van, ahol megvárjuk, amíg a 699 befejezi a működését.
Meglátom mi lesz itt. És itt két dolog történik egyszerre. A tranzakcióazonosító zárolását nézi az első sorban, amely zárolja magát. És leblokkolja magát, hogy az embereket várja.
Ha megnézi a 6. sort, az ugyanaz, mint az első. Ezért a 699-es tranzakció blokkolva van. A 700 is önzáró. És akkor az alsó sorban látni fogja, hogy a 699-re várunk, hogy befejezze a működését.
És a lock_type, tuple-ben számokat lát.
Láthatod, hogy 0/10. És ez az oldalszám, és ennek a sornak az eltolása is.
És látja, hogy 0/11 lesz, amikor frissítjük.
De a valóságban ez 0/10, mert erre a műveletre várni kell. Lehetőségünk van látni, hogy ez az a sorozat, amelynek megerősítését várom.
Miután megerősítettük és megnyomtuk a commit gombot, és amikor a frissítés befejeződött, ismét ezt kapjuk. A 700-as tranzakció az egyetlen zár, nem vár senki másra, mert lekötötték. Egyszerűen megvárja a tranzakció befejezését. Ha a 699 elfogy, nem várunk többé semmire. És most a 700-as tranzakció azt mondja, hogy minden rendben van, minden engedélyezett táblán megvan az összes szükséges zár.
És hogy ezt az egészet még bonyolultabbá tegyük, létrehozunk egy másik nézetet, amely ezúttal egy hierarchiát ad nekünk. Nem várom el, hogy megértse ezt a kérést. De így tisztább képet kapunk arról, hogy mi történik.
Ez egy rekurzív nézet, amely egy másik szakaszt is tartalmaz. Aztán újra összehoz mindent. Használjuk ezt.
Mi van, ha három egyidejű frissítést végzünk, és azt mondjuk, hogy a sor most három. És 3-at cserélünk 4-re.
És itt látjuk a 4. És a 702-es tranzakcióazonosítót.
És akkor 4-et 5-re változtatok. És 5-öt 6-ra, és 6-ot 7-re. És sorba állítok néhány embert, akik megvárják ennek az egyetlen tranzakciónak a végét.
És minden világossá válik. Mi az első sor? Ez a 702. Ez a tranzakcióazonosító, amely eredetileg beállította ezt az értéket. Mi van a Megengedett rovatomban? vannak jegyeim f. Ezek az én frissítéseim, amelyeket (5, 6, 7) nem lehet jóváhagyni, mert a 702-es tranzakcióazonosító végére várunk. Ott van a tranzakcióazonosító letiltása. Ez pedig 5 tranzakciós azonosító zárolást eredményez.
És ha megnézed a 704-et, a 705-öt, ott még nem írtak semmit, mert még nem tudják, mi a helyzet. Egyszerűen azt írják, hogy fogalmuk sincs, mi történik. És csak aludni fognak, mert arra várnak, hogy valaki befejezze és felébressze őket, amikor lehetőség nyílik sorváltásra.
Így néz ki. Egyértelmű, hogy mindannyian a 12-es vonalra várnak.
Ezt láttuk itt. Itt a 0/12.
Tehát az első tranzakció jóváhagyása után itt láthatja, hogyan működik a hierarchia. És most minden világossá válik. Mindegyik tisztává válik. És valójában még mindig várnak.
Íme, mi történik. 702 commit. És most a 703 megkapja ezt a sorzárolást, majd a 704 elkezdi várni a 703 véglegesítését. És a 705 is erre vár. És ha mindez befejeződött, megtisztítják magukat. És szeretném leszögezni, hogy mindenki beáll a sorba. És ez nagyon hasonlít egy forgalmi dugóban kialakult helyzethez, amikor mindenki az első autóra vár. Az első autó megáll, és mindenki beáll a hosszú sorba. Aztán megmozdul, majd a következő autó előre tud hajtani és megkapja a blokkját stb.
És ha ez neked nem tűnt elég bonyolultnak, akkor most a holtpontokról fogunk beszélni. Nem tudom, melyikőtök találkozott már velük. Ez meglehetősen gyakori probléma az adatbázis-rendszerekben. A holtpont azonban az, amikor az egyik munkamenet egy másik munkamenetre vár, hogy csináljon valamit. És ebben a pillanatban egy másik munkamenet vár az első munkamenetre, hogy tegyen valamit.
És például, ha Iván azt mondja: „Adj nekem valamit”, én pedig azt mondom: „Nem, csak akkor adom neked, ha adsz valami mást.” És azt mondja: "Nem, nem adom neked, ha nem adod nekem." És holtpontra jutunk. Biztos vagyok benne, hogy Iván nem fogja ezt megtenni, de értitek a jelentését, hogy két emberünk van, aki szeretne kapni valamit, és nem hajlandó odaadni, amíg a másik meg nem adja, amit akar. És nincs megoldás.
És lényegében az adatbázisának ezt észlelnie kell. És akkor törölnie kell vagy be kell zárnia az egyik munkamenetet, mert különben örökre ott marad. És látjuk az adatbázisokban, látjuk az operációs rendszerekben. És minden olyan helyen, ahol párhuzamos folyamataink vannak, ez megtörténhet.
És most két holtpontot telepítünk. 50-et és 80-at teszünk. Az első sorba 50-ről 50-re frissítek. A 710-es tranzakciószámot kapom.
Aztán 80-at 81-re, 50-et 51-re változtatok.
És ez így fog kinézni. Így a 710-ben egy sor blokkolva van, a 711-es pedig megerősítésre vár. Ezt láttuk, amikor frissítettük. A 710 sorozatunk tulajdonosa. A 711 pedig a 710-re vár a tranzakció befejezéséhez.
És még azt is megmondja, hogy melyik sorban fordulnak elő a holtpontok. És itt kezd furcsa lenni.
Most 80-ról 80-ra frissítjük.
És itt kezdődnek a holtpontok. A 710 a 711-től vár, a 711 a 710-et. És ennek nem lesz jó vége. És ebből nincs kiút. És választ fognak várni egymástól.
És ez csak elkezd mindent késleltetni. És ezt nem akarjuk.
És a Postgresnek van módja annak, hogy észrevegye, ha ez megtörténik. És amikor ez megtörténik, ezt a hibát kapja. Ebből pedig jól látható, hogy ilyen és ilyen folyamat egy másik folyamattól vár SHARE LOCK-ot, vagyis amit a 711-es folyamat blokkol. Az a folyamat pedig arra várt, hogy egy SHARE LOCK-ot adjanak egy ilyen-olyan tranzakciós azonosítóra, és egy ilyen-olyan folyamat blokkolta. Ezért itt holtpontról van szó.
Vannak háromirányú patthelyzetek? Lehetséges? Igen.
Ezeket a számokat beírjuk egy táblázatba. 40-et 40-re cserélünk, blokkolást végzünk.
60-ról 61-re, 80-ról 81-re változtatunk.
És akkor cserélünk 80-at, aztán bumm!
És a 714 most a 715-re vár. A 716-os a 715-re vár. És ez ellen semmit sem lehet tenni.
Itt már nincs két ember, itt már három ember van. Akarok valamit tőled, ez akar valamit egy harmadik személytől, a harmadik pedig tőlem. És végül háromféleképpen várunk, mert mindannyian arra várunk, hogy a másik személy befejezze, amit tennie kell.
És a Postgres tudja, hogy ez melyik sorban történik. Így a következő üzenet jelenik meg, amely azt mutatja, hogy olyan problémája van, ahol három bemenet blokkolja egymást. És itt nincsenek korlátozások. Ez akkor fordulhat elő, ha 20 bejegyzés blokkolja egymást.
A következő probléma a szerializálható.
Ha speciális szerializálható zár.
És visszatérünk a 719-hez. A kimenete teljesen normális.
És rákattinthat, hogy a tranzakció sorosíthatóvá váljon.
És rájössz, hogy most másfajta SA-zárral rendelkezel – ez azt jelenti, hogy sorba rendezhető.
Így van egy új típusú zárunk, a SARieadLock, amely egy soros zár, és lehetővé teszi a sorozatok bevitelét.
És egyedi indexeket is beszúrhat.
Ebben a táblázatban egyedi indexeink vannak.
Tehát ha beírom a 2-es számot, akkor van egy 2-esem. De a legtetején még egy 2-t teszek be. És láthatja, hogy a 721-nek van egy exkluzív zárja. De most a 722 arra vár, hogy a 721 befejezze a működését, mert nem tudja beszúrni a 2-t, amíg nem tudja, mi lesz a 721-gyel.
És ha résztranzakciót végzünk.
Itt van a 723.
És ha elmentjük a pontot, majd frissítjük, akkor új tranzakcióazonosítót kapunk. Ez egy másik viselkedési minta, amellyel tisztában kell lennie. Ha ezt visszaküldjük, akkor a tranzakcióazonosító eltűnik. 724 levél. De most 725-ünk van.
Szóval mit akarok itt csinálni? Megpróbálok példákat mutatni azokra a szokatlan zárakra, amelyeket esetleg találhat: legyen szó szerializálható zárakról vagy SAVEPOINT-ról, ezek különböző típusú zárak, amelyek megjelennek a zártáblázatban.
Ez explicit (explicit) zárolások létrehozása, amelyek rendelkeznek pg_advisory_lock.
És látja, hogy a blokkolás típusa tájékoztató jellegű. És itt pirossal azt írja, hogy „tanácsadó”. És egyidejűleg blokkolhat így a pg_advisory_unlock segítségével.
Végezetül pedig szeretnék még egy elgondolkodtató dolgot mutatni. Létrehozok egy másik nézetet. De csatlakozom a pg_locks táblához a pg_stat_activity táblához. És miért akarom ezt csinálni? Mert ez lehetővé teszi, hogy megnézzem és lássam az összes aktuális munkamenetet, és pontosan lássam, milyen zárakra várnak. Ez pedig egészen érdekes, ha összerakjuk a zártáblát és a lekérdezőtáblát.
És itt létrehozzuk a pg_stat_view-t.
És egyenként frissítjük a sort. És itt látjuk a 724-et. Aztán frissítjük a sort háromra. És mit látsz most itt? Ezek kérések, azaz a bal oldali oszlopban látható kérések teljes listája. És akkor a jobb oldalon láthatod az eltömődéseket és azt, hogy mit hoznak létre. És ez még egyértelműbbé válhat számodra, így nem kell minden alkalommal visszamenned minden ülésre, és megnézni, hogy csatlakoznod kell-e vagy sem. Megteszik helyettünk.
Egy másik nagyon hasznos funkció az pg_blocking_pids. Valószínűleg még soha nem hallottál róla. Mit csinál? Lehetővé teszi, hogy megmondjuk, hogy ehhez az 11740-es munkamenethez milyen konkrét folyamatazonosítókra vár. És láthatod, hogy az 11740 a 724-re vár. A 724 pedig a legtetején van. És az 11306 a folyamatazonosítód. Lényegében ez a funkció a zárasztalon megy keresztül. És tudom, hogy ez egy kicsit bonyolult, de sikerül megértened. Lényegében ez a funkció átmegy ezen a zártáblázaton, és megpróbálja megkeresni, hogy ez a folyamatazonosító hol kapja meg a várakozó zárakat. És azt is megpróbálja kitalálni, hogy a zárolásra váró folyamat melyik folyamatazonosítóval rendelkezik. Tehát futtathatja ezt a funkciót pg_blocking_pids.
És ez nagyon hasznos lehet. Ezt csak a 9.6-os verzióban adtuk hozzá, tehát ez a funkció még csak 5 éves, de nagyon-nagyon hasznos. És ugyanez vonatkozik a második kérésre is. Pontosan azt mutatja, amit látnunk kell.
Erről akartam beszélni veled. És ahogy vártam, minden időnket elhasználtuk, mert annyi csúszda volt. A diák pedig letölthető. Szeretném megköszönni, hogy itt vagy. Biztos vagyok benne, hogy élvezni fogja a konferencia további részét, köszönöm szépen!
Kérdések:
Például, ha megpróbálom frissíteni a sorokat, és a második munkamenet megpróbálja törölni a teljes táblát. Ha jól értem, valami szándékzárhoz hasonlónak kellene lennie. Van ilyen Postgresben?
Térjünk vissza a legelejére. Emlékezhet arra, hogy amikor bármit csinál, például amikor KIVÁLASZT, kiadunk egy AccessShareLock-ot. Ez pedig megakadályozza az asztal leejtését. Tehát, ha például frissíteni szeretne egy sort a táblázatban vagy törölni szeretne egy sort, akkor valaki nem tudja egyszerre törölni a teljes táblát, mert Ön az AccessShareLock funkciót a teljes táblán és a soron át tartja. És ha végzett, törölhetik. De amíg Ön közvetlenül megváltoztat valamit, ők nem fogják tudni megtenni.
Csináljuk mégegyszer. Térjünk át a törlési példára. És láthatja, hogy az egész asztal feletti sorban van egy exkluzív zár.
Ez zár exkluzívnak fog kinézni, igaz?
Igen, úgy néz ki. értem miről beszélsz. Azt akarod mondani, hogy ha megcsinálok egy SELECT-et, akkor van egy ShareExclusive-om, majd sorkizárólagossá teszem, akkor ez gondot jelent? De meglepő módon ez nem jelent problémát. Ez a zárolási fokozat növelésének tűnik, de lényegében van egy zárolásom, amely megakadályozza a törlést. És most, amikor ezt a zárat erősebbé teszem, továbbra is megakadályozza a törlést. Szóval nem mintha felmennék. Vagyis alacsonyabb szinten is megakadályozta, hogy ez megtörténjen, így ha emelem a szintjét, akkor is megakadályozza a tábla törlését.
értem miről beszélsz. Itt nincs záreszkalációs eset, amikor megpróbálja feladni az egyik zárat, hogy egy erősebbet vezessen be. Itt csak fokozza ezt a megelőzést az egész területen, így nem okoz konfliktust. De jó kérdés. Nagyon köszönöm, hogy ezt kérdezted!
Mit kell tennünk, hogy elkerüljük a holtpontot, amikor sok munkamenetünk van, sok felhasználónk van?
A Postgres automatikusan észleli a holtpontot. És automatikusan törli az egyik munkamenetet. Az egyetlen módja annak, hogy elkerüljük a holt blokkolást, ha az embereket ugyanabban a sorrendben blokkoljuk. Tehát ha megnézi a jelentkezését, gyakran a holtpontok oka... Képzeljük el, hogy két különböző dolgot szeretnék blokkolni. Az egyik alkalmazás zárolja az 1. táblázatot, egy másik pedig a 2. táblázatot, majd az 1. táblázatot. A holtpontok elkerülésének legegyszerűbb módja, ha megnézi az alkalmazást, és megpróbálja megbizonyosodni arról, hogy a zárolás ugyanabban a sorrendben történik az összes alkalmazásban. És ez általában a problémák 80%-át kiküszöböli, mert mindenféle ember írja ezeket a pályázatokat. És ha blokkolja őket ugyanabban a sorrendben, akkor nem találkozik patthelyzettel.
Nagyon szépen köszönöm a teljesítményét! Vákuum fullról beszéltél és ha jól értem a vákuum full torzítja a külön tárolóban lévő rekordok sorrendjét, így változatlanul tartják az aktuális rekordokat. Miért vesz igénybe a teljes vákuum kizárólagos zárolási hozzáférést, és miért ütközik az írási műveletekkel?
Ez egy jó kérdés. Ennek az az oka, hogy a vákuum tele van az asztallal. És lényegében a táblázat új verzióját hozzuk létre. És az asztal új lesz. Kiderült, hogy ez a táblázat teljesen új verziója lesz. És a probléma az, hogy amikor ezt tesszük, nem akarjuk, hogy az emberek elolvassák, mert szükségünk van rá, hogy lássák az új táblázatot. És ez kapcsolódik az előző kérdéshez. Ha tudnánk egyszerre olvasni, nem tudnánk áthelyezni és új asztalhoz irányítani az embereket. Meg kell várnunk, hogy mindenki befejezze a táblázat elolvasását, így ez lényegében egy zárolási exkluzív helyzet.
Csak azt mondjuk, hogy kezdettől fogva zároljuk, mert tudjuk, hogy a legvégén szükségünk lesz egy exkluzív zárra, hogy mindenkit áthelyezzünk az új példányra. Tehát ezt potenciálisan meg tudjuk oldani. És ezt így csináljuk egyidejű indexeléssel. De ezt sokkal nehezebb megtenni. És ez nagymértékben kapcsolódik az előző, zárolási exkluzív kérdésedhez.
Hozzáadható a zárolási időtúllépés a Postgreshez? Az Oracle-ben például azt írhatom, hogy "select to update" és várok 50 másodpercet a frissítés előtt. Jó volt a pályázatnak. De Postgresben vagy azonnal meg kell tennem, és egyáltalán nem kell várnom, vagy várnom kell egy ideig.
Igen, megadhat időtúllépést a zárakon, a zárakon. Kiadhat egy tiltó parancsot is, amely... ha nem tudja azonnal megszerezni a zárolást. Ezért vagy zárolási időtúllépés, vagy valami más, ami lehetővé teszi ezt. Ez nem szintaktikai szinten történik. Ez változóként történik a szerveren. Néha ez nem használható.
Ki tudod nyitni a 75. diát?
Igen.
A kérdésem pedig a következő. Miért vár mindkét frissítési folyamat 703-at?
És ez egy nagyszerű kérdés. Nem értem egyébként, hogy Postgres miért csinálja ezt. De amikor a 703-at létrehozták, 702-re számított. És amikor a 704 és 705 megjelenik, úgy tűnik, nem tudják, mit várnak, mert még nincs ott semmi. A Postgres pedig így csinálja: ha nem kapsz zárat, akkor azt írja ki, hogy „Mi értelme van feldolgozni?”, mert már vársz valakit. Szóval csak hagyjuk lógni a levegőben, nem frissíti egyáltalán. De mi történt itt? Amint a 702 befejezte a folyamatot, és a 703 megkapta a zárolását, a rendszer visszatért. És azt mondta, hogy most két emberünk van, akik várnak. És akkor frissítsük őket együtt. És jelezzük, hogy mindketten várnak.
Nem tudom, a Postgres miért csinálja ezt. De van egy probléma, amit f… Nekem úgy tűnik, hogy ez nem orosz nyelvű kifejezés. Ilyenkor mindenki egy kastélyra vár, még akkor is, ha 20 hatóság várja a kastélyt. És hirtelen mindannyian egyszerre ébrednek fel. És mindenki elkezd reagálni. De a rendszer úgy csinálja, hogy mindenki a 703-ra vár. Mert mindannyian várnak, és azonnal sorba állítjuk őket. És ha bármilyen más új kérés jelenik meg, ami ez után generált, például 707, akkor újra üres lesz.
És nekem úgy tűnik, hogy ez azért történik, hogy elmondhassuk, hogy ebben a szakaszban a 702-es a 703-asra vár, és aki ezután jön, annak nem lesz bejegyzése ezen a területen. De amint az első pincér távozik, mindazok, akik abban a pillanatban vártak a frissítés előtt, ugyanazt a tokent kapják. És ezért azt gondolom, hogy ez azért történik, hogy rendben tudjuk feldolgozni, hogy megfelelően legyenek rendezve.
Ezt mindig is elég furcsa jelenségnek tekintettem. Mert itt például egyáltalán nem soroljuk fel őket. De nekem úgy tűnik, hogy minden alkalommal, amikor új zárat adunk, megnézzük mindazokat, akik éppen várnak. Aztán sorba állítjuk mindet. És akkor minden új beérkező csak akkor kerül a sorba, amikor a következő személy feldolgozása befejeződött. Nagyon jó kérdés. Köszönöm szépen kérdését!
Számomra sokkal logikusabb, amikor a 705 704-et vár.
De a probléma itt a következő. Technikailag egyiket vagy másikat felébresztheti. És így egyiket vagy másikat felébresztjük. De mi történik a rendszerben? Láthatja, hogy a legfelső 703 hogyan blokkolta a saját tranzakcióazonosítóját. A Postgres így működik. A 703-at pedig a saját tranzakcióazonosítója blokkolja, tehát ha valaki várni akar, akkor a 703-ra vár. És lényegében a 703 befejeződik. És csak a befejezése után ébred fel az egyik folyamat. És nem tudjuk, hogy pontosan mi lesz ez a folyamat. Ezután mindent fokozatosan feldolgozunk. De nem világos, hogy melyik folyamat ébred fel először, mert ez bármelyik folyamat lehet. Lényegében volt egy ütemezőnk, amely azt mondta, hogy mostantól bármelyik folyamatot felébreszthetjük. Csak véletlenszerűen választunk egyet. Tehát mindkettőt meg kell jegyezni, mert bármelyiküket felébreszthetjük.
És a probléma az, hogy van CP-végtelenségünk. És ezért nagyon valószínű, hogy felébreszthetjük a későbbieket. És ha például felébresztjük a későbbieket, akkor azt várjuk, aki éppen megkapta a blokkot, így nem határozzuk meg, hogy pontosan kit ébresztenek fel először. Egyszerűen létrehozunk egy ilyen helyzetet, és a rendszer véletlenszerű sorrendben felébreszti őket.
Van . Nézd, ezek is érdekesek és hasznosak. A téma persze borzasztóan összetett. Köszönöm szépen, Bruce!
Forrás: will.com
