Transkript fan Bruce Momjian's 2020-petear "De Postgres Lock Manager ûntsluten".
(Opmerking: Alle SQL-fragen fan 'e dia's kinne wurde krigen fan dizze keppeling: )
Hallo! It is geweldich om hjir wer yn Ruslân te wêzen. It spyt my dat ik ferline jier net komme koe, mar dit jier hawwe Ivan en ik grutte plannen. Ik hoopje hjir folle faker te wêzen. Ik hâld fan kommen nei Ruslân. Ik sil besykje Tyumen, Tver. Ik bin hiel bliid dat ik sil by steat wêze om te besykjen dizze stêden.
Myn namme is Bruce Momjian. Ik wurkje by EnterpriseDB en wurkje al mear as 23 jier mei Postgres. Ik wenje yn Philadelphia, Feriene Steaten. Ik reizgje sa'n 90 dagen yn 't jier. En ik bywenje sa'n 40 konferinsjes. Myn , dy't de dia's befettet dy't ik jo no sjen litte sil. Dêrom kinne jo se nei de konferinsje downloade fan myn persoanlike webside. It befettet ek sa'n 30 presintaasjes. Der binne ek fideo's en in grut oantal blog-yngongen, mear as 500. Dit is in frij ynformative boarne. En as jo ynteressearre binne yn dit materiaal, dan noegje ik jo út om it te brûken.
Ik wie eartiids learaar, professor foardat ik mei Postgres begon te wurkjen. En ik bin tige bliid dat ik jo no fertelle kin wat ik jo fertelle sil. Dit is ien fan myn meast nijsgjirrige presintaasjes. En dizze presintaasje befettet 110 dia's. Wy sille begjinne te praten mei ienfâldige dingen, en oan 'e ein sil it rapport mear en komplekser wurde, en sil frij kompleks wurde.
Dit is in nochal onaangenaam petear. Blokkearje is net it populêrste ûnderwerp. Wy wolle dat dit earne ferdwynt. It is as nei de toskedokter gean.
- Beskoatteljen is in probleem foar in grut oantal minsken dy't wurkje yn databases en hawwe meardere prosessen dy't tagelyk rinne. Se moatte blokkearje. Dat is, hjoed sil ik jo basiskennis jaan oer blokkearjen.
- Transaksje IDs. Dit is in nochal saai diel fan 'e presintaasje, mar se moatte wurde begrepen.
- Folgjende sille wy prate oer soarten blokkearjen. Dit is in frij meganysk diel.
- En hjirûnder sille wy wat foarbylden jaan fan blokkearjen. En it sil heul lestich wêze om te begripen.
Litte wy prate oer blokkearjen.
Us terminology is frij kompleks. Hoefolle fan jimme witte wêr't dizze passaazje wei komt? Twa minsken. Dit is fan in spultsje neamd Colossal Cave Adventure. It wie in tekst-basearre kompjûterspultsje yn 'e jierren '80, tink ik. Dêr moasten jo yn in grot, in doalhôf, en de tekst feroare, mar de ynhâld wie elke kear sawat itselde. Dat is hoe't ik ûnthâlde dit spultsje.
En hjir sjogge wy de namme fan 'e slûzen dy't by ús kamen fan Oracle. Wy brûke se.
Hjir sjogge wy termen dy't my betize. Bygelyks, SHARE UPDATE ECXLUSIVE. Folgjende SHARE RAW ECXLUSIVE. Om earlik te wêzen, dizze nammen binne net hiel dúdlik. Wy sille besykje se yn mear detail te beskôgjen. Guon befetsje it wurd "diel", dat betsjut om te skieden. Guon befetsje it wurd "eksklusyf". Guon befetsje dizze beide wurden. Ik soe graach begjinne mei hoe't dizze slûzen wurkje.
En it wurd "tagong" is ek tige wichtich. En de wurden "rige" binne in tekenrige. Dat is, tagong distribúsje, rige distribúsje.
In oare kwestje dy't yn Postgres begrepen wurde moat, dêr't ik spitigernôch net yn myn praatsje oer kin, is MVCC. Ik haw in aparte presintaasje oer dit ûnderwerp op myn webside. En as jo tinke dat dizze presintaasje dreech is, is MVCC wierskynlik myn hurdste. En as jo ynteressearre binne, kinne jo it besjen op 'e webside. Jo kinne de fideo besjen.
In oar ding dat wy moatte begripe is transaksje-ID's. In protte transaksjes kinne net wurkje sûnder unike identifiers. En hjir hawwe wy in útlis fan wat in transaksje is. Postgres hat twa transaksje nûmering systemen. Ik wit dat dit net in heul moaie oplossing is.
Hâld ek yn gedachten dat de dia 's sille wêze hiel lestich te begripen, dus wat is markearre yn read is wat jo moatte betelje omtinken oan.
Litte wy sjen. It transaksjenûmer is yn read markearre. De funksje SELECT pg_back wurdt hjir werjûn. It jout myn transaksje en de transaksje-ID werom.
Noch ien ding, as jo dizze presintaasje leuk fine en it op jo databank wolle útfiere, dan kinne jo nei dizze kepling yn roze gean en de SQL foar dizze presintaasje downloade. En jo kinne it gewoan yn jo PSQL útfiere en de heule presintaasje sil fuortendaliks op jo skerm wêze. It sil gjin blommen befetsje, mar wy kinne it teminsten sjen.
Yn dit gefal sjogge wy de transaksje ID. Dit is it nûmer dat wy har tawiisd hawwe. En d'r is in oar type transaksje-ID yn Postgres, dat wurdt firtuele transaksje-ID neamd
En wy moatte dit begripe. Dit is heul wichtich, oars kinne wy it sluten yn Postgres net begripe.
In firtuele transaksje-ID is in transaksje-ID dy't gjin persistente wearden befettet. Bygelyks, as ik in SELECT-kommando útfiere, dan sil ik nei alle gedachten de databank net feroarje, ik sil neat beskoattelje. Dus as wy in ienfâldige SELECT útfiere, jouwe wy dy transaksje gjin persistente ID. Wy jouwe har dêr allinnich in firtuele ID.
En dit ferbettert de prestaasjes fan Postgres, ferbetteret de mooglikheden foar skjinmeitsjen, sadat de firtuele transaksje-ID bestiet út twa nûmers. It earste nûmer foar de slash is de backend ID. En rjochts sjogge wy gewoan in teller.
Dêrom, as ik in fersyk útfiere, seit it dat de backend ID 2 is.
En as ik in rige fan sokke transaksjes útfiere, dan sjogge wy dat de teller elke kear as ik in query útfiere nimt ta. Bygelyks, as ik de query 2/10, 2/11, 2/12, ensfh.
Hâld der rekken mei dat d'r hjir twa kolommen binne. Oan de linkerkant sjogge wy de firtuele transaksje ID - 2/12. En oan 'e rjochterkant hawwe wy in permaninte transaksje-ID. En dit fjild is leech. En dizze transaksje feroaret de databank net. Dat ik jou it gjin permaninte transaksje-ID.
Sadree't ik rinne it analysearjen kommando ((ANALYSE)), jout deselde fraach my in permaninte transaksje ID. Sjoch hoe't dit foar ús feroare is. Ik hie dizze ID net earder, mar no haw ik it.
Dus hjir is in oar fersyk, in oare transaksje. It firtuele transaksjenûmer is 2/13. En as ik freegje om in oanhâldende transaksje-ID, dan as ik de query útfiere, sil ik it krije.
Dus, noch ien kear. Wy hawwe in firtuele transaksje ID en in oanhâldende transaksje ID. Begryp dit punt gewoan om Postgres gedrach te begripen.
Wy geane nei de tredde seksje. Hjir sille wy gewoan troch de ferskate soarten slûzen yn Postgres rinne. It is net hiel nijsgjirrich. De lêste seksje sil folle ynteressanter wêze. Mar wy moatte de basis dingen beskôgje, want oars sille wy net begripe wat der dan barre sil.
Wy sille gean troch dizze seksje, wy sille sjen op elk type slot. En ik sil jo foarbylden sjen litte hoe't se binne ynstalleare, hoe't se wurkje, ik sil jo wat fragen sjen litte dy't jo kinne brûke om te sjen hoe't beskoatteljen wurket yn Postgres.
Om in query te meitsjen en te sjen wat der bart yn Postgres, moatte wy de query útjaan yn 'e systeemwerjefte. Yn dit gefal wurdt pg_lock yn read markearre. Pg_lock is in systeemtabel dy't ús fertelt hokker slûzen op it stuit yn gebrûk binne yn Postgres.
It is lykwols heul lestich foar my om jo pg_lock op himsels te sjen, om't it frij kompleks is. Dat ik makke in werjefte dy't pg_locks toant. En it docht ek wat wurk foar my dat ik better begryp kin. Dat is, it slút myn slûzen, myn eigen sesje, ensfh It is gewoan standert SQL en it lit jo better sjen litte wat der bart.
In oar probleem is dat dizze werjefte heul breed is, dus ik moat in twadde meitsje - lockview2.
En it lit my mear kolommen út 'e tabel sjen. En noch ien dy't my de rest fan 'e kolommen sjen lit. Dit is frij kompleks, dus ik besocht it sa ienfâldich mooglik te presintearjen.
Sa hawwe wy in tabel makke mei de namme Lockdemo. En dêr makken wy ien rigel. Dit is ús foarbyldtafel. En wy sille seksjes oanmeitsje om jo foarbylden fan slûzen te sjen.
Dus, ien rige, ien kolom. It earste type slot hjit ACCESS SHARE. Dit is de minst beheinende blokkearjen. Dit betsjut dat it praktysk net yn striid is mei oare slûzen.
En as wy eksplisyt in slot wolle definiearje, rinne wy it kommando "slot tabel". En it sil fansels blokkearje, d.w.s. yn ACCESS SHARE-modus lansearje wy de slottafel. En as ik PSQL op 'e eftergrûn útfiere, dan begjin ik de twadde sesje fan myn earste sesje op dizze manier. Dat is, wat sil ik hjir dwaan? Ik gean nei in oare sesje en fertel it "lit my de lockview foar dit fersyk sjen." En hjir haw ik AccessShareLock yn dizze tabel. Dit is krekt wat ik frege. En hy seit dat it blok is tawiisd. Hiel ienfâldich.
Fierder, as wy nei de twadde kolom sjogge, dan is der neat. Se binne leech.
En as ik it kommando "SELECT" útfiere, dan is dit de ymplisite (eksplisite) manier om AccessShareLock oan te freegjen. Dat ik lit myn tabel los en de query útfiere en de query jout meardere rigen werom. En yn ien fan 'e rigels sjogge wy AccessShareLock. Sa neamt SELECT AccessShareLock op 'e tafel. En it is net yn striid mei praktysk alles, om't it in slot op leech nivo is.
Wat as ik in SELECT útfiere en trije ferskillende tabellen hawwe? Earder rûn ik mar ien tabel, no rinne ik trije: pg_class, pg_namespace en pg_attribute.
En no as ik nei de fraach sjoch, sjoch ik 9 AccessShareLocks yn trije tabellen. Wêrom? Trije tabellen wurde markearre yn blau: pg_attribute, pg_class, pg_namespace. Mar jo kinne ek sjen dat alle yndeksen dy't wurde definiearre troch dizze tabellen ek hawwe AccessShareLock.
En dit is in slot dat praktysk net yn striid is mei oaren. En alles wat it docht is gewoan te foarkommen dat wy de tabel weromsette wylst wy it selektearje. It makket sin. Dat is, as wy in tabel selektearje, ferdwynt dy op dat stuit, dan is dit ferkeard, dus AccessShare is in slot op leech nivo dy't ús fertelt "dizze tabel net falle wylst ik wurkje". Yn essinsje is dat alles wat se docht.
ROW SHARE - Dit slot is in bytsje oars.
Litte wy in foarbyld nimme. SELECT ROW SHARE metoade foar it beskoatteljen fan elke rige yndividueel. Op dizze manier kin gjinien se wiskje of feroarje wylst wy se besjen.
Dus wat docht SHARE LOCK? Wy sjogge dat de transaksje-ID 681 is foar SELECT. En dit is nijsgjirrich. Wat is hjir bard? De earste kear dat wy sjogge it getal is yn de "Lock" fjild. Wy nimme de transaksje-ID en it seit dat it blokkearret yn eksklusive modus. Alles wat it docht is dat ik haw in rige dat is technysk op slot earne yn 'e tabel. Mar hy seit net wêr krekt. Wy sille dit in bytsje letter yn mear detail besjen.
Hjir sizze wy dat it slot wurdt brûkt troch ús.
Dat, in eksklusyf slot seit eksplisyt dat it eksklusyf is. En ek as jo in rige yn dizze tabel wiskje, dan is dit wat sil barre, lykas jo sjen kinne.
SHARE EXCLUSIVE is in langer slot.
Dit is it (ANALYZE) analyzer kommando dat sil wurde brûkt.
SHARE LOCK - jo kinne eksplisyt beskoattelje yn dielde modus.
Jo kinne ek in unike yndeks meitsje. En dêr kinne jo sjen SHARE LOCK, dat is diel fan harren. En it slút de tafel en set in SHARE LOCK derop.
Standert betsjut SHARE LOCK op in tafel dat oare minsken de tabel lêze kinne, mar gjinien kin it wizigje. En dit is krekt wat bart as jo in unike yndeks meitsje.
As ik in unike tagelyk yndeks meitsje, dan sil ik in oar type beskoatteljen hawwe, om't, lykas jo ûnthâlde, it brûken fan tagelyk yndeksen de beskoatteleasken ferminderet. En as ik brûk in gewoane slûs, in normale yndeks, dan sil ik sa foarkomme skriuwen nei de tabel yndeks wylst it wurdt oanmakke. As ik in simultane yndeks brûke, dan moat ik in oar type slot brûke.
SHARE ROW EXCLUSIVE - wer kin it eksplisyt (eksplisyt) ynsteld wurde.
Of wy kinne in regel oanmeitsje, d.w.s. in spesifyk gefal nimme wêryn it sil wurde brûkt.
EXCLUSIVE locking betsjut dat gjinien oars kin feroarje de tafel.
Hjir sjogge wy ferskate soarten slûzen.
ACCESS EXCLUSIVE, bygelyks, is in blokkearjende kommando. Bygelyks, as jo dogge CLUSTER table, dan sil dit betsjutte dat nimmen dêr skriuwe kin. En it slút net allinnich de tafel sels, mar ek de yndeksen.
Dit is de twadde side fan 'e ACCESS EXCLUSIVE blocking, wêr't wy krekt sjogge wat it blokkeart yn' e tabel. It slút yndividuele tabel rigen, dat is hiel nijsgjirrich.
Dat is al de basisynformaasje dy't ik jaan woe. Wy hawwe it oer slûzen, oer transaksje-ID's, wy hawwe it oer firtuele transaksje-ID's, oer permaninte transaksje-ID's.
En no sille wy troch guon blokkearjende foarbylden gean. Dit is it meast nijsgjirrige diel. Wy sille sjen nei tige nijsgjirrige gefallen. En myn doel yn dizze presintaasje is om jo in better begryp te jaan fan wat Postgres eins docht as it besiket bepaalde dingen te blokkearjen. Ik tink dat hy heul goed is yn it blokkearjen fan dielen.
Litte wy nei guon spesifike foarbylden sjen.
Wy sille begjinne mei tabellen en ien rige yn in tabel. As ik ynfoegje wat ik haw ExclusiveLock, Transaksje ID en ExclusiveLock werjûn op 'e tafel.
Wat bart der as ik ynfoegje twa mear rigen? En no hat ús tabel trije rigen. En ik ynfoege ien rige en krige dit as in útfier. En as ik noch twa rigen ynfoegje, wat is dêr nuver oan? Der is in nuver ding hjir omdat ik haw tafoege trije rigen oan dizze tabel, mar ik haw noch twa rigen yn it slot tafel. En dit is yn wêzen it fûnemintele gedrach fan Postgres.
In protte minsken tinke dat as jo yn in databank 100 rigen beskoattelje, dan moatte jo 100 slotyngongen oanmeitsje. As ik 1 rigen tagelyk blokkearje, dan sil ik 000 sokke fragen nedich wêze. En as ik in miljoen of in miljard nedich om te blokkearjen. Mar as wy dit dogge, sil it net sa goed wurkje. As jo in systeem hawwe brûkt dat blokkearjende yngongen foar elke yndividuele rige makket, dan kinne jo sjen dat dit yngewikkeld is. Om't jo moatte fuortendaliks definiearje in slot tafel dat kin oerrinne, mar Postgres docht net dat.
En wat echt wichtich is oer dizze slide is dat it dúdlik toant dat d'r in oar systeem is dat rint binnen MVCC dat yndividuele rigen slûpt. Dus as jo miljarden rigen beskoattelje, makket Postgres gjin miljard aparte beskoattelkommando's. En dit hat in hiel goed effekt op de produktiviteit.
Wat oer in update? Ik bin it bywurkjen fan de rige no, en jo kinne sjen dat it hat útfierd twa ferskillende operaasjes tagelyk. It slot de tafel tagelyk, mar it beskoattelje ek de yndeks. En hy moast de yndeks beskoattelje, om't d'r unike beheiningen op dizze tafel binne. En wy wolle derfoar soargje dat gjinien it feroaret, dus blokkearje wy it.
Wat bart der as ik twa rigen bywurkje wol? En wy sjogge dat er itselde gedraacht. Wy dogge twa kear safolle updates, mar krekt itselde oantal slot rigels.
As jo jo ôffreegje hoe't Postgres dit docht, moatte jo harkje nei myn petearen oer MVCC om te learen hoe't Postgres dizze rigels yntern markearret dat it feroaret. En Postgres hat in manier wêrop't it dit docht, mar it docht it net op it nivo fan tafelslot, it docht it op in leger en effisjinter nivo.
Wat as ik wat wiskje wol? As ik wiskje, bygelyks, ien rige en ik haw noch myn twa blokkearjende yngongen, en sels as ik wol wiskje se allegearre, se binne der noch.
En bygelyks wol ik 1 rigels ynfoegje, en dan 000 rigels wiskje of tafoegje, dan wurde dy yndividuele rigels dy't ik tafoegje of wizigje, se wurde hjir net opnommen. Se binne skreaun op in leger nivo binnen de rige sels. En tidens de MVCC-taspraak haw ik hjir yn detail oer praat. Mar it is hiel wichtich as jo analysearje slûzen om te soargjen dat jo beskoattelje op 'e tafel nivo en dat jo net sjogge hoe't yndividuele rigen wurde opnommen hjir.
Hoe sit it mei eksplisite blokkearjen?
As ik klik op ferfarskje, Ik haw twa rigen beskoattele. En as ik se allegear selektearje en op "update oeral" klikje, dan haw ik noch twa blokkearjende records.
Wy meitsje gjin aparte records foar elke yndividuele rige. Want dan sakket de produktiviteit, der kin tefolle fan wêze. En wy kinne ússels yn in ûnnoflike situaasje fine.
En itselde ding, as wy dielde, kinne wy it allegear 30 kear dwaan.
Wy restaurearje ús tabel, wiskje alles, foegje dan wer ien rige yn.
In oar gedrach dat jo sjogge yn Postgres dat is tige bekend en winske gedrach is dat jo kinne dwaan in update of in selekt. En jo kinne dit tagelyk dwaan. En selektearje net blokkearje update en itselde ding yn 'e tsjinoerstelde rjochting. Wy fertelle de lêzer om de skriuwer net te blokkearjen, en de skriuwer hat de lêzer net blokkearre.
Ik sil jo hjir in foarbyld fan sjen litte. Ik sil no in kar meitsje. Wy sille dan de INSERT dwaan. En dan kinne jo sjen - 694. Jo kinne de ID sjen fan 'e transaksje dy't dizze ynfoegje útfierde. En sa wurket it.
En as ik no nei myn backend-ID sjoch, is it no 695.
En ik kin sjen 695 ferskine yn myn tabel.
En as ik hjir sa bywurkje, dan krij ik in oare saak. Yn dit gefal, 695 is in eksklusyf slot, en update hat itselde gedrach, mar der is gjin konflikt tusken harren, dat is hiel ûngewoan.
En jo kinne sjen dat it oan 'e boppekant ShareLock is, en oan' e ûnderkant is it ExclusiveLock. En beide transaksjes wurken út.
En jo moatte harkje nei myn petear by MVCC om te begripen hoe't dit bart. Mar dit is in yllustraasje dat jo it tagelyk kinne dwaan, dus tagelyk in SELECT en in UPDATE dwaan.
Litte wy weromsette en noch ien operaasje dwaan.
As jo besykje twa updates tagelyk op deselde rige út te fieren, sil it blokkearre wurde. En tink, ik sei dat de lêzer de skriuwer net blokkearret, en de skriuwer net blokkearret de lêzer, mar ien skriuwer blokkearret in oare skriuwer. Dat is, wy kinne net hawwe twa minsken bywurkje deselde rige tagelyk. Jo moatte wachtsje oant ien fan harren klear is.
En om dit te yllustrearjen, sjoch ik nei de Lockdemo-tabel. En wy sille sjen nei ien rige. Per transaksje 698.
Wy hawwe dit bywurke nei 2. 699 is de earste fernijing. En it wie suksesfol of it is yn in ôfhannele transaksje en wachtet op ús om te befêstigjen of te annulearjen.
Mar sjoch nei wat oars - 2/51 is ús earste transaksje, ús earste sesje. 3/112 is it twadde fersyk dat kaam út de top dy't feroare dy wearde oan 3. En as jo fernimme, de boppeste ien beskoattele sels, dat is 699. Mar 3/112 net ferliend it slot. De kolom Lock_mode seit wêr't it op wachtet. It ferwachtet 699. En as jo sjogge wêr't 699 is, is it heger. En wat die de earste sesje? Se makke in eksklusyf slot op har eigen transaksje ID. Dit is hoe't Postgres it docht. It blokkearret syn eigen transaksje-ID. En as jo wolle wachtsje op ien om te befêstigjen of te annulearjen, dan moatte jo wachtsje wylst d'r in wachte transaksje is. En dêrom kinne wy in nuvere line sjen.
Litte wy nochris sjen. Oan de linkerkant sjogge wy ús ferwurkings-ID. Yn 'e twadde kolom sjogge wy ús firtuele transaksje-ID, en yn' e tredde sjogge wy lock_type. Wat betsjut dit? Yn essinsje is wat it seit dat it de transaksje-ID blokkearret. Mar merk op dat alle rigen ûnderoan sizze relaasje. En sa hawwe jo twa soarten slûzen op 'e tafel. Der is in relaasje slot. En dan is d'r it blokkearjen fan transaksje-id, wêr't jo op jo eigen blokkearje, dat is krekt wat bart op 'e earste rige of oan' e ûnderkant, wêr't de transaksje-id is, wêr't wy wachtsje op 699 om syn operaasje te foltôgjen.
Ik sil sjen wat der bart hjir. En hjir barre twa dingen tagelyk. Jo sjogge nei in transaksje-ID-slot yn 'e earste rige dy't himsels slûpt. En se blokkearret harsels om minsken te wachtsjen.
As jo sjogge nei de 6e rigel, it is deselde yngong as de earste. En dêrom is transaksje 699 blokkearre. 700 is ek self-locking. En dan yn 'e ûnderste rige sille jo sjen dat wy wachtsje op 699 om syn operaasje te foltôgjen.
En yn lock_type, tuple sjogge jo nûmers.
Jo kinne sjen dat it 0/10 is. En dit is it sidenûmer, en ek de offset fan dizze bepaalde rige.
En jo sjogge dat it 0/11 wurdt as wy bywurkje.
Mar yn werklikheid is it 0/10, om't d'r in wachtsjen is foar dizze operaasje. Wy hawwe de kâns om te sjen dat dit de searje is dy't ik wachtsje om te befêstigjen.
Sadree't wy hawwe befêstige it en drukke commit, en as de fernijing is klear, dit is wat wy krije wer. Transaksje 700 is de ienige slot, it wachtet net op immen oars omdat it waard ynset. It wachtet gewoan op 'e transaksje om te foltôgjen. Sadree't 699 op is, wachtsje wy neat mear op. En no seit transaksje 700 dat alles goed is, dat it hat alle slûzen it nedich is op alle tastiene tabellen.
En om dit hiele ding noch komplisearre te meitsjen, meitsje wy in oare werjefte, dy't ús dizze kear in hiërargy sil jaan. Ik ferwachtsje net dat jo dit fersyk begripe. Mar dit sil ús in dúdliker sicht jaan fan wat der bart.
Dit is in rekursive werjefte dy't ek in oare seksje hat. En dan bringt it alles wer byinoar. Litte wy dit brûke.
Wat as wy trije simultane updates dogge en sizze dat de rige no trije is. En wy feroarje 3 nei 4.
En hjir sjogge wy 4. En transaksje ID 702.
En dan feroarje ik 4 yn 5. En 5 yn 6, en 6 yn 7. En ik sil in oantal minsken opstelle dy't wachtsje op dizze iene transaksje om te einigjen.
En alles wurdt dúdlik. Wat is de earste rige? Dit is 702. Dit is de transaksje-ID dy't dizze wearde oarspronklik ynsteld hat. Wat is skreaun yn myn Granted kolom? Ik haw tekens f. Dit binne myn updates dy't (5, 6, 7) net goedkard wurde kinne, om't wy wachtsje op transaksje ID 702 om te einigjen. Dêr hawwe wy transaksje ID blokkearjen. En dit resultearret yn 5 transaksjonele ID-slûzen.
En as je sjogge nei 704, op 705, dan is der noch neat skreaun, want se witte noch net wat der oan de hân is. Se skriuwe gewoan dat se gjin idee hawwe wat der bart. En se sille gewoan sliepe, om't se wachtsje op ien dy't klear is en wekker wurdt as der in kâns is om rigen te feroarjen.
Dit is wat it liket. It is dúdlik dat se allegear wachtsje op de 12e line.
Dit is wat wy hjir seagen. Hjir is 0/12.
Dus as de earste transaksje goedkard is, kinne jo hjir sjen hoe't de hiërargy wurket. En no wurdt alles dúdlik. Se wurde allegear skjin. En se wachtsje eins noch.
Hjir is wat der bart. 702 ynset. En no krijt 703 dizze rige slot, en dan begjint 704 te wachtsjen op 703 om te begean. En de 705 wachtet hjir ek op. En as dit alles klear is, meitsje se har sels skjin. En ik wol graach oanjaan dat elkenien yn 'e line stiet. En dit is hiel gelyk oan in situaasje yn in file doe't elkenien wachtet op de earste auto. De earste auto stopt en elkenien stiet yn in lange rige. Dan beweecht it, dan kin de folgjende auto foarút ride en syn blok krije, ensfh.
En as dit jo net yngewikkeld genôch like, dan sille wy no mei jo prate oer deadlocks. Ik wit net wa fan jimme se tsjinkommen is. Dit is in frij algemien probleem yn databasesystemen. Mar deadlocks binne as ien sesje wachtet op in oare sesje om wat te dwaan. En op dit stuit wachtet in oare sesje op 'e earste sesje om wat te dwaan.
En, bygelyks, as Ivan seit: "Jou my wat," en ik sis: "Nee, ik sil it jo allinich jaan as jo my wat oars jouwe." En hy seit: "Nee, ik sil it jo net jaan as jo it my net jouwe." En wy komme yn in deadlock situaasje. Ik bin der wis fan dat Ivan dit net sil dwaan, mar jo begripe de betsjutting dat wy twa minsken hawwe dy't wat wolle krije en se binne net ree om it fuort te jaan oant de oare persoan har jout wat se wolle. En der is gjin oplossing.
En yn essinsje moat jo databank dit detektearje. En dan moatte jo ien fan 'e sesjes wiskje of slute, want oars bliuwe se der foar altyd. En wy sjogge it yn databases, wy sjogge it yn bestjoeringssystemen. En op alle plakken dêr't wy parallelle prosessen hawwe, kin dat barre.
En no sille wy twa deadlocks ynstallearje. Wy sette 50 en 80. Yn 'e earste rige sil ik bywurkje fan 50 nei 50. Ik krij transaksjenûmer 710.
En dan sil ik 80 feroarje yn 81, en 50 yn 51.
En dit is hoe't it der útsjen sil. En sa hat 710 in rige blokkearre, en 711 wachtet op befêstiging. Wy seagen dit doe't wy bywurke. 710 is de eigner fan ús searje. En 711 wachtet op 710 om de transaksje te foltôgjen.
En der stiet sels op hokker rige de deadlines foarkomme. En hjir begjint it nuver te wurden.
No aktualisearje wy 80 nei 80.
En dit is wêr't de deadlocks begjinne. 710 wachtet op in antwurd fan 711, en 711 wachtet op 710. En dit sil net einigje goed. En der is gjin wei út dit. En se sille in reaksje fan elkoar ferwachtsje.
En it sil gewoan begjinne alles te fertrage. En dat wolle wy net.
En Postgres hat manieren om te merken as dit bart. En as dit bart, krije jo dizze flater. En út dit is it dúdlik dat sa'n en sa'n proses wachtet op in SHARE LOCK fan in oar proses, d.w.s. dat wurdt blokkearre troch 711 proses. En dat proses wachte op in SHARE LOCK om te jaan op sa'n en sa'n transaksje-ID en waard blokkearre troch sa'n en sa'n proses. Dêrom is hjir in deadlock situaasje.
Binne der trije-way deadlocks? It is mooglik? Ja.
Wy fiere dizze nûmers yn in tabel. Wy feroarje 40 nei 40, wy dogge blokkearjen.
Wy feroarje 60 nei 61, 80 nei 81.
En dan feroarje wy 80 en dan boom!
En 714 wachtet no op 715. De 716e wachtet op de 715e. En der kin neat oan dien wurde.
Hjir binne gjin twa minsken mear, hjir binne al trije minsken. Ik wol wat fan dy, dizze wol wat fan in tredde persoan, en de tredde wol wat fan my. En wy einigje yn in trije-manier wachtsjen, om't wy allegear wachtsje op 'e oare persoan om te foltôgjen wat se moatte dwaan.
En Postgres wit op hokker rige dit bart. En sa sil it jo it folgjende berjocht jaan, dat lit sjen dat jo in probleem hawwe wêr't trije yngongen inoar blokkearje. En d'r binne hjir gjin beheiningen. Dit kin it gefal wêze wêr't 20 yngongen elkoar blokkearje.
It folgjende probleem is serialisearre.
As spesjale serializable slot.
En wy geane werom nei 719. Syn útfier is hiel normaal.
En jo kinne klikke om de transaksje fan serializable te meitsjen.
En jo realisearje dat jo no hawwe in oar soarte fan SA slot - it betsjut serializable.
En sa hawwe wy in nij type slot neamd SARieadLock, dat is in serial slot en kinne jo ynfiere serials.
En jo kinne ek unike yndeksen ynfoegje.
Yn dizze tabel hawwe wy unike yndeksen.
Dus as ik set yn it getal 2 hjir, dus ik haw in 2. Mar op de hiel top, Ik set nochris 2. En jo kinne sjen dat 721 hat in eksklusyf slot. Mar no wachtet 722 op 721 om syn operaasje te foltôgjen, om't it 2 net kin ynfoegje oant it wit wat der mei 721 barre sil.
En as wy dogge subtransaction.
Hjir hawwe wy 723.
En as wy it punt bewarje en it dan bywurkje, dan krije wy in nije transaksje-ID. Dit is in oar gedrachspatroan wêrfan jo bewust moatte wêze. As wy dit werombringe, dan giet de transaksje-ID fuort. 724 giet fuort. Mar no hawwe wy 725.
Dus wat besykje ik hjir te dwaan? Ik besykje te sjen litte jo foarbylden fan ûngewoane slûzen dy't jo miskien fine: oft it is serializable slûzen of SAVEPOINT, dit binne ferskillende soarten slûzen dy't sil ferskine yn it slot tabel.
Dit is it meitsjen fan eksplisite (eksplisite) slûzen, dy't pg_advisory_lock hawwe.
En jo sjogge dat it blokkearjende type wurdt fermeld as advisearjend. En hjir stiet it "advisearjend" yn read. En jo kinne tagelyk blokkearje lykas dit mei pg_advisory_unlock.
En ta konklúzje wol ik jim noch ien ferrassend ding sjen litte. Ik sil in oare werjefte meitsje. Mar ik sil meidwaan oan de pg_locks tabel mei de pg_stat_activity tabel. En wêrom wol ik dit dwaan? Om't dit sil tastean my te sjen en sjen alle aktuele sesjes en sjen krekt wat soarte fan slûzen se wachtsje. En dit is hiel nijsgjirrich as wy sette tegearre de slot tafel en de query tabel.
En hjir meitsje wy pg_stat_view.
En wy fernije de rige troch ien. En hjir sjogge wy 724. En dan fernije wy ús rige nei trije. En wat sjochst hjir no? Dit binne oanfragen, d.w.s. jo sjogge de folsleine list mei oanfragen dy't yn 'e lofterkolom steane. En dan op 'e rjochterkant kinne jo de blokkades sjen en wat se meitsje. En it kin foar jo dúdliker wêze, sadat jo net elke kear nei elke sesje hoege werom te gean en te sjen oft jo der by moatte of net. Se dogge it foar ús.
In oare funksje dy't heul nuttich is pg_blocking_pids. Jo hawwe wierskynlik noch noait fan har heard. Wat docht sy? It lit ús fertelle dat foar dizze sesje 11740 hokker spesifike proses-ID's it wachtet. En jo kinne sjen dat 11740 wachtet op 724. En 724 is op 'e top. En 11306 is jo proses ID. Yn wêzen giet dizze funksje troch jo slot tafel. En ik wit dat it in bytsje yngewikkeld is, mar jo kinne it begripe. Yn essinsje giet dizze funksje troch dizze slottabel en besiket te finen wêr't dizze proses-ID de slûzen wurdt jûn wêrop it wachtet. En it besiket ek út te finen hokker proses ID it proses dat wachtet op it slot hat. Sa kinne jo dizze funksje útfiere pg_blocking_pids.
En dit kin heul nuttich wêze. Wy hawwe dit allinich tafoege yn ferzje 9.6, dus dizze funksje is mar 5 jier âld, mar it is heul, heul nuttich. En itselde jildt foar it twadde fersyk. It lit krekt sjen wat wy moatte sjen.
Dit is wêr't ik mei dy oer prate woe. En lykas ik ferwachte, hawwe wy al ús tiid brûkt om't d'r safolle dia's wiene. En de dia's binne te downloaden. Ik wol jo betankje foar it wêzen hjir. Ik bin der wis fan dat jo sille genietsje fan de rest fan 'e konferinsje, tige tank!
Fragen:
Bygelyks, as ik besykje te aktualisearjen rigen, en de twadde sesje besiket te wiskjen de hiele tabel. Foar safier't ik begryp, moat der wat wêze as in opsetslot. Is der soks yn Postgres?
Litte wy weromgean nei it heule begjin. Jo kinne ûnthâlde dat as jo wat dogge, bygelyks as jo in SELECT dogge, wy in AccessShareLock útjaan. En dit foarkomt dat de tafel fallen wurdt. Dus as jo bygelyks in rige yn in tabel bywurkje wolle of in rige wiskje wolle, dan kin immen de hiele tabel net tagelyk wiskje om't jo dizze AccessShareLock oer de hiele tabel en oer de rige hâlde. En as jo klear binne, kinne se it wiskje. Mar wylst jo dêr direkt wat feroarje, sille se it net kinne dwaan.
Litte wy it nochris dwaan. Lit ús gean nei it wiskjen foarbyld. En jo sjogge hoe't der in eksklusyf slot op 'e rige boppe de hiele tafel.
Dit sil lykje op slot eksklusyf, rjochts?
Ja, it liket derop. Ik begryp wêr't jo it oer hawwe. Jo sizze dat as ik in SELECT doch, dan haw ik in ShareExclusive en dan meitsje ik it Row Exclusive, wurdt dat in probleem? Mar ferrassend is dit gjin probleem. Dit liket it fergrutsjen fan de slûsgraad, mar yn essinsje haw ik in slot dy't wiskjen foarkomt. En no, as ik dit slot machtiger meitsje, foarkomt it noch wiskjen. Dus it is net sa dat ik omheech gean. Dat is, it foarkommen dat it barde doe't it ek op in leger nivo wie, dus as ik har nivo ferheegje, foarkomt it noch dat de tabel wurdt wiske.
Ik begryp wêr't jo it oer hawwe. Der is gjin slot eskalaasje gefal hjir, dêr't jo besykje te jaan ien slot foar in yntrodusearje in sterker. Hjirmei fergruttet it dizze previnsje gewoan oer de hiele breedte, sadat it gjin konflikt feroarsaket. Mar it is in goede fraach. Tige tank foar it freegjen fan dit!
Wat moatte wy dwaan om in deadlock-situaasje te foarkommen as wy in protte sesjes hawwe, in grut oantal brûkers?
Postgres merkt automatysk deadlock-situaasjes op. En it sil automatysk ien fan 'e sesjes wiskje. De ienige manier om deade blokkearjen te foarkommen is om minsken yn deselde folchoarder te blokkearjen. Dus as jo nei jo oanfraach sjogge, faaks de reden foar deadlocks ... Litte wy ús foarstelle dat ik twa ferskillende dingen blokkearje wol. Ien applikaasje slûpt tabel 1, en in oare applikaasje slút 2, en dan tabel 1. En de maklikste manier om deadlocks te foarkommen is om nei jo applikaasje te sjen en te besykjen om te soargjen dat it beskoatteljen yn deselde folchoarder foar alle applikaasjes bart. En dit elimineert normaal 80% fan 'e problemen, om't alle soarten minsken dizze applikaasjes skriuwe. En as jo se yn deselde folchoarder blokkearje, dan komme jo gjin deadlock-situaasje tsjin.
Tige tank foar dyn optreden! Jo hawwe it oer fakuüm fol en, as ik it goed begryp, fersteurt fakuüm fol de folchoarder fan records yn aparte opslach, sadat se de hjoeddeistige records net feroarje. Wêrom nimt fakuüm folslein eksklusive slot tagong en wêrom komt it yn striid mei skriuwoperaasjes?
Dat is in goede fraach. De reden is dat fakuüm fol nimt de tafel. En wy meitsje yn wêzen in nije ferzje fan 'e tafel. En de tafel sil nij wêze. It docht bliken dat dit in folslein nije ferzje fan 'e tafel sil wêze. En it probleem is dat as wy dit dogge, wy net wolle dat minsken it lêze, om't wy se nedich hawwe om de nije tabel te sjen. En sa slút dit oan by de foarige fraach. As wy tagelyk lêze koene, soene wy it net kinne ferpleatse en minsken nei in nije tafel liede. Wy soene moatte wachtsje foar elkenien klear te lêzen dizze tabel, en dus it is yn wêzen in slot eksklusyf situaasje.
Wy sizze gewoan dat wy fan it begjin ôf slute, om't wy witte dat wy oan 'e ein in eksklusyf slot nedich hawwe om elkenien nei it nije eksimplaar te ferpleatsen. Sa kinne wy dit mooglik oplosse. En wy dogge it op dizze manier mei simultane yndeksearring. Mar dit is folle dreger om te dwaan. En dit hat in protte te krijen mei jo foarige fraach oer slot eksklusyf.
Is it mooglik om beskoattelje time-out ta te foegjen oan Postgres? Yn Oracle kin ik bygelyks "selektearje om te aktualisearjen" skriuwe en 50 sekonden wachtsje foar it bywurkjen. It wie goed foar de applikaasje. Mar yn Postgres moat ik it of daliks dwaan en hielendal net wachtsje, of wachtsje oant in skoftke.
Ja, jo kinne in time-out kieze op jo slûzen, op jo slûzen. Jo kinne ek in no way-kommando útjaan, dat sil ... as jo it slot net daliks krije kinne. Dêrom, of in slot timeout of wat oars dat sil tastean jo te dwaan dit. Dit wurdt net dien op it syntaktyske nivo. Dit wurdt dien as in fariabele op de tsjinner. Soms kin dit net brûkt wurde.
Kinne jo dia 75 iepenje?
Ja.
En myn fraach is de folgjende. Wêrom ferwachtsje beide fernijingsprosessen 703?
En dit is in geweldige fraach. Ik begryp trouwens net wêrom Postgres dit docht. Mar doe't 703 waard makke, ferwachte it 702. En as 704 en 705 ferskine, liket it derop dat se net witte wat se ferwachtsje, om't d'r noch neat is. En Postgres docht it op dizze manier: as jo gjin slot kinne krije, skriuwt it "Wat is it punt om jo te ferwurkjen?", om't jo al op immen wachtsje. Dat wy litte it mar yn 'e loft hingje, it sil it hielendal net bywurkje. Mar wat is hjir bard? Sadree't 702 it proses foltôge en 703 syn slot krige, kaam it systeem werom. En se sei dat wy no twa minsken hawwe dy't wachtsje. En dan litte wy se tegearre bywurkje. En lit ús oanjaan dat beide yn ferwachting binne.
Ik wit net wêrom Postgres dit docht. Mar d'r is in probleem neamd f .... It liket my ta dat dit gjin term yn it Russysk is. Dit is as elkenien wachtet op ien kastiel, sels as der 20 autoriteiten binne dy't wachtsje op it kastiel. En ynienen wurde se allegearre tagelyk wekker. En elkenien begjint te besykjen te reagearjen. Mar it systeem makket it sa dat elkenien wachtet op 703. Omdat se allegearre wachtsje, en wy sille fuortendaliks line se allegearre. En as der in oar nij fersyk ferskynt dat is oanmakke nei dit, bygelyks, 707, dan sil der wer leechte.
En it liket my dat dit dien wurdt sadat wy kinne sizze dat op dit stadium 702 wachtet op 703, en al dyjingen dy't dêrnei komme, sille gjin yngong hawwe op dit fjild. Mar sa gau as de earste ober fuortgiet, krije al dyjingen dy't op dat stuit wachte foar de fernijing itselde token. En dus tink ik dat dit dien is sadat wy yn oarder kinne ferwurkje sadat se goed besteld binne.
Ik seach dit altyd as in nochal frjemd ferskynsel. Want hjir lizze wy se bygelyks hielendal net op. Mar it liket my ta dat eltse kear as wy jouwe in nij slot, wy sjogge op al dyjingen dy't yn it proses fan wachtsjen. Dan rige wy se allegear op. En dan komt elke nije dy't binnenkomt pas yn 'e wachtrige as de folgjende persoan klear is mei it ferwurkjen. Hiel goede fraach. Tige tank foar dyn fraach!
It liket my dat it folle logysker is as 705 704 ferwachtet.
Mar it probleem hjir is it folgjende. Technysk kinne jo de iene as de oare wekker meitsje. En sa sille wy de iene as de oare wekker meitsje. Mar wat bart der yn it systeem? Jo kinne sjen hoe't 703 oan 'e boppekant syn eigen transaksje-ID hat blokkearre. Dit is hoe't Postgres wurket. En 703 wurdt blokkearre troch syn eigen transaksje-ID, dus as immen wachtsje wol, dan sille se wachtsje op 703. En, yn essinsje, foltôget 703. En pas nei syn foltôging wurdt ien fan 'e prosessen wekker. En wy witte net wat dit proses krekt sil wêze. Dan ferwurkje wy alles stadichoan. Mar it is net dúdlik hokker proses earst wekker wurdt, om't it ien fan dizze prosessen kin wêze. Yn essinsje hienen wy in planner dy't sei dat wy no ien fan dizze prosessen kinne wekker meitsje. Wy kieze gewoan ien willekeurich. Sa moatte se beide opmurken wurde, om't wy ien fan har wekker kinne.
En it probleem is dat wy CP-infinity hawwe. En dêrom is it frij wierskynlik dat wy de lettere wekker kinne. En as wy bygelyks de lettere wekker meitsje, wachtsje wy op dyjinge dy't krekt it blok krige hat, sadat wy net bepale wa't krekt earst wekker wurdt. Wy meitsje gewoan sa'n situaasje, en it systeem sil se yn in willekeurige folchoarder wekker meitsje.
der binne . Sjoch, se binne ek nijsgjirrich en nuttich. It ûnderwerp is fansels ferskriklik kompleks. Tige tank, Bruce!
Boarne: www.habr.com