Unlocking the Postgres Lock Manager. Bruce Momjian

Bruce Momjian'i 2020. aasta ettekande "Unlocking the Postgres Lock Manager" tõlge.

(Märkus: Kõik SQL päringud slaididelt on saadaval sellelt lingilt: http://momjian.us/main/writings/pgsql/locking.sql)

Tere! On suurepärane olla taas Venemaal. Vabandan, et ei saanud eelmisel aastal tulla, kuid sel aastal on Ivanil ja mul suured plaanid. Loodan, et olen siin palju tihedamini. Ma armastan Venemaal käia. Kavas on külastada Tjumenit ja Tveri. Olen väga rõõmus, et mul on võimalus nendes linnades viibida.

Minu nimi on Bruce Momjian. Töötan EnterpriseDB-s ja olen Postgresiga tegelenud enam kui 23 aastat. Elan Philadelphias, USA-s. Reisin umbes 90 päeva aastas. Külastan ligikaudu 40 konverentsi. Minu vebsait, mis sisaldab slaide, mida ma teile praegu näitan. Seega pärast konverentsi saate need minu isiklikult veebisaidilt alla laadida. Seal on ka umbes 30 esitlust. Samuti leidub videosid ja üle 500 blogipostituse. See on tõeliselt sisutihe ressurss. Ja kui see materjal teid huvitab, kutsun teid seda kasutama.

Olen varem olnud õpetaja, professor, enne kui hakkasin Postgresiga tegelema. Olen väga rõõmus, et mul on võimalus rääkida teile sellest, mida ma kavatsen rääkida. See on üks minu kõige huvitavamaid ettekandeid. See ettekande koosneb 110 slaidist. Alustame lihtsate asjadega, aga ettekande lõpus muutub see järjest keerulisemaks.

See on üsna ebameeldiv vestlus. Lukustamine ei ole just populaarne teema. Me tahame, et see kaoks. See on nagu hambaarsti juures käimine.

1. Lukustamine on probleem paljudele, kes töötavad andmebaasidega ja kellel on samaaegselt mitu protsessi. Nad vajavad lukustamist. Seega, täna annan ma teile põhiteadmised lukustamisest.
2. Tehinguidentifikaatorid. See on üsna igav osa esitlusest, kuid see on hädavajalik mõista.
3. Ja edasi räägime lukustamise liikidest. See on piisavalt mehaaniline osa.
4. Ja seejärel tutvustame mõningaid lukustamise näiteid. See on küllaltki keeruline teema.

Räägime lukustamisest.

Meie terminoloogia on piisavalt keeruline. Kui palju teist teab, kust see katkend pärineb? Kaks inimest. See on mängust nimega „Kolossaalsed seiklused koopas“. See oli teksti põhine arvutimäng 80-ndatel, ma arvan. Seal pidi minema koopasse, labürinti ja tekst muutus, kuid sisu oli iga kord umbes sama. Nii mäletan ma seda mängu.

Siin näeme blokeeringute nimetusi, mis on meile tulnud Oracle'ist. Me kasutame neid.

Siin on terminid, mis mind häirivad. Näiteks SHARE UPDATE ECXLUSIVE. Järgmine on SHARE RAW ECXLUSIVE. Ausalt öeldes, need nimed pole väga arusaadavad. Püüame neid üksikasjalikumalt vaadata. Mõned sisaldavad sõna „share“, mis tähendab – eralduda. Mõned sisaldavad sõna „exclusive“ — eksklusiivne. Mõned sisaldavad mõlemat sõna. Tahaksin alustada sellest, kuidas need blokeeringud töötavad.

Samuti on väga oluline sõna „dostup“ — access. Ja sõna „row“ — rida. Ehk siis juurdepääsu ja ridade jaotamine.

Veel üks probleem, mida Postgreses mõista on vajalik, kuid millest ma kahjuks oma ettekandes rääkida ei saa, on MVCC. Mul on sellel teemal eraldi esitlus minu veebisaidil. Ja kui arvate, et see esitlus on keeruline, siis MVCC on tõenäoliselt minu kõige keerulisem teema. Kui olete huvitatud, võite selle veebisaidilt vaadata. Saate vaadata ka videot.

Veel üks punkt, mida peame mõistma – on tehinguidentifikaatorid. Paljud tehingud ei saa töötada ilma ainulaadsete identifikaatoriteta. Ja siin anname selgituse, mis on tehing. Postgreses on kaks tehingu numeratsiooni süsteemi. Ma tean, et see ei ole väga ilus lahendus.

Pange tähele, et slaidid on suhteliselt keerulised, seega tuleks pöörata erilist tähelepanu sellele, mis on punase värviga esile tõstetud.

http://momjian.us/main/writings/pgsql/locking.sql

Vaadake. Punase värviga on esile tõstetud tehingu number. Siin on näidatud funktsioon SELECT pg_back. See tagastab minu tehingu ja selle tehingu ID.

Veel on oluline, kui teile meeldib see esitlus ja soovite selle oma andmebaasis käivitada, siis saate klikata sel roosaga esile tõstetud lingil ning alla laadida selle esituse SQL. Ja te saate lihtsalt käivitada selle oma PSQL-is ning kogu esitlus ilmub teile ekraanile viivitamatult. See ei sisalda värve, kuid vähemalt saame selle siiski näha.

Selles olukorras näeme tehingu ID-d. See on number, mille me sellele määrasime. Ja Postgresis on veel üks tehingu ID tüüp, mida kutsutakse virtuaalseks tehingu ID-ks.

Ja me peame seda mõistma. See on väga oluline, vastasel juhul ei suuda me Postgresis lukustamist mõista.

Virtuaalne tehingu ID on tehingu ID, mis ei sisalda püsivaid väärtusi. Näiteks kui ma kasutan SELECT käsku, siis tõenäoliselt ei muuda ma andmebaasi, ma ei blokeeri midagi. Seega, kui käivitame lihtsa SELECT-i, ei anna me sellele tehingule püsivat ID-d. Anname sellele vaid virtuaalse ID.

Ja see suurendab Postgresi jõudlust, parandades puhastamisvõimalusi, seega koosneb virtuaalne tehingu ID kahest numbrist. Esimene number enne kaldkriipsu on bakenidi ID. Ja paremal pool näeme lihtsalt loendurit.

Seega, kui ma käivitangi päringu, ütleb see, et bakenidi ID on 2.

Ja kui ma käitan selliseid tehingute seeriat, siis näeme, et loendur suureneb iga kord, kui ma päringu käivitada. Näiteks, kui ma käitan päringut 2/10, 2/11, 2/12 jne.

Pange tähele, et siin on kaks veergu. Vasakul näeme virtuaalset tehingu ID-d – 2/12. Ja paremal on meil püsiv tehingu ID. Ja see väli on tühi. Ja see tehing ei muuda andmebaasi. Seega ei anna ma sellele püsivat tehingu ID-d.

Niipea kui ma käitan analüüsi käsku (ANALYZE), annab sama päring mulle püsiva tehingu ID. Vaadake, kuidas see on muutunud. Varem ei olnud mul seda ID-d, nüüd on see olemas.

Nii et siin on veel üks päring, veel üks tehing. Virtuaalne tehingu number on 2/13. Ja kui ma küsin püsivat tehingu ID-d, siis kui käivitan päringu, saan selle.

Nii et veel kord. Meil on virtuaalne tehingu ID ja püsiv tehingu ID. Lihtsalt mõistke seda, et mõista Postgresi käitumist.

Liigume kolmandasse jaossa. Siin vaatleme erinevaid lukustustüüpe Postgresis. See ei ole väga huvitav. Kuid viimane jaos on palju huvitavam. Siiski peame vaatama põhilisi asju, vastasel korral ei mõista me seda, mis tuleb edasi.

Me vaatame seda jaotust, iga lukustustüübi vaatlemiseks. Näitan teile näiteid, kuidas need seadistatakse, kuidas need töötavad, ning näitan teile mõningaid päringuid, mida saab kasutada lukustuse toimimise jälgimiseks Postgresis.

Küsimuse esitamiseks ja Postgresis toimuva jälgimiseks peame küsima süsteemi vaate kaudu. Antud juhul on meil punase värviga esile toodud pg_lock. Pg_lock on süsteemitabel, mis ütleb meile, milliseid lukustusi kasutatakse Postgresis.

Kuid mul on väga keeruline näidata teile pg_lock'i iseenesest, kuna see on üsna keeruline. Seetõttu olen loonud vaate, mis näitab pg_locks'i. Samuti täidab see minu jaoks teatud ülesannet, mis aitab mul paremini mõista. St see jätab välja minu lukustused, minu enda seansi jne. See on lihtsalt tavaline SQL ja aitab mul näidata, mis toimub.

Teine probleem on see, et see vaade on väga lai, seetõttu pean looma teise – lockview2.

Ja see näitab mulle veel veerge tabelist. Veel üks, mis näitab mulle teisi veerge. See on piisavalt keeruline, seega püüdsin seda esitada võimalikult lihtsalt.

Nii et lõime tabeli nimega Lockdemo. Ja seal on üks rida. See on meie näidistabel. Loomeme jaotisi lihtsalt selleks, et näidata teile lukustuse näiteid.

Nii et üks rida, üks veerg. Esimene lukustustüüp on ACCESS SHARE. See on kõige vähem piirav lukustus. See tähendab, et see ei konfliktis praktiliselt teiste lukustustega.

Ja kui me tahame selgelt määratleda blokeerimise, siis käivitame käsu «lock table». Ja see blokeerib selgelt, st ACCESS SHARE režiimis käivitame lock table. Ja kui ma käivitan PSQL taustal, siis käivitangi sel viisil teise seansi oma esimesest seansist. St mida ma siin teen? Ma lähen teise seanssi ja ütlen talle «näita mulle lockview selle päringu jaoks». Ja siin on mul AccessShareLock selles tabelis. See on täpselt see, mida ma küsisin. Ja ta ütleb, et blokeering on antud. Väga lihtne.

Edasi, kui vaatame teist veergu, siis seal ei ole midagi. Need on tühjad.

Ja kui ma käivitun käsu «SELECT», siis see on implitsiitne (selge) viis küsida AccessShareLocki. Seetõttu vabastan oma tabeli ja käivitun päringu, ja päring tagastab mitu rida. Ja ühes ridast näeme AccessShareLocki. Nii et SELECT kutsub tabelis esile AccessShareLocki. Ja see ei konflikti praktiliselt millegagi, sest see on madala taseme blokeering.

Mis juhtub, kui käivitan SELECT ja mul on kolm erinevat tabelit? Varem käivitasin ainult ühe tabeli, nüüd käivitan kolm: pg_class, pg_namespace ja pg_attribute.

Ja nüüd, kui vaatan päringut, näen kolme tabeli peale 9 AccessShareLocki. Miks? Sinise värviga on esile tõstetud kolm tabelit: pg_attribute, pg_class, pg_namespace. Kuid võite näha, et kõik indeksid, mis on määratletud nende tabelite kaudu, omavad samuti AccessShareLocki.

Ja see on blokeering, mis praktiliselt ei konflikti teistega. Ja kõik, mida ta teeb, on lihtsalt see, et ta ei luba meil tabelit kustutada, kuni me seda vaatame. See on mõistetav. St kui me valime tabeli, siis see hetkel kaob, see on vale, seega AccessShare – see on madala taseme blokeering, mis ütleb meile "ärge kustutage seda tabelit, kuni ma töötan".. Sisuliselt on see kõik, mida ta teeb.

ROW SHARE – see blokeering on veidi erinev.

Võtame näite. SELECT ROW SHARE viib iga rea blokeerimise eraldi.. Nii et keegi ei saa neid kustutada ega muuta, kuni me neid vaatame.

Nii et, mida teeb SHARE LOCK? Me näeme, et tehingu ID 681 on SELECT jaoks. Ja see on huvitav. Mis meil siin juhtus? Esmakordselt näeme numbrit väli "Lock". Me võtame tehingu ID, ja see ütleb, et see lukustab selle eksklusiivses režiimis. Kõik, mida ta teeb, on ütlemine, et mul on rida, mis on tehniliselt kuskil tabelis lukustatud. Aga ei ütle, kus täpselt. Veidi hiljem vaatame seda lähemalt.

Siin räägime, et lukustus on meie poolt kasutusel.

Nii et, eksklusiivne lukustus ütleb selgelt, et see on eksklusiivne. Ja samuti, kui kustutate rea selles tabelis, siis just see juhtub, nagu te võite näha.

SHARE EXCLUSIVE – see on pikem lukustus.

See (ANALYZE) on analüüsi käsk, mida kasutatakse.

SHARE LOCK – võite ekspressiivselt lukustada jagamisrežiimis.

Saate luua ka unikaalse indeksi. Ja seal näete SHARE LOCKi, mis on osa sellest. Ja see lukustab tabeli ning seab sellele SHARE LOCK-i.

Vaikimisi tähendab SHARE LOCK tabelis, et teised inimesed võivad tabelit lugeda, kuid keegi ei saa seda muuta. Ja just see juhtub, kui loote unikaalse indeksi.

Kui ma loon unikaalse concurrently indeksi, siis mul on teine tüüpi lukustus, sest nagu te mäletate, vähendab concurrently indeksite kasutamine lukustusnõudeid. Ja kui kasutan tavalist lukustust, tavalist indeksit, siis takistan nii indeksi kirjutamist tabelisse selle loomise ajal. Kui kasutan concurrently indeksit, siis pean kasutama teist tüüpi lukustust.

SHARE ROW EXCLUSIVE – jälle saab seda määrata ekspressiivselt.

Või saame luua reegli, st võtta mingi kindla juhu, mille puhul seda kasutatakse.

EXCLUSIVE lukustus tähendab, et keegi teine ei saa tabelit muuta.

Siin näeme erinevaid lukustusi.

ACCESS EXCLUSIVE, näiteks, on lukustus käsk. Näiteks, kui teete CLUSTER table, siis see tähendab, et keegi ei saa sinna kirjutada. Ja see lukustab mitte ainult tabeli, vaid ka indeksid.

See on ACCESS EXCLUSIVE lukustuse teine leht, kus me näeme konkreetselt, mida see tabelis lukustab. See lukustab eraldi rea tabelis, mis on päris huvitav.

See kõik põhiteave, mida ma tahtsin anda. Oleme rääkinud lukudest, tehingu ID-dest, virtuaalsetest tehingu ID-dest ja püsivatest tehingu ID-dest.

Nüüd vaatame lukke näidete kaudu. See on kõige huvitavam osa. Uurime väga huvitavaid juhtumeid. Minu ülesanne selles esituses on anda teile parem arusaam sellest, mida Postgres tõeliselt teeb, kui ta üritab lukustada erinevaid asju. Minu arvates oskab ta väga hästi lukustada üksikuid osi.

Vaatame konkreetseid näiteid.

Alustame tabelitest ja ühest reast tabelis. Kui ma midagi sisestan, kuulen ExclusiveLock'i, tehingu ID-d ja ExclusiveLock'i tabelil.

Aga mis juhtub, kui sisestan veel kaks rida? Nüüd on meie tabelis kolm rida. Kui ma sisestan ühe rea ja saan sellise väljundi. Ja kui ma sisestan veel kaks rida, mis siin on veider? Siin on imelikkus, kuna ma lisasin kolm rida sellele tabelile, kuid mul on endiselt kaks rida lukustustabelis. Ja see on põhimõtteliselt Postgresi aluseline käitumine.

Paljud arvavad, et kui andmebaasis lukustad 100 rida, siis pead looma 100 lukustuse sissekannet. Kui ma lukustan korraga 1 000 rida, siis tahan 1 000 sellist päringut. Ja kui ma pean lukustama miljon või miljard. Kuid kui me seda teeme, siis see ei tööta hästi. Kui oled kasutanud süsteemi, mis loob lukustuse sissekande iga üksiku rea jaoks, siis näed, et see on keeruline. Sest pead kohe määrama lukustustabeli, mis võib täituda, aga Postgres nii ei tee.

Ja slaidil on väga oluline, et siin näidatakse selgelt, et on olemas veel üks süsteem, mis töötab MVCC sees, mis lukustab üksikuid reade. Seega, kui lukustate miljardeid reade, ei loo Postgres miljardit eraldi lukustamise käsku. Ja see mõjub väga hästi jõudlusele.

Aga kuidas on uuendustega? Ma praegu uuendan rida ja te võite märkida, et see tegi kohe kaks erinevat operatsiooni. Ta blokeeris tabeli samal ajal, aga ta blokeeris ka indeksi. Ja tal oli vaja blokeerida indeksi, kuna sellele tabelile on seatud unikaalsed piirangud. Ja me tahame veenduda, et keegi seda ei muuda, seetõttu me selle blokeerime.

Aga mis juhtub, kui ma tahan uuendada kahte rida? Ja me näeme, et see käitub samuti. Me teeme kaks korda rohkem uuendusi, kuid täpselt sama palju ridade blokeeringuid.

Kui teid huvitab, kuidas Postgres seda teeb, peate kuulama mu ettekandeid MVCC-st, et teada saada, kuidas Postgres sisemiselt tähistab neid rive, mida ta muudab. Ja Postgresel on viis, kuidas ta seda teeb, kuid ta ei tee seda tabelite blokeerimise tasemel, ta teeb seda madalamal ja efektiivsemal tasemel.

Aga kui ma tahan midagi kustutada? Kui ma kustutan näiteks ühe rida ja mul on ikkagi minu kaks algset blokeeringut, ning isegi kui ma tahaksin need kõik eemaldada, on need ikkagi seal.

Ja näiteks, kui ma tahan lisada 1 000 rida ja siis kustutada või lisada veel 1 000 rida, siis need individuaalsed read, mida ma lisasin või muutsin, ei salvestata siia. Need salvestatakse madalamal tasemel seesama rida. Ja MVCC ettekandes rääkisin ma sellest üksikasjalikult. Kuid on väga oluline, et analüüsite blokeeringuid, et tagada, et teil on tabeli tasemel blokeering ja et siin ei ole näha, kuidas mõned üksikud read salvestatakse.

Aga kuidas on eksplicitse blokeerimisega?

Kui ma vajutan 'uuenda', siis mul on kaks blokeeritud rida. Ja kui ma valin need kõik ja vajutan 'uuenda kõikjal', siis mul jääb endiselt kaks blokeerimisrekordit.

Me ei loo eraldi kirjeid igaühe jaoks eraldi rida. Sest siis langeb jõudlus, seal võib olla liiga palju. Ja me võime sattuda ebamugavasse olukorda.

Ja sama kehtib, kui me teeme shared, me võime teha kõigi 30 korda.

Me taastame oma tabeli, kõik eemaldame, siis lisame uuesti ühe rida.

Teine käitumisviis, mida näete Postgres'is, on väga hästi tuntud ja soovitud käitumine – saate teha update või select. Ja te saate neid teha samaaegselt. Select ei blokeeri update'id ja sama kehtib ka vastupidiselt. Me ütleme, et lugeja ei blokeeri kirjutajat ja kirjutaja ei blokeeri lugejat.

Ma näitan teile selle näidet. Ma teen praegu valiku. Seejärel teeme INSERT. Ja te saate näha – 694. Te näete tehingu ID-d, mis tegi selle insert'i. Ja see on see, kuidas see töötab.

Ja kui ma nüüd vaatan oma tagaosa ID-d, siis see on – 695.

Ja ma näen, et 695 ilmub minu tabelisse.

Ja kui ma teen siin uuenduse, siis saan teise juhtumi. Sellisel juhul on 695 eksklusiivne lukustus ja update'l on sama käitumine, kuid nende vahel ei teki konflikte, mis on piisavalt ebatavaline.

Ja võite märgata, et üleval on ShareLock ja all on ExclusiveLock. Ja mõlemad tehingud said läbi.

Ja peate kuulama minu ettekannet MVCC teemal, et mõista, kuidas see toimub. Kuid see on illustratsioon sellele, et saate neid samaaegselt teha, st samaaegselt teha SELECT ja UPDATE.

Laske meil lähtestada ja teha veel üks tehing.

Kui proovite samaaegselt käivitada kaks update'i samal real, siis see lukustub. Ja pidage meeles, et ma ütlesin, et lugeja ei blokeeri kirjutajat, vaid kirjutaja blokeerib lugeja, kuid üks kirjutaja blokeerib teist kirjutajat. St me ei saa lasta kahte inimest samaaegselt uuendada sama rida. Peab ootama, kuni üks neist lõpetab.

Ja selle illustreerimiseks vaatan Lockdemo tabelit. Ja vaatame ühte rida. Tehingut 698.

Me uuendasime selle 2 peale. 699 – see on esimene uuendus. Ja see läks edukalt läbi või see on ootel tehingus ja ootab, kuni me selle kinnitame või tühistame.

Aga vaadake teist – 2/51 – see on meie esimene tehing, meie esimene sessioon. 3/112 – see on teine päring, mis ilmus ülal ja mis muutsid selle väärtuse kolme peale. Ja kui te märkate, siis ülemine jättis ennast lukku, millel on ID 699. Kuid 3/112 ei saanud lukku. Veerus Lock_mode on kirjutatud, et ta ootab. Ta ootab 699. Ja kui te vaatate, kus on 699, on ta üleval. Ja mida esimest sessiooni tegi? Ta lõi eksklusiivse lukku omaenda tehingu ID-l. Just nii teeb Postgres. Ta blokeerib oma tehingu ID. Ja kui te soovite Oodata, kuni keegi kinnitab või tühistab, siis peate ootama, kuni seal on ootel tehing. Ja seetõttu saame näha kummalist rida.

Vaadakem veel kord. Vasakul näeme meie töötlemise ID-d. Teises veerus näeme meie virtuaalse tehingu ID-d ja kolmandas näeme lock_type'i. Mida see tähendab? Fondamentaalselt ütleb, et see blokeerib tehingu ID-d. Kuid märkige, et kõikides ridades üleval on kirjutatud relation. Ja seetõttu on teil tabelis kaks tüüpi blokeeringut. On relation-lukustus. Samuti on tehingu ID lukustus, kus me blokeerime ise, see on just see, mis toimub esimeses reas või kõige alumises, kus transationid, kus me ootame, et 699 lõpetaks oma operatsiooni.

Mina vaatan, kuidas asjad lähevad. Ja siin toimub samaaegselt kaks asja. Te vaatate lukustamist tehingu ID-l esimeses reas, mis blokeerib iseennast. Ja ta blokeerib iseennast, et sundida inimesi ootama.

Kui te vaatate 6. rida, siis see sama kirje, mis on esimeses. Ja seetõttu on tehing 699 blokeeritud. Samuti blokeerib 700 ennast. Ja siis näete alumises reas, et ootame, kuni 699 lõpetab oma operatsiooni.

Ja lock_type, tuple, näete numbreid.

Te näete, et see on 0/10. Ja see on lehe number, samuti ka selle konkreetse rea offset.

Ja te näete, et see saab 0/11, kui me uuendame.

Aga tegelikult – see on 0/10, kuna ootamine toimib selle operatsiooni kallal. Meil on võimalus vaadata, et see on see rida, mida ma ootan, et kinnitada.

Kui me selle kinnitasime ja commit-nuppu vajutasime, ning värskendus lõpetas, saame me jälle sama. Tehing 700 on ainus lukustus, ta ei oota enam kedagi, kuna see on commititud. Ta ootab vaid, kuni tehing lõpetatakse. Kui 699 lõpeb, ei oota me enam kedagi. Ja nüüd ütleb tehing 700, et kõik on korras, et kõik vajalikud lukustused on tal kõikides lubatud tabelites.

Ja et seda kõike veel keerulisemaks teha, loome me veel ühe vaate, mis seekord annab meile hierarhia. Ma ei oota, et te seda päringut mõistate. Kuid see annab meile selgema ülevaate, mis toimub.

See on rekursiivne vaade, millel on veel üks sektsioon. Ja see toob kõik tagasi kokku. Kasutame seda.

Mis juhtub, kui me teeme kolm samaaegset värskendust ja ütleme, et rida on nüüd kolme võrra suurem. Ja vahetame 3 4 vastu.

Ja nüüd näeme 4. Ja tehingu ID 702.

Ja siis vahetan 4 5 vastu. Ja 5 6, ja 6 7. Ja ma panen ritta inimesed, kes ootavad, et see üks tehing õnnestuks.

Ja kõik muutub selgeks. Mis on esimene rida? See on 702. See on tehingu ID, mis algselt selle väärtuse seadmiseks määrati. Ja mis mul on kirjas veerus Granted? Mul on seal märgid. f. Need on minu värskendused (5, 6, 7), mis ei saa kinnitust, sest me ootame, et tehingu ID 702 lõpeks. Seal on meil tehingu ID lukustus. Ja kokku tuleb 5 tehingu lukustus ID-d.

Ja kui te vaatate 704, 705, siis seal ei ole veel midagi kirjas, sest nad ei tea veel, mis toimub. Nad lihtsalt kirjutavad, et ei tea, mis toimub. Ja nad lähevad lihtsalt unne, sest nad ootavad, kuni keegi lõpetab ja äratab nad, kui tekib võimalus rida vahetada.

Nii see välja näeb. Selge on see, et nad kõik ootavad 12. rida.

See on see, mida me siin nägime. Siin on 0/12.

Nii et niipea, kui esimene tehing kinnitatakse, saate siin näha, kuidas hierarhia töötab. Ja nüüd on kõik selge. Nad kõik saavad puhtaks. Ja nad on tegelikult endiselt ootamas.

Nii see läheb. 702 on toimetamisel. Nüüd saab 703 selle rea lukustuse ja pärast seda hakkab 704 ootama, kuni 703 lõpetab toimetamise. Ja 705 ootab samuti. Kui kõik see on lõpule viidud, siis nad puhastavad end ise. Tahaksin märkida, et kõik seisavad järjekorras. See meenutab olukorda ummikus, kus kõik ootavad esimest autot. Esimene auto peatus ja kõik järgnevad seisavad pikalt reas. Siis see liigub edasi, järgmine auto saab siis edasi liikuda ja oma lukustuse jne.

Ja kui see tundub teile ebapiisavalt keeruline, räägime nüüd deadlockidest. Ma ei tea, kui palju teist on nende vastu puutunud. See on piisavalt levinud probleem andmebaasisüsteemides. Deadlockid tekivad siis, kui üks sessioon ootab, et teine sessioon midagi teeks. Samal ajal ootab teine sessioon, et esimene sessioon midagi teeks.

Ja näiteks, kui Ivan ütleb: "Anna mulle midagi" ja mina ütlen: "Ei, ma annan sulle seda ainult siis, kui sa annad mulle midagi teist." Ja ta ütleb: "Ei, ma ei anna seda, kui sa ei anna mulle." Jõuame murtud lukustuse olukorda. Olen kindel, et Ivan ei teeks nii, kuid te mõistate mõtte, et meil on kaks inimest, kes tahavad midagi saada ja nad ei ole valmis seda andma, kuni teine inimene neile seda ei anna. Ja siin ei ole lahendust.

Eessential on, et teie andmebaas tuvastaks need olukorrad. Seejärel tuleb eemaldada või lõpetada üks sessioon, sest vastasel juhul jäävad nad sinna igavesti. Me näeme seda andmebaasides, operatsioonisüsteemides ja kõikjal, kus meil on paralleelsed protsessid.

Ja nüüd paigutame kaks deadlocki. Asetame 50 ja 80. Esimeses real loon värskenduse 50-le 50-ks. See toob välja tehingu numbri 710.

Seejärel muudan 80 81-ks ja 50 51-ks.

Ja nii see välja näeb. Seetõttu on 710-l rea lukustus ja 711 ootab kinnitust. Oleme seda varem näinud, kui värskendused toimusid. 710 on meie rea omanik. Ja 711 ootab, kuni 710 lõpetab tehingu.

Seal on isegi kirjas, millisel täpselt real meil deadlock toimub. Ja siin hakkab see kummaliseks muutuma.

Nüüd värskendame 80 80-ks.

Ja nüüd saavad alguse ummikud. 710 ootab 711 vastust, samas kui 711 ootab 710-d. See ei lõpe hästi. Ja sellest pole väljapääsu. Nad ootavad üksteiselt vastust.

See lihtsalt hakkab kõike aeglustama. Me ei soovi seda.

Postgresis on viise, kuidas märkida, kui see juhtub. Ja kui see juhtub, siis saad sellise veateate. Selgub, et üks protsess ootab SHARED LOCK-i teiselt protsessilt, st see, mis blokeerib 711. Ja see protsess ootas SHARED LOCK-i teatud tehingu ID jaoks ning oli blokeeritud mingi protsessi poolt. Nii et siin on olukord ummikus.

Kas on olemas ka kolmeosalisi ummikuid? Kas see on võimalik? Jah.

Sisestame need numbrid tabelisse. Muudame 40 40-ks, teeme blokeeringu.

Muudame 60 61-ks, 80 81-ks.

K seejärel muudame 80, ja siis - bum!

Nüüd ootab 714 715-d. 716 ootab 715-d. Ja seda ei saa enam parandada.

Siin pole enam kahte inimesena, vaid kolm inimest. Ma tahan sinult midagi, see tahab kolmandalt inimeselt midagi, ja kolmas inimene tahab minult midagi. Ja meil on kolmepoolne ootus, sest kõik ootame, kuni teine inimene lõpetab selle, mida ta peab tegema.

Postgres teab, millisel real see juhtub. Seega annab see teile järgmise sõnumi, kus näidatakse, et teil on probleem, kus kolm sisendit blokeerivad üksteist. Ja siin pole piiranguid. See võib juhtuda, kus 20 kirjet blokeerivad üksteist.

Järgmine probleem on serialiseeritavus.

Kui on eriline serialiseeritav blokeering.

Ja naaseme 719 juurde. Sellel on täiesti normaalne väljund.

Ja saate vajutada, et teha tehing serialiseeritava formaadiga.

Nüüd mõistate, et teil on teine blokk SA - see tähendab serialiseeritav.

Seega on meil uus blokeeringu liik, mida nimetatakse SARieadLock, mis on järjekindel blokeering ja lubab sisestada seerianumbrid.

Samuti võite sisestada unikaalseid indekseid.

Selles tabelis on meil unikaalsed indeksid.

Seega, kui ma sisestan siia numbri 2, siis mul on 2. Kuid kõige ülal oleval joonisel sisestan veel ühe 2. Näete, et 721-l on eksklusiivne blokeering. Kuid nüüd ootab 722, et 721 lõpetaks oma operatsiooni, sest ta ei saa 2-d sisestada, enne kui ei tea, mis juhtub 721-ga.

Ja kui teeme alatehingu.

Siin on meil 723.

Ja kui me säilitame punkti ja siis värskendame seda, siis saame uue tehingu ID. See on veel üks käitumismuster, millest peate teadma. Kui me selle tagasi anname, siis tehingu ID kaob. 724 kaob. Kuid nüüd on meil 725.

Ja mida ma siin püüan teha? Püüan näidata teile näiteid ebatavalisest lukustamisest, mida võite kohata: olgu need serializable lukud või SAVEPOINT - need on erinevad lukustamisvõimalused, mis ilmuvad lukustamisdiagrammi.

See on eksplicitsete (selgete) lukustamiste loomine, kus asub pg_advisory_lock.

Ja näete, et lukustamise tüüp on siin loetletud kui advisory. Ja siin on punasega kirjutatud „advisory“. Ja te saate samaaegselt lukustada pg_advisory_unlock.

Ja lõpetuseks tahaksin teile näidata veel ühte hämmastavat asja. Loome veel ühe tüübi. Kuid vormin pg_locks tabeli pg_stat_activity tabeliga. Ja miks ma seda teha tahan? Sest see võimaldab mul vaadata ja näha kõiki praegusi sessioone ning näha, milliseid lukke nad ootavad. Ja see on piisavalt huvitav, kui me kogume lukustamisdiagrammi ja päringute diagrammi kokku.

Ja siin loome pg_stat_view.

Ja me värskendame rida ühe võrra. Ja siin näeme 724. Seejärel värskendame meie rea kolme peale. Ja mida te siit praegu näete? Need on päringud, st näete kogu päringute nimekirja, mis on loetletud vasakus veerus. Ja siis paremal pool näete lukustusi ja seda, mida need loovad. See võib olla teile arusaadav, et pole vajadust iga kord tagasi minna igasse sessiooni ja vaadata - kas on vaja liituda või mitte. Meie eest teevad nad seda.

Veel üks väga kasulik funktsioon on pg_blocking_pids. Te ei pruugi sellest kunagi kuulnud olla. Mida see teeb? See võimaldab meil öelda, et seansi 11740 jaoks ootab see täpselt neid protsessi ID'sid. Ja te näete, et 11740 ootab 724. Ja 724 on kõige üleval. Ja 11306 on teie protsessi ID. Sisuliselt läbib see funktsioon teie lukutustabelit. Ja ma tean, et see on veidi keeruline, kuid te mõistate seda. Sisuliselt läbib see funktsioon selle lukutustabeli ja püüab leida, kus see protsessi ID on, arvestades neid lukustusi, mida ta ootab. Samuti püüab ta arvutada, milline protsessi ID on selle protsessi puhul, mis ootab lukustusi. Nii et te saate selle funktsiooni käivitada pg_blocking_pids.

Ja see on väga kasulik. Me lisasime selle alles versioonist 9.6, seega on see funktsioon vaid 5 aastat vana, kuid see on väga ja väga kasulik. Sama kehtib ka teise päringu kohta. See näitab täpselt seda, mida me peame nägema.

See on see, millest ma tahtsin teiega rääkida. Nagu ma ootasin, kulutasime kogu meie aja, sest slaide oli nii palju. Slaidid on allalaadimist ootamas. Ma tahan teid tänada, et olite siin. Olen kindel, et teile meeldib konverentsi ülejäänud osa, suur tänu!

Küsimused:

Näiteks, kui ma proovin ridu uuendada, ja teine sessioon proovib kogu tabelit kustutada. Niikaua kui ma aru saan, peaks seal olema midagi nagu intent lock. Kas Postgreses on midagi sellist?

Naaseme algusesse. Võib-olla mäletate, et kui teete midagi, näiteks SELECT, siis anname AccessShareLock'i. Ja see takistab tabeli kustutamist. Seega, kui soovite näiteks tabelis rida uuendada või rida kustutada, ei saa keegi samal ajal kogu tabelit kustutada, sest te hoiate selle AccessShareLock'i kogu tabeli ja rea üle. Ja niipea kui olete lõpetanud, saavad nad selle kustutada. Kuid seni, kuni te seal midagi muutate, ei saa nad seda teha.

Teeme veel kord. Liigume kustutamise näite juurde. Ja te näete, kuidas reaal on eksklusiivne lukustus kogu tabeli üle.

See näeb välja nagu eksklusiivne lukustus, eks ole?

Jah, see näeb välja nagu see. Ma mõistan, millest te räägite. Te ütlete, et kui ma teen SELECT-i, siis on mul ShareExclusive, ja kui ma muudan selle Row Exclusive-iks, kas see tekib probleem? Kuid üllatavalt see ei tekita probleemi. See on nagu lukustustaseme tõstmine, kuid tegelikult on mul lukustus, mis takistab kustutamist. Ja nüüd, kui ma teen selle luku tugevamaks, takistab see endiselt kustutamist. Seega ei ole see nii, et ma tõusen üles. St. see takistas seda ja kui see oli madalamal tasemel, seega, kui ma tõstsin selle taset, takistab see endiselt tabeli kustutamist.

Ma mõistan, millest te räägite. Siin ei ole olukorda, kus lukustustaset tõstetakse, kus te proovite loobuda ühest lukustusest, et tutvustada võimsamat. Siin see lihtsalt suurendab selle takistuse ulatust, seega see ei põhjusta mingit konflikti. Aga see on hea küsimus. Suur tänu, et selle küsisite!

Mida peame tegema, et vältida deadlocki olukorda, kui meil on palju sessioone, suur kasutajate arv?

Postgres märkab automaatselt deadlocki olukordi. Ja automaatselt eemaldab ühe sessioonidest. Ainus viis, kuidas aidata vältida deadlocki, on blokeerida inimesi samas järjestuses. Seega, kui vaatate oma rakendust, on tihti deadlockide põhjus... Oletame, et ma tahan blokeerida kaks erinevat asja. Üks rakendus blokeerib tabeli 1, teine rakendus blokeerib 2 ja seejärel tabeli 1. Ja kõige lihtsam viis deadlockide vältimiseks on vaadata oma rakendust ja püüda tagada, et blokeerimine toimub kõigis rakendustes samas järjekorras. Ja see tavaliselt eemaldab 80% probleemidest, sest erinevad inimesed kirjutavad neid rakendusi. Ja kui blokite neid samas järjekorras, ei satu te deadlocki olukorda.

Suur tänu teie ettekande eest! Te rääkisite vacuum full-st ja kui ma õigesti mõistan, siis vacuum full deformeerib kirje järjekorda eraldi hoidlas, seega säilib praegune kirje muutumatuna. Aga miks vacuum full nõuab eksklusiivset lukustust ja miks see konflikteerub kirjutamisoperatsioonidega?

See on hea küsimus. Põhjuseks on see, et vacuum full võtab tabeli. Ja me sisuliselt loome uue versiooni tabelist. Ja tabel on uus. Seega on tegemist täiesti uue versiooniga tabelist. Probleem seisneb selles, et kui me seda teeme, ei taha me, et inimesed seda loeksid, sest me vajame, et nad näeksid uut tabelit. Seetõttu on see seotud eelmise küsimusega. Kui me saaksime lugeda samaaegselt, siis ei saaks me seda liigutada ja suunata inimesi uuele tabelile. Me peaksime ootama, kuni kõik lõpetavad selle tabeli lugemise, ja seetõttu on tegelikult tegemist exclusiivse lukustusolukorraga.
Me lihtsalt ütleme, et blokeerime alguses, kuna me teame, et lõpuks vajame eksklusiivset lukustust, et liigutada kõik uue koopia juurde. Seetõttu saame me seda potentsiaalselt lahendada. Ja me teeme seda koos samaaegse indekseerimisega. Kuid see on palju keerulisem teha. Ja see on väga seotud teie eelmise küsimusega exclusiivse lukustuse kohta.

Kas Postgres'is on võimalik lisada lukustamise katkestusaega? Oracle'is võin ma näiteks kirjutada 'vali uuendamiseks' ja oodata 50 sekundit uuendamiseks. See oli rakenduse jaoks hea. Kuid Postgres'is pean ma selle kas kohe tegema ja mitte ootama, või ootama kuni teatud ajani.

Jah, saate valida lukustamise katkestuaja oma lukustustele. Samuti saate anda käsu no way, mis …, kui te ei saa kohe lukustust. Seega kas lukustamise katkestusaja või muu, mis võimaldab teil seda teha. Seda ei tehta süntaktilisel tasemel. Seda tehakse serveri muutuja tasemel. Mõnikord ei saa seda kasutada.

Kas saad avada 75. slaidi?

Jah.

Ja minu küsimus on järgmine. Miks ootavad mõlemad uuendusprotsessid 703?

Ja see on tõesti hea küsimus. Ma ei saa aru, miks Postgres seda teeb. Aga kui 703 loodi, oodati 702. Ja kui 704 ja 705 ilmuvad, siis näib, et nad ei tea, mida nad ootavad, sest seal pole veel midagi. Ja Postgres teeb seda nii: kui sa ei saa lukku, siis ta kirjutab „Milleks sind töödelda?“, sest sa ikkagi ootad kedagi. Nii et anname tal lihtsalt õhus rippuda, ta ei uuenda seda üldse. Aga mis siin toimub? Kui 702 on protsessi lõpetanud ja 703 on saanud oma luku, siis süsteem naaseb tagasi. Ja ütleb, et nüüd ootavad kaks inimest. Siis uuendame neid koos. Ja märkime, et mõlemad ootavad.

Ma ei tea, miks Postgres nii teeb. Aga on probleem, mis on tuntud kui f…. Tundub, et see ei ole vene termin. See on siis, kui kõik ootavad ühte lukku, isegi kui 20 instantsi ootab lukku. Ja äkki ärkavad nad kõik üles korraga. Ja kõik hakkavad püüdma reageerida. Aga süsteem teeb nii, et kõik ootavad 703. Sest nad kõik ootavad ja me panevad nad kohe ritta. Ja kui tuleb mõni muu uus päring, mis on pärast seda loodud, näiteks 707, siis seal on taas tühjus.

Ja mulle tundub, et see on tehtud selleks, et saaks öelda, et sellel etapil ootab 702 703, ja kõigil, kes pärast seda tulevad, ei ole selles valdkonnas mitte mingit kirjet. Aga niipea, kui esimene ootaja lahkub, saavad kõik, kes sel hetkel ootasid enne uuendust, sama märgise. Ja seetõttu arvan, et see on tehtud selleks, et saaksime töödelda järjekorras, et nad oleksid õigesti järjestatud.

Ma olen alati vaadanud seda kui üsna kummalist fenomeni. Sest siin, näiteks, ei loetle neid üldse. Aga mulle tundub, et iga kord, kui anname uue luku, vaatame me kõiki, kes on ooteprotsessis. Siis paneme nad kõik järjekorda. Ja seejärel, iga uus, mis tuleb, satub järjekorda ainult siis, kui järgmine inimene on lõpetanud töötlemise. Väga hea küsimus. Aitäh küsimise eest!

Mulle tundub, et see on palju loogilisem, kui 705 ootab 704.

Aga probleem on järgmine. Tehniliselt saate äratada kas ühe või teise. Seega äratame kas ühe või teise. Kuid mis toimub süsteemi töös? Näete, et 703 on ülal blokeerinud omaenda tehingu ID. Nii töötab Postgres. Ja 703 blokeerib enda tehingu ID, seega kui keegi tahab oodata, siis ootab see 703. Ja põhimõtteliselt lõpetab 703. Ja ainult pärast selle lõpetamist ärkab mõni protsess. Ja me ei tea, milline neist protsessidest on. Siis töötame järk-järgult kõik läbi. Kuid pole selge, milline protsess ärkab esimesena, sest see võib olla ükskõik milline neist protsessidest. Põhimõtteliselt oli meil ajastaja, mis ütles, et nüüd saame äratada ükskõik millise neist protsessidest. Valime lihtsalt ühe juhuslikult. Seetõttu tuleb mõlemad üles märkida, sest me saan äratada mõlemat.

Ja probleem on see, et meil on CP-lõpmatus. Seega on täiesti tõenäoline, et saame äratada hilisema. Ja kui näiteks äratame hilisema, siis ootame seda, kes just sai blokeeringu, seega me ei määra, kes täpselt esimesena äratatakse. Loome lihtsalt sellise olukorra, ja süsteem äratab neid juhuslikus järjekorras.

Jah artiklid lukustustest Egor Rogovilt. Vaadake, need on samuti huvitavad ja kasulikud. Teema on muidugi kohutavalt keeruline. Aitäh palju, Bruce!

Allikas: habr.com