Malŝlosado de la Ŝlosa Administranto de Postgres. Bruce Momjian

Transskribo de la 2020-a parolado de Bruce Momjian "Malŝlosi la Postgresan Ŝlosan Administranton".

(Noto: Vi povas ricevi ĉiujn SQL-demandojn de la diapozitivoj ĉe ĉi tiu ligo: http://momjian.us/main/writings/pgsql/locking.sql)

Saluton! Estas bonege esti ĉi tie en Rusio denove. Mi bedaŭras, ke mi ne povis veni pasintjare, sed ĉi-jare Ivano kaj mi havas grandajn planojn. Mi esperas esti ĉi tie multe pli ofte. Mi amas veni al Rusio. Mi vizitos Tjumenon, Tveron. Mi tre ĝojas, ke mi povos viziti ĉi tiujn urbojn.

Mia nomo estas Bruce Momjian. Mi laboras ĉe EnterpriseDB kaj laboras kun Postgres dum pli ol 23 jaroj. Mi loĝas en Filadelfio, Usono. Mi vojaĝas ĉirkaŭ 90 tagojn jare. Kaj mi ĉeestas ĉirkaŭ 40 konferencojn. Mia Retejo, kiu enhavas la lumbildojn, kiujn mi nun montros al vi. Tial, post la konferenco vi povas elŝuti ilin de mia persona retejo. Ĝi ankaŭ enhavas ĉirkaŭ 30 prezentojn. Estas ankaŭ videoj kaj granda nombro da blogaj enskriboj, pli ol 500. Ĉi tio estas sufiĉe informa rimedo. Kaj se vi interesiĝas pri ĉi tiu materialo, tiam mi invitas vin uzi ĝin.

Mi antaŭe estis instruisto, profesoro antaŭ ol mi eklaboris kun Postgres. Kaj mi tre ĝojas, ke mi nun povas diri al vi, kion mi diros al vi. Ĉi tiu estas unu el miaj plej interesaj prezentoj. Kaj ĉi tiu prezento enhavas 110 lumbildojn. Ni komencos paroli kun simplaj aferoj, kaj je la fino de la raporto ĝi fariĝos pli kaj pli komplika, kaj ĝi fariĝos sufiĉe komplika.

Ĉi tio estas sufiĉe malagrabla konversacio. Blokado ne estas la plej populara temo. Ni volas, ke ĝi malaperu ie. Estas kiel iri al la dentisto.

1. Ŝlosado estas problemo por multaj homoj, kiuj laboras pri datumbazoj kaj havas plurajn procezojn funkciigantaj samtempe. Ili bezonas blokadon. Tio estas, hodiaŭ mi donos al vi bazajn scion pri blokado.
2. Transakciaj identigiloj. Ĉi tio estas sufiĉe enuiga parto de la prezento, sed ili devas esti komprenitaj.
3. Poste, ni parolos pri la tipoj de blokado. Ĝi estas sufiĉe mekanika parto.
4. Kaj tiam ni donos kelkajn ekzemplojn de blokado. Kaj estos sufiĉe malfacile kompreni.

Ni parolu pri blokado.

Nia terminologio estas sufiĉe komplika. Kiom da vi scias, de kie venas ĉi tiu trairejo? Du homoj. Ĝi estas de ludo nomita Colossal Cave Adventure. Ĝi estis tekstbazita komputila ludo en la 80-aj jaroj, mi pensas. Tie necesis iri en la kavernon, en la labirinton kaj la teksto ŝanĝiĝis, sed la enhavo estis proksimume sama ĉiufoje. Tiel mi memoras ĉi tiun ludon.

Kaj jen ni vidas la nomon de la seruroj, kiuj venis al ni el Orakolo. Ni uzas ilin.

Ĉi tie ni vidas terminojn, kiuj konfuzas min. Ekzemple, SHARE UPDATE ECXLUSIVE. Sekva SHARE RAW ECXLUSIVE. Sincere, ĉi tiuj nomoj ne estas tre klaraj. Ni provos konsideri ilin pli detale. Iuj enhavas la vorton "dividi", kiu signifas apartigi. Iuj enhavas la vorton "ekskluziva" - ekskluziva. Iuj enhavas ambaŭ ĉi tiujn vortojn. Mi ŝatus komenci pri kiel funkcias ĉi tiuj seruroj.

Kaj la vorto "aliro" ankaŭ estas tre grava. Kaj la vortoj "vico" - linio. Tio estas, alirdistribuo, vicodistribuo.

Alia problemo, kiun oni devas kompreni en Postgres, kiun mi bedaŭrinde ne povos trakti en mia prelego, estas MVCC. Mi havas apartan prezenton pri ĉi tiu temo en mia retejo. Kaj se vi pensas, ke ĉi tiu prezento estas malfacila, tiam MVCC verŝajne estas mia plej malfacila. Kaj se vi interesiĝas, vi povas vidi ĝin sur la retejo. Vi povas spekti la videon.

Alia afero, kiun ni devas kompreni, estas transakciaj identigiloj. Multaj transakcioj ne povas funkcii sen unikaj identigiloj. Kaj ĉi tie ni havas klarigon pri kio estas transakcio. Postgres havas du transakciajn numerajn sistemojn. Mi scias, ke ĝi ne estas tre bela solvo.

Ankaŭ memoru, ke la diapozitivoj estos sufiĉe malfacile legeblaj, do tio, kio estas elstarigita ruĝe, estas kion vi devas atenti.

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

Ni rigardas. La transakcia numero estas emfazita en ruĝa. Montrita ĉi tie estas la SELECT pg_back funkcio. Ĝi resendas mian transakcion kaj la ID de tiu transakcio.

Ankoraŭ unu afero, se vi ŝatas ĉi tiun prezenton kaj volas ruli ĝin en via datumbazo, tiam vi povas iri al ĉi tiu ligilo en rozkolora kaj elŝuti la SQL por ĉi tiu prezento. Kaj vi povas simple ruli ĝin en via PSQL kaj la tuta prezento tuj estos sur via ekrano. Ĝi ne enhavos florojn, sed almenaŭ ni povas vidi ĝin.

En ĉi tiu kazo ni vidas la transakcian ID. Jen la numero, kiun ni atribuis al ŝi. Kaj ekzistas alia speco de transakcia ID en Postgres, kiu nomiĝas virtuala transakcia ID

Kaj ni devas kompreni ĉi tion. Ĉi tio estas tre grava, alie ni ne povos kompreni ŝlosadon en Postgres.

Virtuala transakcia ID estas transakcia ID, kiu ne enhavas konstantajn valorojn. Ekzemple, se mi rulas SELECT-komandon, tiam mi plej verŝajne ne ŝanĝos la datumbazon, mi nenion ŝlosos. Do kiam ni kuras simplan SELECT, ni ne donas al tiu transakcio konstantan identigilon. Ni nur donas al ŝi virtualan identigilon tie.

Kaj ĉi tio plibonigas la agadon de Postgres, plibonigas purigajn kapablojn, do la virtuala transakcia ID konsistas el du nombroj. La unua numero antaŭ la oblikvo estas la malantaŭa ID. Kaj dekstre ni vidas nur nombrilon.

Tial, se mi plenumas peton, ĝi diras, ke la backend ID estas 2.

Kaj se mi kuras serion da tiaj transakcioj, tiam ni vidas, ke la nombrilo pliiĝas ĉiufoje kiam mi faras demandon. Ekzemple, kiam mi rulas la demandon 2/10, 2/11, 2/12, ktp.

Memoru, ke ĉi tie estas du kolumnoj. Maldekstre, ni vidas la virtualan transakcian ID - 2/12. Kaj dekstre ni havas konstantan transakcian ID. Kaj ĉi tiu kampo estas malplena. Kaj ĉi tiu transakcio ne modifas la datumbazon. Tial mi ne atribuas al ĝi konstantan transakcian ID.

Tuj kiam mi rulas la analizan komandon ((ANALYZE)), la sama demando donas al mi konstantan transakcian ID. Rigardu kiel ĉi tio ŝanĝiĝis por ni. Mi ne havis ĉi tiun identigilon antaŭe, sed nun mi havas ĝin.

Do jen alia peto, alia transakcio. La virtuala transakcia numero estas 2/13. Kaj se mi petas konstantan transakcian ID, tiam kiam mi plenumos la demandon, mi ricevos ĝin.

Do, ankoraŭ unu fojon. Ni havas virtualan transakcian ID kaj konstantan transakcian ID. Nur prenu ĉi tiun punkton por kompreni la konduton de Postgres.

Ni transiru al la tria sekcio. Ĉi tie ni nur promenos tra la malsamaj specoj de seruroj en Postgres. Ĝi ne estas tre interesa. La lasta sekcio estos multe pli interesa. Sed ni devas konsideri la bazajn aferojn, ĉar alie ni ne komprenos kio okazos poste.

Ni trairos ĉi tiun sekcion, ni rigardos ĉiun tipon de blokado. Kaj mi montros al vi ekzemplojn pri kiel ili estas instalitaj, kiel ili funkcias, montros al vi kelkajn demandojn, kiujn vi povas uzi por vidi kiel funkcias blokado en Postgres.

Por krei demandon kaj vidi kio okazas en Postgres, ni devas elsendi la demandon al la sistema vido. En ĉi tiu kazo, pg_lock estas elstarigita ruĝe. pg_lock estas sistema tabelo, kiu diras al ni, kiuj seruroj estas nuntempe uzataj en Postgres.

Tamen, estas tre malfacile por mi montri al vi pg_lock per si mem, ĉar ĝi estas sufiĉe komplika. Do mi kreis vidon kiu montras pg_locks. Kaj ĝi ankaŭ faras iun laboron por mi, kiu ebligas al mi pli bone kompreni. Tio estas, ĝi ekskludas miajn serurojn, mian propran seancon, ktp. Ĝi estas nur norma SQL kaj ĝi permesas vin pli bone montri kio okazas.

Alia problemo estas, ke ĉi tiu vidpunkto estas tre larĝa, do mi devas krei duan - lockview2.

Kaj ĝi montras al mi pliajn kolumnojn de la tabelo. Kaj alia kiu montras al mi la ceterajn kolumnojn. Ĉi tio estas sufiĉe komplika, do mi provis prezenti ĝin kiel eble plej simple.

Do, ni kreis tabelon nomitan Lockdemo. Kaj ni kreis unu linion tie. Jen nia specimena tablo. Kaj ni kreos sekciojn nur por montri al vi ekzemplojn de blokado.

Do, unu vico, unu kolumno. La unua tipo de seruro nomiĝas ACCESS SHARE. Ĉi tio estas la malplej limiga blokado. Ĉi tio signifas, ke ĝi praktike ne konfliktas kun aliaj seruroj.

Kaj se ni volas eksplicite difini seruron, ni rulas la komandon "ŝlosi tablon". Kaj ĝi eksplicite blokos, t.e. en la ACCESS SHARE-reĝimo, ni kuras la serurtabelon. Kaj se mi komencas PSQL en la fono, tiam mi komencas la duan sesion de mia unua sesio tiamaniere. Tio estas, kion mi faros ĉi tie? Mi iras al alia sesio kaj diras al ĝi "montri al mi la ŝlosilvidon por ĉi tiu peto". Kaj ĉi tie mi havas AccessShareLock sur ĉi tiu tablo. Jen ĝuste tio, kion mi petis. Kaj li diras, ke la seruro estis asignita. Tre simpla.

Plue, se ni rigardas la duan kolumnon, tiam estas nenio tie. Ili estas malplenaj.

Kaj se mi rulas la komandon "SELECT", tiam ĉi tiu estas la implica (eksplicita) maniero peti AccessShareLock. Do mi liberigas mian tabelon kaj rulas demandon kaj la demando resendas plurajn vicojn. Kaj en unu el la linioj ni vidas AccessShareLock. Do SELECT vokas AccessShareLock sur la tablo. Kaj ĝi ne konfliktas kun preskaŭ io ajn, ĉar ĝi estas malaltnivela seruro.

Kio se mi rulas SELECT kaj mi havas tri malsamajn tabelojn? Antaŭe mi prizorgis nur unu tablon, nun mi kuras tri: pg_class, pg_namespace kaj pg_attribute.

Kaj nun, kiam mi rigardas la demandon, mi vidas 9 AccessShareLocks en XNUMX tabeloj. Kial? Tri tabeloj estas emfazitaj en bluo: pg_attribute, pg_class, pg_namespace. Sed vi ankaŭ povas vidi, ke ĉiuj indeksoj, kiuj estas difinitaj per ĉi tiuj tabeloj, ankaŭ havas AccessShareLock.

Kaj ĉi tio estas blokado, kiu praktike ne konfliktas kun aliaj. Kaj ĉio, kion ĝi faras, estas nur malhelpi nin fali la tablon dum ni elektas ĝin. Ĝi havas sencon. Tio estas, se ni elektas tabelon, ĝi malaperas en tiu momento, tiam ĉi tio estas malĝusta, do AccessShare estas malaltnivela seruro kiu diras al ni "ne faligu ĉi tiun tabelon dum mi laboras". Esence, tion ŝi faras.

ROW SHARE - Ĉi tiu seruro estas iom malsama.

Ni prenu ekzemplon. SELECT ROW SHARE maniero ŝlosi ĉiun vicon individue. Tiel neniu povas forigi ilin aŭ ŝanĝi ilin dum ni rigardas ilin.

Do kion faras SHARE LOCK? Ni vidas, ke la transakcia ID estas 681 por la SELECT. Kaj ĉi tio estas interesa. Kio okazis ĉi tie? Por la unua fojo ni vidas la numeron en la kampo "Ŝlosi". Ni prenas la transakcian ID, kaj li diras, ke li blokas ĝin en ekskluziva reĝimo. Ĉio, kion ĝi faras, diras, ke mi havas vicon, kiu estas teknike ŝlosita ie en la tabelo. Sed li ne diras kie precize. Ni rigardos ĉi tion pli detale iom poste.

Ĉi tie ni diras, ke la seruro estas uzata de ni.

Do, ekskluziva seruro eksplicite (eksplicite) diras, ke ĝi estas ekskluziva. Kaj ankaŭ se vi forigas vicon en ĉi tiu tabelo, tio okazas, kiel vi povas vidi.

SHARE EXCLUSIVE estas pli longa seruro.

Ĉi tio estas (ANALIZA) la analizilo uzota.

PARTIA Ŝlosilo - Vi povas eksplicite ŝlosi en kundivida reĝimo.

Vi ankaŭ povas krei unikan indekson. Kaj tie vi povas vidi SHARE LOCK, kiu estas parto de ili. Kaj ĝi ŝlosas la tablon kaj starigas SHARE LOCK-seruron sur ĝin.

La defaŭlta SHARE LOCK sur tablo signifas ke aliaj homoj povas legi la tabelon, sed neniu povas modifi ĝin. Kaj ĝuste tio okazas kiam vi kreas unikan indekson.

Se mi kreas unikan samtempan indekson, tiam mi havos malsaman tipon de seruro, ĉar, memoru, uzi samtempe indeksojn reduktas la serurpostulon. Kaj se mi uzas normalan seruron, normalan indekson, tiam mi tiel malhelpas skribi al la indekso de la tabelo dum ĝia kreado. Se mi uzas samtempe indekson, tiam mi devas uzi alian tipon de seruro.

SHARE ROW EXCLUSIVE - denove ĝi povas esti agordita eksplicite (eksplicite).

Aŭ ni povas krei regulon, tio estas, preni iun specifan kazon en kiu ĝi estos uzata.

Ekskluziva ŝlosado signifas, ke neniu alia povas ŝanĝi la tablon.

Ĉi tie ni vidas malsamajn tipojn de seruroj.

EXCLUSIVE ALIRO, ekzemple, estas ŝlosa komando. Ekzemple, se vi faras CLUSTER table, tiam ĝi signifos, ke neniu povos skribi tie. Kaj ĝi ŝlosas ne nur la tabelon mem, sed ankaŭ la indeksojn.

Ĉi tiu estas la dua paĝo de la ACCESS EXCLUSIVE seruro kie ni vidas specife kion ĝi ŝlosas en la tabelo. Ĝi ŝlosas individuajn tablovicojn, kio estas sufiĉe interesa.

Jen ĉiuj bazaj informoj, kiujn mi volis doni. Ni parolis pri seruroj, pri transakciaj ID-oj, ni parolis pri virtualaj transakciaj ID-oj, pri konstantaj transakciaj ID-oj.

Kaj nun ni trarigardos la blokajn ekzemplojn. Ĉi tiu estas la plej interesa parto. Ni vidos tre interesajn kazojn. Kaj mia celo en ĉi tiu prezento estas doni al vi pli bonan ideon pri tio, kion Postgres efektive faras kiam ĝi provas bloki aferojn. Ŝajnas al mi, ke li tre lertas pri blokado de unuopaj partoj.

Ni rigardu kelkajn specifajn ekzemplojn.

Ni komencos per tabeloj kaj unu vico en tabelo. Kiam mi enmetas ion, mi havas ExclusiveLock, Transaction ID kaj ExclusiveLock montratajn sur la tablo.

Kio okazas se mi enmetas du pliajn vicojn? Kaj nun nia tablo havas tri vicojn. Kaj mi enmetis unu vicon kaj ricevis ĉi tion kiel eligo. Kaj se mi enmetas du pliajn vicojn, kio estas stranga ĉi tie? Estas strangaĵo ĉi tie ĉar mi aldonis tri vicojn al ĉi tiu tabelo, sed mi ankoraŭ havas du vicojn en la serurtabelo. Kaj ĉi tio estas, fakte, la fundamenta konduto de Postgres.

Multaj homoj pensas, ke se en datumbazo, vi ŝlosas 100 vicojn, tiam vi devos krei 100 ŝlosajn enirojn. Se mi blokas 1 vicojn samtempe, tiam mi bezonos 000 tiajn petojn. Kaj se mi bezonas milionon aŭ miliardon por bloki. Sed se ni faros tion, ĝi ne funkcios tre bone. Se vi uzis sistemon, kiu kreas blokajn enirojn por ĉiu unuopa vico, tiam vi povas vidi, ke ĉi tio estas komplika. Ĉar vi devas difini la serurtabelon tuj, kiu povas superflui, sed Postgres ne faras tion.

Kaj estas tre grave sur ĉi tiu glito, ke ĝi klare pruvas, ke ekzistas alia sistemo, kiu funkcias ene de MVCC, kiu blokas individuajn liniojn. Do kiam vi ŝlosas miliardojn da vicoj, Postgres ne kreas miliardojn da apartaj ŝlosaj instrukcioj. Kaj ĉi tio estas tre bona por agado.

Kio pri ĝisdatigo? Mi ĝisdatigas la vicon nun, kaj vi povas vidi, ke ĝi faris du malsamajn operaciojn samtempe. Ĝi ŝlosis la tablon samtempe, sed ĝi ankaŭ ŝlosis la indekson. Kaj li devis ŝlosi la indekson ĉar estas unikaj limoj sur ĉi tiu tablo. Kaj ni volas certigi, ke neniu ŝanĝas ĝin, do ni blokas ĝin.

Kio okazas se mi volas ĝisdatigi du vicojn? Kaj ni vidas, ke li kondutas same. Ni faras duoble pli da ĝisdatigoj, sed ĝuste la saman nombron da serurlinioj.

Se vi scivolas kiel Postgres faras tion, vi devus aŭskulti miajn paroladojn pri MVCC por ekscii kiel Postgres interne markas ĉi tiujn liniojn, kiujn ĝi ŝanĝas. Kaj Postgres havas manieron fari ĝin, sed ĝi ne faras ĝin ĉe la tablo-ŝlosa nivelo, ĝi faras ĝin je pli malalta kaj pli efika nivelo.

Kio se mi volas forigi ion? Se mi forigas, ekzemple, unu vicon kaj mi ankoraŭ havas miajn du enigojn ĉe la seruro, kaj eĉ se mi volas forigi ĉiujn, ili ankoraŭ estas tie.

Kaj, ekzemple, mi volas enmeti 1 liniojn, kaj tiam aŭ forigi aŭ aldoni 000 liniojn, tiam la individuajn liniojn, kiujn mi aldonas aŭ ŝanĝas, ili ne estas registritaj ĉi tie. Ili estas skribitaj sur pli malalta nivelo ene de la vico mem. Kaj dum la MVCC-parolado, mi detale parolis pri ĝi. Sed estas tre grave, kiam vi analizas serurojn, por certigi, ke vi havas tabelnivelan seruron kaj ke vi ne povas vidi kiel unuopaj vicoj estas skribitaj ĉi tie.

Kio pri eksplicita blokado?

Se mi klakas "refreŝigi" tiam mi havas du vicojn ŝlositaj. Kaj se mi elektas ĉiujn kaj alklakas "ĝisdatigi ĉie", tiam mi ankoraŭ havas du ŝlosilrekordojn.

Ni ne kreas apartajn enskribojn por ĉiu individua vico. Ĉar tiam rendimento malpliiĝas, eble estas tro multe da ĝi. Kaj ni povas trovi nin en malagrabla situacio.

Kaj la sama afero, se ni faras kunhava, ni povas fari ĉion 30 fojojn.

Ni restarigas nian tabelon, forigas ĉion, poste enigu unu vicon denove.

Alia speco de konduto, kiun vi vidas en Postgres, kiu estas tre konata kaj dezirata, estas ke vi povas fari ĝisdatigon aŭ elekton. Kaj vi povas fari ĝin samtempe. Kaj elektu ne blokas ĝisdatigon kaj la samon en la kontraŭa direkto. Ni diras al la leganto ne bloki la verkiston, kaj la verkisto ne blokis la leganton.

Mi montros al vi ekzemplon de ĉi tio. Mi faros elekton nun. Ni tiam faros INSERT. Kaj tiam vi povas vidi - 694. Vi povas vidi la ID de la transakcio kiu faris ĉi tiun enmeton. Kaj jen kiel ĝi funkcias.

Kaj se mi nun rigardas mian backend ID, ĝi fariĝis - 695.

Kaj mi povas vidi, ke 695 aperas en mia tabelo.

Kaj se mi ĝisdatigas ĉi tie tiel, tiam mi ricevas malsaman kazon. En ĉi tiu kazo, 695 estas ekskluziva seruro, kaj ĝisdatigo havas la saman konduton, sed ne ekzistas konflikto inter ili, kio estas sufiĉe nekutima.

Kaj vi povas rimarki, ke supre estas ShareLock kaj malsupre estas ExclusiveLock. Kaj ambaŭ transakcioj sukcesis.

Kaj vi devas aŭskulti mian paroladon ĉe MVCC por kompreni kiel tio okazas. Sed ĉi tio estas ilustraĵo pri tio, ke vi povas fari ĝin samtempe, t.e. fari SELECT kaj ĜISDATIGI samtempe.

Ni rekomencu kaj faru unu operacion denove.

Se vi provas ruli du ĝisdatigojn samtempe sur la sama vico, ĝi blokos. Kaj memoru, mi diris, ke la leganto ne baras la verkiston, sed la verkiston de la leganto, sed unu verkisto baras alian verkiston. Tio estas, ni ne povas havi du homojn ĝisdatigi la saman vicon samtempe. Vi devas atendi ĝis unu el ili finiĝos.

Kaj por ilustri ĉi tion, mi rigardos la tablon Lockdemo. Kaj ni rigardos unu vicon. Por transakcio 698.

Ni ĝisdatigis ĉi tion al 2. 699 estas la unua ĝisdatigo. Kaj ĝi sukcesis aŭ ĝi estas en pritraktata transakcio kaj atendas nin konfirmi aŭ nuligi.

Sed rigardu ion alian - 2/51 estas nia unua transakcio, nia unua sesio. 3/112 estas la dua peto, kiu venis de la supro, kiu ŝanĝis tiun valoron al 3. Kaj se vi rimarkas, la supro ŝlosis sin, kiu estas 699. Sed 3/112 ne donis la seruron. La kolumno Lock_mode diras, ke ĝi atendas. Li atendas 699. Kaj se vi rigardas kie estas 699, li estas pli alta. Kaj kion faris la unua sesio? Ŝi kreis ekskluzivan seruron sur sia propra transakcia ID. Jen kiel Postgres faras ĝin. Ĝi blokas sian propran transakcian ID. Kaj se vi volas atendi ke iu konfirmos aŭ nuligos, tiam vi devas atendi dum estas pritraktata transakcio. Kaj tiel ni povas vidi strangan linion.

Ni rigardu denove. Maldekstre ni vidas nian pretigan ID. En la dua kolumno ni vidas nian virtualan transakcian ID, kaj en la tria ni vidas lock_type. Kion ĉi tio signifas? Fakte, ŝi diras, ke ŝi blokas la transakcian ID. Sed rimarku, ke en ĉiuj vicoj malsupre estas skribita rilato. Kaj do vi havas du specojn de seruroj sur la tablo. Estas rilato seruro. Kaj tiam estas la transakciid-blokado, kie vi blokas memstare, kio estas ĝuste kio okazas sur la unua vico aŭ ĉe la malsupro, kie la transakciid estas, kie ni atendas 699 por fini sian operacion.

Mi vidas, kio okazas ĉi tie. Kaj ĉi tie du aferoj okazas samtempe. Vi rigardas la transakcian ID-seruron en la unua vico, kiu ŝlosas sin. Kaj ŝi blokas sin por atendi homojn.

Se vi rigardas la 6-an linion, ĝi estas la sama enskribo kiel la unua. Kaj do transakcio 699 estas blokita. 700 ankaŭ estas memŝlosa. Kaj tiam en la malsupra vico vi vidos, ke ni atendas ke 699 kompletigu ĝian funkciadon.

Kaj en lock_type, opo vi vidas nombrojn.

Vi povas vidi, ke ĝi estas 0/10. Kaj ĉi tio estas la paĝonumero, kaj ankaŭ la ofseto de ĉi tiu aparta vico.

Kaj vi vidas, kio fariĝas 0/11 kiam ni ĝisdatigas.

Sed fakte, ĝi estas 0/10, ĉar estas atendo por ĉi tiu operacio. Ni havas la ŝancon vidi, ke ĉi tiu estas la vico, kiun mi atendas por konfirmi.

Post kiam ni konfirmis ĝin kaj premis kommit, kaj kiam la ĝisdatigo estas finita, ĉi tio estas kion ni ricevas denove. Transakcio 700 estas la sola seruro, ĝi ne atendas iun alian, ĉar ĝi estis farita. Ĝi nur atendas ke la transakcio finiĝos. Post kiam 699 finiĝas, ni ne atendas ion alian. Kaj nun transakcio 700 diras, ke ĉio estas en ordo, ke ĝi havas ĉiujn serurojn, kiujn ĝi bezonas en ĉiuj permesitaj tabeloj.

Kaj por pli kompliki la tuton, ni kreas alian vidon, kiu ĉi-foje provizos al ni hierarkion. Mi ne atendas, ke vi komprenos ĉi tiun peton. Sed ĝi donos al ni pli klaran vidon pri kio okazas.

Ĉi tio estas rekursiva vido kiu ankaŭ havas alian sekcion. Kaj tiam ĝi denove kunigas ĉion. Ni uzu ĉi tion.

Kio se ni faras tri samtempajn ĝisdatigojn kaj diras, ke la vico nun estas tri. Kaj ni ŝanĝos 3 al 4.

Kaj ĉi tie ni vidas 4. Kaj transakcia ID 702.

Kaj tiam mi interŝanĝos 4 por 5. Kaj 5 por 6, kaj 6 por 7. Kaj mi vicigas kelkajn homojn por atendi ke ĉi tiu transakcio finiĝos.

Kaj ĉio iĝas klara. Kio estas la unua vico? Ĉi tio estas 702. Ĉi tiu estas la transakcia ID kiu origine starigis ĉi tiun valoron. Kion mi havas en la kolumno Koncedita? Mi havas markojn f. Ĉi tiuj estas miaj ĝisdatigoj kiuj (5, 6, 7) ne povas esti aprobitaj ĉar ni atendas ke transakcia ID 702 eksvalidiĝos. Tie ni havas transakcian ID-seruron. Kaj rezultas 5 transakciaj seruroj ID.

Kaj se oni rigardas 704, 705, tie ankoraŭ nenio estas skribita, ĉar oni ankoraŭ ne scias, kio okazas. Ili nur skribas, ke ili ne havas ideon, kio okazas. Kaj ili nur endormiĝos, ĉar ili atendas ke iu finos kaj ili vekiĝos, kiam eblos ŝanĝi la vicon.

Jen kiel ĝi aspektas. Estas klare, ke ili ĉiuj atendas la 12-an linion.

Jen kion ni vidis ĉi tie. Jen 0/12.

Do, post kiam la unua transakcio estas aprobita, tiam vi povas vidi kiel la hierarkio funkcias ĉi tie. Kaj nun ĉio estas klara. Ili ĉiuj fariĝas puraj. Kaj ili efektive ankoraŭ atendas.

Jen kio okazas. 702 faras. Kaj nun 703 ricevas ĉi tiun vicon, kaj tiam 704 komencas atendi ke 703 fariĝu. Kaj la 705 ankaŭ atendas ĉi tion. Kaj kiam ĉio ĉi estas finita, ili purigas sin. Kaj mi ŝatus atentigi, ke ĉiuj viciĝas. Kaj ĝi tre similas al la trafikŝtopiĝo, kie ĉiuj atendas la unuan aŭton. La unua aŭto haltis kaj ĉiuj viciĝas en longa vico. Tiam ĝi moviĝas, tiam la sekva aŭto povas veturi antaŭen kaj ricevi sian blokon, ktp.

Kaj se ŝajnis al vi ne sufiĉe malfacila, tiam ni nun parolos kun vi pri blokiĝo. Mi ne scias, kiu el vi spertis ilin. Ĉi tio estas sufiĉe ofta problemo en datumbazaj sistemoj. Sed blokiĝo estas kiam unu sesio atendas ke alia sesio faru ion. Kaj en tiu momento alia sesio atendas la unuan sesion por fari ion.

Kaj, ekzemple, se Ivano diras: "Donu ion al mi", kaj mi diras: "Ne, mi donos ĝin al vi nur se vi donos al mi ion alian." Kaj li diras: "Ne, mi ne donos ĝin al vi, se vi ne donos ĝin al mi." Kaj ni finiĝas en blokiĝo situacio. Mi certas, ke Ivano ne faros tion, sed vi komprenas, ke ni havas du homojn dezirantaj ion kaj ili ne pretas fordoni ĝin ĝis la alia persono donos al ili kion ili volas. Kaj ne ekzistas solvo.

Kaj, fakte, via datumbazo bezonas detekti ĉi tion. Kaj tiam vi devas forigi aŭ fermi unu el la sesioj, ĉar alie ili restos tie por ĉiam. Kaj ni vidas ĝin en datumbazoj, ni vidas ĝin en operaciumoj. Kaj en ĉiuj lokoj, kie ni havas paralelajn procezojn, tio povas okazi.

Kaj ni metos du blokiĝon nun. Ni metos 50 kaj 80. En la unua vico, mi ĝisdatigos de 50 ĝis 50. Mi ricevos transakcian numeron 710.

Kaj tiam mi ŝanĝos 80 al 81, kaj 50 al 51.

Kaj jen kiel ĝi aspektos. Kaj do 710 havas vicŝlosilon, kaj 711 atendas konfirmon. Ni vidis ĝin kiam ni ĝisdatigis. 710 - estas la posedanto de nia serio. Kaj 711 atendas 710 por kompletigi la transakcion.

Kaj ĝi eĉ diras sur kiu vico ni havas blokiĝon. Kaj ĉi tie ĝi komencas fariĝi stranga.

Nun ni ĝisdatigas 80 ĝis 80.

Kaj tie komenciĝas la blokiĝo. 710 atendas respondon de 711, kaj 711 atendas 710. Kaj tio ne finiĝos bone. Kaj ne ekzistas eliro el ĉi tio. Kaj ili atendos respondon unu de la alia.

Kaj ĝi nur komencos prokrasti ĉion. Kaj ni ne volas tion.

Kaj Postgres havas manierojn rimarki kiam tio okazas. Kaj kiam tio okazas, vi ricevas ĉi tiun eraron. Kaj de ĉi tio estas klare, ke tia kaj tia procezo atendas SHARE LOCK de alia procezo, t.e., kiu estas blokita de la 711-procezo. Kaj tiu procezo atendis ke SHARE LOCK estu donita al tia kaj tia transakcia ID kaj esti blokita per tia kaj tia procezo. Tial, ekzistas situacio de morta blokado.

Ĉu ekzistas tridirekta blokiĝo? Ĉu eblas? Jes.

Ni kondukas ĉi tiujn nombrojn en la tabelon. Ni ŝanĝas 40 al 40, ni faras seruron.

Ŝanĝu 60 al 61, 80 al 81.

Kaj tiam ni ŝanĝas 80 kaj poste bum!

Kaj 714 nun atendas 715. 716 atendas 715. Kaj estas nenio farenda pri tio.

Ne plu estas du homoj, jam estas tri homoj. Mi volas ion de vi, ĉi tiu volas ion de la tria persono, kaj la tria persono volas ion de mi. Kaj ni finiĝas en tridirekta atendo ĉar ni ĉiuj atendas ke la alia persono kompletigos tion, kion ili devas fari.

Kaj Postgres scias sur kiu vico ĝi okazas. Kaj do ĝi donos al vi la sekvan mesaĝon, kiu montras, ke vi havas problemon, kie tri enigoj blokas unu la alian. Kaj ne estas limigoj ĉi tie. Ĉi tio povas esti la kazo kie 20 eniroj blokas unu la alian.

La sekva problemo estas seriigebla.

Se speciala seriigebla seruro.

Kaj ni revenas al 719. Li havas tute normalan aferon.

Kaj vi povas puŝi por fari transakcion de seriigebla.

Kaj vi rimarkas, ke vi nun havas alian specon de SA-seruro - ĝi signifas seriigebla.

Kaj do ni havas novan specon de seruro nomata SARieadLock, kiu estas seria seruro kaj permesas vin enigi seriajn numerojn.

Kaj ankaŭ vi povas enmeti unikajn indeksojn.

En ĉi tiu tabelo ni havas unikajn indeksojn.

Do se mi enmetas la numeron 2 ĉi tie, tial mi havas 2. Sed supre, mi enmetis alian 2. Kaj vi povas vidi, ke la 721 havas ekskluzivan seruron. Sed nun 722 atendas ke 721 kompletigu sian operacion ĉar ĝi ne povas enmeti 2 ĝis ĝi scias kio okazos al 721.

Kaj se ni faras subtransakcion.

Ĉi tie ni havas 723.

Kaj se ni konservas la punkton kaj poste ĝisdatigas ĝin, tiam ni ricevas novan transakcian ID. Ĉi tio estas alia konduto, pri kiu vi devas esti konscia. Se ni resendas tion, tiam la transakcia ID malaperis. 724 foriras. Sed nun ni havas 725.

Kaj kion mi provas fari ĉi tie? Mi provas montri al vi ekzemplojn de nekutimaj seruroj, kiujn vi povas trovi: ĉu seriigeblaj seruroj aŭ SAVEPOINT-seruroj, ĉi tiuj estas malsamaj specoj de seruroj, kiuj aperos en la serurotabelo.

Ĉi tio estas la kreado de eksplicitaj (eksplicitaj) seruroj, kiuj havas pg_advisory_lock.

Kaj vi povas vidi, ke la seruro tipo estas listigita ĉi tie kiel konsila. Kaj ĉi tie ĝi diras "konsilan" ruĝe. Kaj vi povas samtempe bloki per pg_advisory_unlock.

Kaj konklude, mi ŝatus montri al vi ankoraŭ unu mensblovigan aferon. Mi kreos alian vidon. Sed mi aliĝos al la tabelo pg_locks kun la tabelo pg_stat_activity. Kaj kial mi volas fari ĉi tion? Ĉar ĝi permesos al mi rigardi kaj vidi ĉiujn nunajn sesiojn kaj vidi kiajn serurojn ili atendas. Kaj estas sufiĉe interese, kiam ni kunmetas serurtabelon kaj demandtabelon.

Kaj ĉi tie ni kreas pg_stat_view.

Kaj ni ĝisdatigas la vicon de unu. Kaj ĉi tie ni vidas 724. Kaj tiam ni ĝisdatigas nian vicon al tri. Kaj kion vi nun vidas ĉi tie? Ĉi tiuj estas petoj, t.e. vi vidas la tutan liston de petoj listigitaj en la maldekstra kolumno. Kaj tiam sur la dekstra flanko vi povas vidi serurojn kaj kion ili kreas. Kaj ĝi povas esti pli komprenebla por vi, por ke vi ne devas ĉiufoje reiri al ĉiu sesio kaj vidi ĉu vi bezonas aliĝi al ĝi aŭ ne. Ili faras ĝin por ni.

Alia trajto kiu estas tre utila estas pg_blocking_pids. Vi verŝajne neniam aŭdis pri ŝi. Kion ŝi faras? Ĝi permesas al ni diri, ke por ĉi tiu sesio 11740 kiajn procezidentigilojn ĝi atendas. Kaj vi povas vidi, ke 11740 atendas 724. Kaj 724 estas ĉe la supro. Kaj 11306 estas via proceza ID. Esence, ĉi tiu funkcio iras super via seruro tablo. Kaj mi scias, ke ĝi estas iom komplika, sed vi komprenas la ideon. Esence, ĉi tiu funkcio trairas ĉi tiun serurtabelon kaj provas trovi kie ĉi tiu proceza ID estas, donita la serurojn kiujn ĝi atendas. Kaj ĝi ankaŭ provas eltrovi kiun procezan ID havas la procezo, kiu atendas la seruron. Do vi povas ruli ĉi tiun funkcion pg_blocking_pids.

Kaj ĉi tio estas tre utila. Ni aldonis ĉi tion nur ekde la versio 9.6, do ĉi tiu funkcio aĝas nur 5 jarojn, sed ĝi estas tre, tre utila. Kaj same validas por la dua peto. Ĝi montras ĝuste tion, kion ni bezonas vidi.

Jen pri kio mi volis paroli kun vi. Kaj kiel mi atendis, ni uzis la tutan tempon ĉar estis tiom da lumbildoj. Kaj la diapozitivoj estas disponeblaj por elŝuto. Mi ŝatus danki vin pro esti ĉi tie. Mi certas, ke vi ĝuos la reston de la konferenco, koran dankon!

Demandoj:

Ekzemple, se mi provas ĝisdatigi la vicojn, kaj la dua sesio provas forigi la tutan tabelon. Laŭ mia kompreno, devus ekzisti io kiel intenca seruro. Ĉu ekzistas tia afero en Postgres?

Ni revenas al la komenco mem. Vi eble memoras, ke kiam vi faras ion ajn, kiel kiam vi faras SELECT, ni eldonas AccessShareLock. Kaj ĝi malhelpas ke la tablo estu faligita. Do se vi, ekzemple, volas ĝisdatigi vicon en tabelo aŭ forigi vicon, tiam iu ne povas forigi la tutan tabelon samtempe, ĉar vi tenas ĉi tiun AccessShareLock super la tuta tablo kaj super la vico. Kaj post kiam vi finos, ili povas forigi ĝin. Sed dum vi rekte ŝanĝas ion tie, ili ne povos fari ĝin.

Ni faru ĝin denove. Ni transiru al la forigita ekzemplo. Kaj vi vidas kiel la vico havas ekskluzivan seruron super la tuta tablo.

Ĝi aspektos kiel ekskluziva seruro, ĉu ne?

Jes, ĝi aspektas kiel ĝi. Mi komprenas, pri kio vi parolas. Ĉu vi diras, ke se mi faras SELECT tiam mi havas ShareExclusive kaj tiam mi metas tion en Row Exclusive staton, ĉu tio fariĝas problemo? Sed mirinde ĉi tio ne prezentas problemon. Estas kiel pliigi la gradon de la seruro, sed esence mi havas seruron kiu malhelpas ĝin esti forigita. Kaj nun, kiam mi plifortigas ĉi tiun ŝlosilon, ĝi ankoraŭ malhelpas forigon. Do ne estas kvazaŭ mi supreniras. T.e. ĝi malhelpis ĝin ankaŭ kiam ĝi estis sur pli malalta nivelo, do kiam mi levas ĝin, ĝi ankoraŭ malhelpas la tablon fali.

Mi komprenas, pri kio vi parolas. Ne estas kazo de pliigo de la grado de blokado, kie vi provas rezigni unu blokon por enkonduki pli potencan. Ĉi tie ĝi nur pliigas ĉi tiun evitadon ĉie, do ĝi ne kaŭzas ajnan konflikton. Sed ĝi estas bona demando. Koran dankon pro demandi!

Kion ni devas fari por eviti blokiĝon kiam ni havas multajn sesiojn, grandan nombron da uzantoj?

Postgres aŭtomate rimarkas situaciojn de blokiĝo. Kaj ĝi aŭtomate forigos unu el la sesioj. La nura maniero eviti mortan blokadon estas bloki homojn en la sama ordo. Do kiam vi rigardas vian aplikaĵon, ofte la kialon de blokiĝo... Ni imagu, ke mi volas bloki du malsamajn aferojn. Unu aplikaĵo ŝlosas tabelon 1, kaj alia aplikaĵo ŝlosas 2, kaj poste tabelon 1. Kaj la plej facila maniero eviti blokiĝon estas rigardi vian aplikaĵon kaj provi certigi, ke la ŝlosado okazas en la sama ordo tra ĉiuj aplikaĵoj. Kaj ĉi tio kutime forigas 80% de la problemoj, ĉar ĉiaj homoj skribas ĉi tiujn aplikojn. Kaj se vi blokas ilin en la sama ordo, tiam vi ne renkontas blokiĝon.

Koran dankon pro via agado! Vi parolis pri vakuo plena kaj, se mi bone komprenas, vakuo plena deformas la ordon de diskoj en aparta vendejo, do ĝi tenas la nunajn rekordojn senŝanĝe. Kial vakuo plena prenas ekskluzivan seruran aliron kaj kial ĝi konfliktas kun skribaj operacioj?

Tio estas bona demando. La kialo estas, ke plenplena vakuo prenas tablon. Kaj ni esence kreas novan version de la tabelo. Kaj la tablo estos nova. Rezultas, ke ĝi estos tute nova versio de la tablo. Kaj la problemo estas, ke kiam ni faras tion, ni ne volas, ke homoj legu ĝin ĉar ni volas, ke ili vidu la novan tabelon. Kaj do ĉi tio rilatas al la antaŭa demando. Se ni povus legi samtempe, tiam ni ne povus movi ĝin kaj direkti homojn al nova tablo. Ni devus atendi ke ĉiuj finos legi ĉi tiun tabelon, kaj do, esence, ĉi tio estas ŝlosila ekskluziva situacio.
Ni nur diras, ke ni ŝlosas de la komenco ĉar ni scias, ke ni bezonos ekskluzivan seruron ĉe la fino por movi ĉiujn al la nova kopio. Do eble ni povas solvi ĝin. Kaj jen kiel ni faras ĝin kun samtempa indeksado. Sed ĉi tio estas multe pli malfacile fari. Kaj ĉi tio tre forte validas por via antaŭa demando pri ekskluziva seruro.

Ĉu eblas aldoni ŝlosiltempon en Postgres? En Oracle, mi povas, ekzemple, skribi "elekti ĝisdatigi" kaj atendi 50 sekundojn antaŭ ĝisdatigi. Ĝi estis bona por la aplikaĵo. Sed en Postgres, mi aŭ devas fari tion tuj kaj tute ne atendi, aŭ atendi ĝis iom da tempo.

Jes, vi povas elekti tempon ĉe viaj seruroj, ĉe viaj seruroj. Vi ankaŭ povas eldoni nenian komandon, kiu faros... se vi ne povas tuj akiri la seruron. Sekve, ĉu ŝlosiltempo aŭ io alia, kiu permesos al vi fari tion. Ĉi tio ne estas farita je la sintaksa nivelo. Ĉi tio estas farita kiel variablo sur la servilo. Kelkfoje ĉi tio ne povas esti uzata.

Ĉu vi povas malfermi gliton 75?

Jes.

Kaj mia demando estas la sekva. Kial ambaŭ ĝisdatigaj procezoj atendas 703?

Kaj tio estas bonega demando. Mi ne komprenas kial Postgres faras tion, cetere. Sed kiam 703 estis kreita, ĝi atendis 702. Kaj kiam 704 kaj 705 aperas, ili ŝajne ne scias, kion ili atendas, ĉar ankoraŭ estas nenio tie. Kaj Postgres faras tion tiel: kiam vi ne povas ricevi seruron, ĝi diras "Kial estas prilabori vin?", Ĉar vi jam atendas iun. Do simple lasu ĝin pendi en la aero, ĝi tute ne ĝisdatigas ĝin. Sed kio okazis ĉi tie? Tuj kiam 702 kompletigis la procezon kaj 703 ricevis ĝian seruron, la sistemo revenis reen. Kaj ŝi diris, ke nun ni havas du homojn, kiuj atendas. Kaj tiam ni ĝisdatigu ilin kune. Kaj indiku, ke ambaŭ estas atendataj.

Mi ne scias kial Postgres faras tion. Sed estas problemo nomata f.... Ŝajnas al mi, ke ĉi tio ne estas termino en la rusa. Jen kiam ĉiuj atendas unu kastelon, eĉ se estas 20 okazoj kiuj atendas la kastelon. Kaj subite ili ĉiuj vekiĝas samtempe. Kaj ĉiuj komencas provi reagi. Sed la sistemo faras tiel, ke ĉiuj atendas 703. Ĉar ili ĉiuj atendas, kaj ni tuj vicigos ilin ĉiujn. Kaj se aperas iu alia nova peto, kiu estis formita post tio, ekzemple 707, tiam denove estos malpleno.

Kaj ŝajnas al mi, ke tio estas farita por povi diri, ke en ĉi tiu etapo 702 atendas 703, kaj ĉiuj, kiuj venos post tio, ili ne havos neniun eniron en ĉi tiu kampo. Sed tuj kiam la unua kelnero foriras, kaj ĉiuj tiuj, kiuj atendis en tiu momento antaŭ la ĝisdatigo, ricevas la saman signon. Kaj do ŝajnas al mi, ke tio estas farita por ke ni povu prilabori en ordo, por ke ili estu ĝuste ordigitaj.

Mi ĉiam rigardis tion kiel iom strangan fenomenon. Ĉar ĉi tie, ekzemple, ni tute ne listigas ilin. Sed ŝajnas al mi, ke ĉiufoje, kiam ni donas novan seruron, ni rigardas ĉiujn, kiuj atendas. Tiam ni vicigas ilin ĉiujn. Kaj tiam ĉiu nova kiu envenas nur eniras la atendovicon kiam la sekva persono finiĝis prilaborita. Tre bona demando. Koran dankon pro via demando!

Ŝajnas al mi multe pli logika, kiam 705 atendas 704.

Sed la problemo ĉi tie estas la sekva. Teknike, vi povas veki aŭ unu aŭ tiun. Kaj tiel ni vekiĝas unu aŭ la alian. Sed kio okazas en la funkciado de la sistemo? Vi povas vidi kiel 703 ĉe la plej supro blokis sian propran transakcian ID. Tiel funkcias Postgres. Kaj 703 estas blokita de sia propra transakcia ID, do se iu volas atendi, tiam li atendos 703. Kaj, fakte, 703 kompletigas. Kaj nur post ĝia kompletigo, unu el la procezoj vekiĝas. Kaj ni ne scias, kia procezo ĝi estos. Poste ni iom post iom prilaboras ĉion. Sed ne estas klare, kiu procezo vekiĝas unue, ĉar ĝi povus esti iu el ĉi tiuj procezoj. Esence, ni havis planilon, kiu diris, ke ni nun povus veki iun el ĉi tiuj procezoj. Ni simple elektas unu hazarde. Tial oni devas noti ambaŭ el ili, ĉar ni povas veki iun el ili.

Kaj la problemo estas, ke ni havas CP-senfinecon. Kaj tial, estas sufiĉe verŝajne, ke ni povas veki la postan. Kaj se ni ekzemple vekas la postan, ni atendos tiun, kiu ĵus ricevis la blokon, do ni ne determinos, kiu ĝuste estos vekita unue. Ni simple kreas tian situacion, kaj la sistemo vekos ilin en hazarda ordo.

Ekzistas artikoloj pri la seruroj de Egor Rogov. Rigardu, ili ankaŭ estas interesaj kaj utilaj. La temo estas, kompreneble, terure kompleksa. Multan dankon Bruce!

fonto: www.habr.com