Transkription von Bruce Momjians Vortrag „Unlocking the Postgres Lock Manager“ aus dem Jahr 2020.
(Hinweis: Sie können alle SQL-Abfragen von den Folien unter diesem Link abrufen: )
Hallo! Es ist großartig, wieder hier in Russland zu sein. Es tut mir leid, dass ich letztes Jahr nicht kommen konnte, aber dieses Jahr haben Ivan und ich große Pläne. Ich hoffe, noch öfter hier zu sein. Ich liebe es, nach Russland zu kommen. Ich werde Tjumen, Twer besuchen. Ich bin sehr froh, dass ich diese Städte besuchen kann.
Mein Name ist Bruce Momjian. Ich arbeite bei EnterpriseDB und arbeite seit über 23 Jahren mit Postgres. Ich lebe in Philadelphia, USA. Ich reise etwa 90 Tage im Jahr. Und ich besuche etwa 40 Konferenzen. Mein , das die Folien enthält, die ich Ihnen jetzt zeigen werde. Daher können Sie sie nach der Konferenz von meiner persönlichen Website herunterladen. Es enthält außerdem etwa 30 Vorträge. Außerdem gibt es Videos und eine große Anzahl von Blogeinträgen, mehr als 500. Dies ist eine ziemlich informative Ressource. Und wenn Sie an diesem Material interessiert sind, dann lade ich Sie ein, es zu nutzen.
Ich war Lehrer und Professor, bevor ich anfing, bei Postgres zu arbeiten. Und ich bin sehr froh, dass ich Ihnen nun sagen kann, was ich Ihnen sagen werde. Dies ist einer meiner interessantesten Vorträge. Und diese Präsentation enthält 110 Folien. Wir beginnen mit einfachen Dingen zu sprechen, und am Ende des Berichts wird es immer komplizierter, und es wird ziemlich kompliziert.
Das ist ein ziemlich unangenehmes Gespräch. Blockieren ist nicht das beliebteste Thema. Wir wollen, dass es irgendwo verschwindet. Es ist, als würde man zum Zahnarzt gehen.
- Für viele Leute, die mit Datenbanken arbeiten und mehrere Prozesse gleichzeitig ausführen, ist das Sperren ein Problem. Sie müssen blockiert werden. Das heißt, heute werde ich Ihnen grundlegende Kenntnisse zum Blockieren vermitteln.
- Transaktions-IDs. Dies ist ein eher langweiliger Teil der Präsentation, aber sie müssen verstanden werden.
- Als nächstes werden wir über die Arten der Blockierung sprechen. Es ist ein ziemlich mechanisches Teil.
- Und dann geben wir einige Beispiele für das Blockieren. Und es wird ziemlich schwer zu verstehen sein.
Lassen Sie uns über das Blockieren sprechen.
Unsere Terminologie ist ziemlich kompliziert. Wie viele von euch wissen, woher diese Passage kommt? Zwei Menschen. Es stammt aus einem Spiel namens Colossal Cave Adventure. Ich glaube, es war ein textbasiertes Computerspiel in den 80ern. Dort musste man in die Höhle, ins Labyrinth gehen und der Text änderte sich, aber der Inhalt war jedes Mal ungefähr derselbe. So erinnere ich mich an dieses Spiel.
Und hier sehen wir den Namen der Sperren, die von Oracle zu uns kamen. Wir benutzen sie.
Hier sehen wir Begriffe, die mich verwirren. Beispiel: SHARE UPDATE ECXLUSIVE. Weiter RAW ECXLUSIVE TEILEN. Ehrlich gesagt sind diese Namen nicht sehr klar. Wir werden versuchen, sie genauer zu betrachten. Einige enthalten das Wort „teilen“, was „trennen“ bedeutet. Einige enthalten das Wort „exklusiv“ – exklusiv. Einige enthalten beide Wörter. Ich möchte damit beginnen, wie diese Schlösser funktionieren.
Und auch das Wort „Zugang“ ist sehr wichtig. Und die Worte „Reihe“ – eine Linie. Das heißt, Zugriffsverteilung, Zeilenverteilung.
Ein weiteres Problem, das in Postgres verstanden werden muss und auf das ich in meinem Vortrag leider nicht eingehen kann, ist MVCC. Zu diesem Thema habe ich auf meiner Website einen eigenen Vortrag. Und wenn Sie denken, dass diese Präsentation schwierig ist, dann ist MVCC wahrscheinlich meine schwierigste. Und wenn Sie interessiert sind, können Sie es auf der Website sehen. Sie können das Video ansehen.
Eine andere Sache, die wir verstehen müssen, sind Transaktions-IDs. Viele Transaktionen können ohne eindeutige Identifikatoren nicht funktionieren. Und hier haben wir eine Erklärung, was eine Transaktion ist. Postgres verfügt über zwei Transaktionsnummerierungssysteme. Ich weiß, dass es keine sehr schöne Lösung ist.
Bedenken Sie auch, dass die Folien recht schwer zu lesen sein werden. Sie müssen also auf die rot hervorgehobenen Elemente achten.
Wir schauen. Die Transaktionsnummer wird rot hervorgehoben. Hier ist die Funktion SELECT pg_back dargestellt. Es gibt meine Transaktion und die ID dieser Transaktion zurück.
Und noch etwas: Wenn Ihnen diese Präsentation gefällt und Sie sie in Ihrer Datenbank ausführen möchten, können Sie diesem rosa hervorgehobenen Link folgen und die SQL für diese Präsentation herunterladen. Und Sie können es einfach in Ihrem PSQL ausführen und die gesamte Präsentation wird im Handumdrehen auf Ihrem Bildschirm angezeigt. Es wird keine Blumen enthalten, aber wir können es zumindest sehen.
In diesem Fall sehen wir die Transaktions-ID. Dies ist die Nummer, die wir ihr zugewiesen haben. Und in Postgres gibt es eine andere Art von Transaktions-ID, die sogenannte virtuelle Transaktions-ID
Und wir müssen das verstehen. Dies ist sehr wichtig, sonst können wir das Sperren in Postgres nicht verstehen.
Eine virtuelle Transaktions-ID ist eine Transaktions-ID, die keine konstanten Werte enthält. Wenn ich beispielsweise einen SELECT-Befehl ausführe, werde ich höchstwahrscheinlich die Datenbank nicht ändern und nichts sperren. Wenn wir also ein einfaches SELECT ausführen, geben wir dieser Transaktion keine permanente ID. Wir geben ihr dort nur einen virtuellen Ausweis.
Dies verbessert die Leistung von Postgres und die Bereinigungsfähigkeit, sodass die virtuelle Transaktions-ID aus zwei Zahlen besteht. Die erste Zahl vor dem Schrägstrich ist die Backend-ID. Und rechts sehen wir nur einen Zähler.
Wenn ich also eine Anfrage ausführe, heißt es, dass die Backend-ID 2 ist.
Und wenn ich eine Reihe solcher Transaktionen ausführe, sehen wir, dass der Zähler jedes Mal erhöht wird, wenn ich die Abfrage ausführe. Zum Beispiel, wenn ich die Abfrage 2/10, 2/11, 2/12 usw. ausführe.
Beachten Sie, dass es hier zwei Spalten gibt. Auf der linken Seite sehen wir die virtuelle Transaktions-ID – 2/12. Und rechts haben wir eine permanente Transaktions-ID. Und dieses Feld ist leer. Und diese Transaktion verändert die Datenbank nicht. Daher vergebe ich ihm keine dauerhafte Transaktions-ID.
Sobald ich den Analysebefehl ( (ANALYZE)) ausführe, erhalte ich mit derselben Abfrage eine permanente Transaktions-ID. Sehen Sie, wie wir uns verändert haben. Früher hatte ich diese ID nicht, jetzt habe ich sie.
Hier ist also eine weitere Anfrage, eine weitere Transaktion. Die virtuelle Transaktionsnummer ist 2/13. Und wenn ich nach einer permanenten Transaktions-ID frage, erhalte ich sie, wenn ich die Anfrage ausführe.
Also noch einmal. Wir haben eine virtuelle Transaktions-ID und eine permanente Transaktions-ID. Nehmen Sie einfach diesen Punkt, um das Verhalten von Postgres zu verstehen.
Wir gehen zum dritten Abschnitt über. Hier gehen wir einfach durch die verschiedenen Arten von Schleusen in Postgres. Es ist nicht sehr interessant. Der letzte Abschnitt wird viel interessanter sein. Aber wir müssen die grundlegenden Dinge bedenken, sonst verstehen wir nicht, was als nächstes passieren wird.
Wir werden diesen Abschnitt durchgehen und uns jede Art von Blockierung ansehen. Und ich zeige Ihnen Beispiele dafür, wie sie installiert werden, wie sie funktionieren, und zeige Ihnen einige Abfragen, mit denen Sie sehen können, wie das Blockieren in Postgres funktioniert.
Um eine Abfrage zu erstellen und zu sehen, was in Postgres vor sich geht, müssen wir die Abfrage an die Systemansicht senden. In diesem Fall wird pg_lock rot hervorgehoben. pg_lock ist eine Systemtabelle, die uns sagt, welche Sperren derzeit in Postgres verwendet werden.
Es fällt mir jedoch sehr schwer, Ihnen pg_lock allein zu zeigen, da es ziemlich kompliziert ist. Also habe ich eine Ansicht erstellt, die pg_locks anzeigt. Und es bringt mir auch etwas Arbeit, die es mir ermöglicht, es besser zu verstehen. Das heißt, es schließt meine Sperren, meine eigene Sitzung usw. aus. Es ist nur Standard-SQL und ermöglicht es Ihnen, besser zu zeigen, was vor sich geht.
Ein weiteres Problem besteht darin, dass diese Ansicht sehr breit ist, sodass ich eine zweite erstellen muss – lockview2.
Und es zeigt mir weitere Spalten aus der Tabelle. Und noch eine, die mir den Rest der Spalten zeigt. Das ist ziemlich kompliziert, deshalb habe ich versucht, es so einfach wie möglich darzustellen.
Deshalb haben wir eine Tabelle namens Lockdemo erstellt. Und wir haben dort eine Zeile erstellt. Dies ist unsere Beispieltabelle. Und wir werden Abschnitte erstellen, um Ihnen Beispiele für das Blockieren zu zeigen.
Also eine Zeile, eine Spalte. Der erste Sperrtyp heißt ACCESS SHARE. Dies ist die am wenigsten restriktive Blockierung. Dies bedeutet, dass es praktisch keine Konflikte mit anderen Schlössern gibt.
Und wenn wir explizit eine Sperre definieren möchten, führen wir den Befehl „Tabelle sperren“ aus. Und es wird explizit blockiert, d. h. im ACCESS SHARE-Modus führen wir die Sperrtabelle aus. Und wenn ich PSQL im Hintergrund starte, dann starte ich auf diese Weise die zweite Sitzung meiner ersten Sitzung. Das heißt, was werde ich hier tun? Ich gehe zu einer anderen Sitzung und fordere sie auf, „mir die Sperransicht für diese Anfrage anzuzeigen“. Und hier habe ich einen AccessShareLock für diese Tabelle. Das ist genau das, was ich angefordert habe. Und er sagt, die Sperre sei zugewiesen worden. Sehr einfach.
Wenn wir uns außerdem die zweite Spalte ansehen, ist dort nichts zu finden. Sie sind leer.
Und wenn ich den Befehl „SELECT“ ausführe, ist dies die implizite (explizite) Möglichkeit, AccessShareLock anzufordern. Also gebe ich meine Tabelle frei und führe eine Abfrage aus, und die Abfrage gibt mehrere Zeilen zurück. Und in einer der Zeilen sehen wir AccessShareLock. Daher ruft SELECT AccessShareLock für die Tabelle auf. Und es kollidiert mit fast nichts, da es sich um eine Sperre auf niedriger Ebene handelt.
Was passiert, wenn ich ein SELECT ausführe und drei verschiedene Tabellen habe? Früher habe ich nur eine Tabelle ausgeführt, jetzt verwende ich drei: pg_class, pg_namespace und pg_attribute.
Und wenn ich mir jetzt die Abfrage ansehe, sehe ich 9 AccessShareLocks in XNUMX Tabellen. Warum? Drei Tabellen sind blau hervorgehoben: pg_attribute, pg_class, pg_namespace. Sie können aber auch sehen, dass alle Indizes, die über diese Tabellen definiert werden, auch über AccessShareLock verfügen.
Und das ist eine Blockade, die praktisch nicht mit anderen in Konflikt steht. Und alles, was es bewirkt, ist, uns davon abzuhalten, die Tabelle fallen zu lassen, während wir sie auswählen. Es ergibt Sinn. Das heißt, wenn wir eine Tabelle auswählen und diese in diesem Moment verschwindet, dann ist das falsch AccessShare ist eine Sperre auf niedriger Ebene, die uns sagt: „Diese Tabelle nicht löschen, während ich arbeite.“. Im Grunde ist das alles, was sie tut.
ROW SHARE – Diese Sperre ist etwas anders.
Nehmen wir ein Beispiel. Mit der Option SELECT ROW SHARE können Sie jede Zeile einzeln sperren. Auf diese Weise kann niemand sie löschen oder ändern, während wir sie ansehen.
Was macht SHARE LOCK? Wir sehen, dass die Transaktions-ID für SELECT 681 ist. Und es ist interessant. Was ist hier passiert? Zum ersten Mal sehen wir die Nummer im Feld „Sperre“. Wir nehmen die Transaktions-ID und er sagt, dass er sie im exklusiven Modus blockiert. Es wird lediglich angezeigt, dass irgendwo in der Tabelle eine Zeile technisch gesperrt ist. Wo genau, sagt er aber nicht. Wir werden uns das etwas später genauer ansehen.
Hier sagen wir, dass das Schloss von uns genutzt wird.
Eine exklusive Sperre besagt also ausdrücklich (explizit), dass sie exklusiv ist. Und wie Sie sehen, passiert das auch, wenn Sie eine Zeile in dieser Tabelle löschen.
SHARE EXKLUSIV ist eine längere Sperre.
Dies ist (ANALYZE) der zu verwendende Analysebefehl.
SHARE LOCK – Sie können den Share-Modus explizit sperren.
Sie können auch einen eindeutigen Index erstellen. Und dort können Sie SHARE LOCK sehen, das Teil davon ist. Und es sperrt die Tabelle und setzt eine SHARE LOCK-Sperre darauf.
Die standardmäßige SHARE LOCK für eine Tabelle bedeutet, dass andere Personen die Tabelle lesen können, aber niemand sie ändern kann. Und genau das passiert, wenn Sie einen eindeutigen Index erstellen.
Wenn ich einen eindeutigen gleichzeitigen Index erstelle, habe ich eine andere Art von Sperre, denn denken Sie daran, dass die Verwendung gleichzeitiger Indizes den Sperrbedarf reduziert. Und wenn ich eine normale Sperre verwende, einen normalen Index, dann verhindere ich damit, dass beim Erstellen auf den Index der Tabelle geschrieben wird. Wenn ich einen gleichzeitigen Index verwende, muss ich einen anderen Sperrtyp verwenden.
SHARE ROW EXCLUSIVE – auch hier kann es explizit (explizit) festgelegt werden.
Oder wir können eine Regel erstellen, also einen bestimmten Fall annehmen, in dem sie verwendet wird.
EXKLUSIVE Sperre bedeutet, dass niemand sonst die Tabelle ändern kann.
Hier sehen wir verschiedene Arten von Schlössern.
ACCESS EXCLUSIVE ist beispielsweise ein Sperrbefehl. Zum Beispiel, wenn Sie es tun CLUSTER table, dann bedeutet das, dass dort niemand mehr schreiben kann. Und es sperrt nicht nur die Tabelle selbst, sondern auch die Indizes.
Dies ist die zweite Seite der ACCESS EXCLUSIVE-Sperre, auf der wir in der Tabelle genau sehen, was sie sperrt. Es sperrt einzelne Tabellenzeilen, was interessant genug ist.
Das sind alle grundlegenden Informationen, die ich geben wollte. Wir haben über Sperren gesprochen, über Transaktions-IDs, wir haben über virtuelle Transaktions-IDs gesprochen, über permanente Transaktions-IDs.
Und jetzt gehen wir die Blockierungsbeispiele durch. Das ist der interessanteste Teil. Wir werden sehr interessante Fälle sehen. Und mein Ziel in dieser Präsentation ist es, Ihnen eine bessere Vorstellung davon zu vermitteln, was Postgres tatsächlich tut, wenn es versucht, Dinge zu blockieren. Es scheint mir, dass er sehr gut darin ist, einzelne Teile zu blockieren.
Schauen wir uns einige konkrete Beispiele an.
Wir beginnen mit Tabellen und einer Zeile pro Tabelle. Wenn ich etwas einfüge, erhalte ich ExclusiveLock, Transaction ID und ExclusiveLock auf dem Tisch.
Was passiert, wenn ich zwei weitere Zeilen einfüge? Und jetzt hat unsere Tabelle drei Zeilen. Und ich habe eine Zeile eingefügt und diese als Ausgabe erhalten. Und wenn ich zwei weitere Zeilen einfüge, was ist hier seltsam? Hier gibt es eine Kuriosität, da ich dieser Tabelle drei Zeilen hinzugefügt habe, in der Sperrtabelle aber immer noch zwei Zeilen vorhanden sind. Und das ist tatsächlich das grundlegende Verhalten von Postgres.
Viele Leute denken, wenn Sie in einer Datenbank 100 Zeilen sperren, müssen Sie 100 Sperreinträge erstellen. Wenn ich 1 Zeilen auf einmal blockiere, benötige ich 000 solcher Anfragen. Und wenn ich eine Million oder eine Milliarde zum Blockieren brauche. Aber wenn wir das tun, wird es nicht sehr gut funktionieren. Wenn Sie ein System verwendet haben, das Sperreinträge für jede einzelne Zeile erstellt, sehen Sie, dass dies kompliziert ist. Weil Sie die Sperrtabelle sofort definieren müssen, was zu einem Überlauf führen kann, aber Postgres macht das nicht.
Und es ist sehr wichtig, dass diese Folie deutlich zeigt, dass es innerhalb von MVCC ein anderes System gibt, das einzelne Zeilen blockiert. Wenn Sie also Milliarden von Zeilen sperren, erstellt Postgres nicht eine Milliarde separate Sperranweisungen. Und das ist sehr gut für die Leistung.
Wie wäre es mit einem Update? Ich aktualisiere die Serie jetzt und Sie können sehen, dass zwei verschiedene Vorgänge gleichzeitig ausgeführt wurden. Gleichzeitig wurde die Tabelle gesperrt, aber auch der Index. Und er musste den Index sperren, weil es eindeutige Einschränkungen für diese Tabelle gibt. Und wir wollen sicherstellen, dass niemand es ändert, also blockieren wir es.
Was passiert, wenn ich zwei Zeilen aktualisieren möchte? Und wir sehen, dass er sich genauso verhält. Wir machen doppelt so viele Updates, aber genau die gleiche Anzahl an Sperrleitungen.
Wenn Sie sich fragen, wie Postgres das macht, sollten Sie sich meine Vorträge zu MVCC anhören, um herauszufinden, wie Postgres diese Zeilen intern markiert, die es ändert. Und Postgres hat eine Möglichkeit, dies zu tun, aber es tut es nicht auf der Ebene der Tabellensperre, sondern auf einer niedrigeren und effizienteren Ebene.
Was ist, wenn ich etwas löschen möchte? Wenn ich beispielsweise eine Zeile lösche und ich immer noch meine beiden Eingaben am Schloss habe, und selbst wenn ich sie alle löschen möchte, sind sie immer noch da.
Und ich möchte zum Beispiel 1 Zeilen einfügen und dann entweder 000 Zeilen löschen oder hinzufügen, dann werden die einzelnen Zeilen, die ich hinzufüge oder ändere, hier nicht aufgezeichnet. Sie werden auf einer niedrigeren Ebene innerhalb der Zeile selbst geschrieben. Und während des MVCC-Vortrags habe ich ausführlich darüber gesprochen. Beim Analysieren von Sperren ist es jedoch sehr wichtig, sicherzustellen, dass Sie über eine Sperre auf Tabellenebene verfügen und nicht sehen können, wie einzelne Zeilen hier geschrieben werden.
Was ist mit explizitem Blockieren?
Wenn ich auf „Aktualisieren“ klicke, sind zwei Zeilen gesperrt. Und wenn ich sie alle auswähle und auf „Überall aktualisieren“ klicke, dann habe ich immer noch zwei Sperrdatensätze.
Wir erstellen keine separaten Einträge für jede einzelne Zeile. Weil dann die Leistung sinkt, kann es sein, dass zu viel davon vorhanden ist. Und wir könnten uns in einer unangenehmen Situation befinden.
Und das Gleiche gilt: Wenn wir es teilen, können wir alles 30 Mal machen.
Wir stellen unsere Tabelle wieder her, löschen alles und fügen dann erneut eine Zeile ein.
Eine andere Art von Verhalten, das Sie in Postgres sehen und das sehr bekannt und erwünscht ist, besteht darin, dass Sie ein Update oder eine Auswahl durchführen können. Und Sie können es gleichzeitig tun. Und Select blockiert keine Aktualisierung und das Gleiche auch in die entgegengesetzte Richtung. Wir weisen den Leser an, den Autor nicht zu blockieren, und der Autor hat den Leser nicht blockiert.
Ich zeige Ihnen ein Beispiel dafür. Ich werde jetzt eine Wahl treffen. Wir werden dann einen INSERT durchführen. Und dann sehen Sie - 694. Sie können die ID der Transaktion sehen, die diese Einfügung vorgenommen hat. Und so funktioniert es.
Und wenn ich jetzt auf meine Backend-ID schaue, ist sie - 695.
Und ich kann sehen, dass 695 in meiner Tabelle erscheint.
Und wenn ich hier so aktualisiere, dann erhalte ich einen anderen Fall. In diesem Fall ist 695 eine exklusive Sperre und update verhält sich gleich, es besteht jedoch kein Konflikt zwischen ihnen, was ziemlich ungewöhnlich ist.
Und Sie können sehen, dass oben ShareLock und unten ExclusiveLock ist. Und beide Transaktionen waren erfolgreich.
Und Sie müssen sich meinen Vortrag bei MVCC anhören, um zu verstehen, wie das passiert. Dies ist jedoch ein Beispiel dafür, dass Sie dies gleichzeitig tun können, d. h. gleichzeitig SELECT und UPDATE ausführen.
Lassen Sie uns zurücksetzen und einen Vorgang erneut ausführen.
Wenn Sie versuchen, zwei Updates gleichzeitig in derselben Zeile auszuführen, wird dies blockiert. Und denken Sie daran, ich habe gesagt, dass nicht der Leser den Autor blockiert, sondern der Autor des Lesers, aber ein Autor blockiert einen anderen. Das heißt, wir können nicht zulassen, dass zwei Personen gleichzeitig dieselbe Zeile aktualisieren. Sie müssen warten, bis einer von ihnen fertig ist.
Und um dies zu veranschaulichen, schaue ich mir die Lockdemo-Tabelle an. Und wir schauen uns eine Zeile an. Für Transaktion 698.
Wir haben es auf 2 aktualisiert. 699 ist das erste Update. Und es war erfolgreich oder es befindet sich in einer ausstehenden Transaktion, die darauf wartet, dass wir sie festschreiben oder stornieren.
Aber schauen Sie sich etwas anderes an: 2/51 ist unsere erste Transaktion, unsere erste Sitzung. 3/112 ist die zweite Anfrage, die von oben kam und diesen Wert auf 3 änderte. Und wie Sie bemerken, hat sich die oberste Anfrage selbst gesperrt, nämlich 699. Aber 3/112 hat keine Sperre gewährt. In der Spalte Lock_mode steht, dass es wartet. Er erwartet 699. Und wenn man sich die 699 anschaut, ist er höher. Und was hat die erste Sitzung bewirkt? Sie hat eine exklusive Sperre für ihre eigene Transaktions-ID erstellt. So macht es Postgres. Es blockiert seine eigene Transaktions-ID. Und wenn Sie darauf warten möchten, dass jemand eine Zusage oder einen Abbruch vornimmt, müssen Sie warten, während eine Transaktion aussteht. Und so können wir eine seltsame Linie sehen.
Schauen wir noch einmal. Links sehen wir unsere Verarbeitungs-ID. In der zweiten Spalte sehen wir unsere virtuelle Transaktions-ID und in der dritten sehen wir den lock_type. Was bedeutet das? Tatsächlich sagt sie, dass sie die Transaktions-ID blockiert. Beachten Sie jedoch, dass in allen Zeilen unten die Beziehung angegeben ist. Sie haben also zwei Arten von Schlössern auf dem Tisch. Es gibt eine Beziehungssperre. Und es gibt auch eine Transaktions-ID-Sperre, die wir selbst sperren. Genau das passiert in der ersten Zeile oder ganz unten, wo sich die Transaktions-ID befindet, wo wir erwarten, dass 699 ihren Vorgang beendet.
Ich sehe, was hier passiert. Und hier passieren zwei Dinge gleichzeitig. Sie sehen die Transaktions-ID-Sperre in der ersten Zeile, die sich selbst sperrt. Und sie blockiert sich selbst, um die Leute warten zu lassen.
Wenn Sie sich die 6. Zeile ansehen, handelt es sich um denselben Eintrag wie in der ersten. Daher wird die Transaktion 699 blockiert. 700 ist außerdem selbsthemmend. Und dann sehen Sie in der unteren Reihe, dass wir darauf warten, dass 699 seinen Vorgang abschließt.
Und in lock_type, tuple sehen Sie Zahlen.
Sie können sehen, dass es 0/10 ist. Und das ist die Seitenzahl und auch der Versatz dieser bestimmten Zeile.
Und Sie sehen, was bei der Aktualisierung zu 0/11 wird.
Tatsächlich ist es jedoch 0/10, da für diesen Vorgang eine Erwartung besteht. Wir haben die Gelegenheit zu sehen, dass dies der Streit ist, auf dessen Bestätigung ich warte.
Sobald wir es bestätigt und auf „Commit“ geklickt haben und das Update abgeschlossen ist, erhalten wir erneut Folgendes. Transaktion 700 ist die einzige Sperre, sie wartet nicht auf andere, da sie festgeschrieben wurde. Es wartet lediglich darauf, dass die Transaktion abgeschlossen ist. Sobald 699 endet, warten wir auf nichts anderes mehr. Und jetzt sagt Transaktion 700, dass alles in Ordnung ist, dass alle erforderlichen Sperren in allen zulässigen Tabellen vorhanden sind.
Und um das Ganze noch komplizierter zu machen, erstellen wir eine weitere Ansicht, die uns dieses Mal eine Hierarchie bietet. Ich erwarte nicht, dass Sie diese Bitte verstehen. Aber es wird uns eine klarere Sicht auf das geben, was vor sich geht.
Dies ist eine rekursive Ansicht, die auch einen weiteren Abschnitt enthält. Und dann fügt es alles wieder zusammen. Nutzen wir das.
Was wäre, wenn wir drei gleichzeitige Aktualisierungen durchführen und sagen, die Zeile ist jetzt drei? Und wir werden 3 zu 4 ändern.
Und hier sehen wir 4. Und Transaktions-ID 702.
Und dann tausche ich 4 gegen 5. Und 5 gegen 6 und 6 gegen 7. Und ich stelle eine Reihe von Leuten auf, die darauf warten, dass diese eine Transaktion abgeschlossen ist.
Und alles wird klar. Was ist die erste Reihe? Dies ist 702. Dies ist die Transaktions-ID, die diesen Wert ursprünglich festgelegt hat. Was steht in der Spalte „Gewährt“? Ich habe Noten f. Dies sind meine Updates, die (5, 6, 7) nicht genehmigt werden können, da wir auf den Ablauf der Transaktions-ID 702 warten. Dort haben wir eine Transaktions-ID-Sperre. Und es stellt sich heraus, dass es 5 Transaktionssperren gibt.
Und wenn Sie sich 704, 705 ansehen, steht dort noch nichts geschrieben, weil sie noch nicht wissen, was los ist. Sie schreiben nur, dass sie keine Ahnung haben, was los ist. Und sie schlafen einfach ein, weil sie darauf warten, dass jemand fertig wird, und werden geweckt, wenn es möglich ist, die Reihe zu wechseln.
So sieht es aus. Es ist klar, dass sie alle auf die 12. Zeile warten.
Das haben wir hier gesehen. Hier ist 0/12.
Sobald also die erste Transaktion genehmigt wurde, können Sie hier sehen, wie die Hierarchie funktioniert. Und jetzt ist alles klar. Sie werden alle sauber. Und sie warten tatsächlich immer noch.
Hier ist, was passiert. 702 ist festgeschrieben. Und jetzt erhält 703 diese Zeilensperre, und dann beginnt 704, darauf zu warten, dass 703 festschreibt. Und auch darauf wartet die 705. Und wenn das alles erledigt ist, räumen sie sich auf. Und ich möchte darauf hinweisen, dass alle Schlange stehen. Und es ist ganz ähnlich wie im Stau, wo alle auf das erste Auto warten. Das erste Auto hat angehalten und alle stellen sich in einer langen Schlange auf. Dann bewegt es sich, dann kann das nächste Auto nach vorne kommen und seinen Block bekommen und so weiter.
Und wenn es Ihnen nicht schwierig genug erschien, dann sprechen wir jetzt mit Ihnen über Deadlocks. Ich weiß nicht, wer von euch sie erlebt hat. Dies ist ein recht häufiges Problem in Datenbanksystemen. Aber Deadlocks entstehen, wenn eine Sitzung darauf wartet, dass eine andere Sitzung etwas tut. Und in diesem Moment wartet eine weitere Sitzung darauf, dass die erste Sitzung etwas bewirkt.
Und zum Beispiel, wenn Ivan sagt: „Gib mir etwas“, und ich sage: „Nein, ich gebe es dir nur, wenn du mir etwas anderes gibst.“ Und er sagt: „Nein, ich gebe es dir nicht, wenn du es mir nicht gibst.“ Und wir geraten in eine Sackgasse. Ich bin mir sicher, dass Ivan das nicht tun wird, aber Sie verstehen, dass wir zwei Leute haben, die etwas wollen und nicht bereit sind, es wegzugeben, bis die andere Person ihnen gibt, was sie wollen. Und es gibt keine Lösung.
Und tatsächlich muss Ihre Datenbank dies erkennen. Und dann müssen Sie eine der Sitzungen löschen oder schließen, da sie sonst für immer dort bleiben. Und wir sehen es in Datenbanken, wir sehen es in Betriebssystemen. Und überall dort, wo wir parallele Prozesse haben, kann das passieren.
Und wir werden jetzt zwei Deadlocks setzen. Wir geben 50 und 80 ein. In der ersten Zeile aktualisiere ich von 50 auf 50. Ich erhalte die Transaktionsnummer 710.
Und dann ändere ich 80 auf 81 und 50 auf 51.
Und so wird es aussehen. Daher verfügt 710 über eine Zeilensperre und 711 wartet auf eine Bestätigung. Wir haben es gesehen, als wir aktualisiert haben. 710 - ist der Besitzer unserer Serie. Und 711 wartet darauf, dass 710 die Transaktion abschließt.
Und es steht sogar, in welcher Zeile wir Deadlocks haben. Und hier fängt es an, seltsam zu werden.
Jetzt aktualisieren wir 80 auf 80.
Und hier beginnen die Blockaden. 710 wartet auf eine Antwort von 711, und 711 wartet auf 710. Und das wird nicht gut enden. Und es gibt keinen Ausweg. Und sie werden eine Antwort voneinander erwarten.
Und es fängt einfach an, alles zu verzögern. Und das wollen wir nicht.
Und Postgres hat Möglichkeiten, dies zu bemerken. Und wenn das passiert, erhalten Sie diese Fehlermeldung. Und daraus ist klar, dass dieser oder jener Prozess auf eine SHARE LOCK von einem anderen Prozess wartet, also vom 711-Prozess blockiert wird. Und dieser Prozess wartete darauf, dass dieser oder jener Transaktions-ID eine SHARE LOCK zugewiesen und von diesem und jenem Prozess blockiert wurde. Daher liegt eine Situation des Dead Blocking vor.
Gibt es Drei-Wege-Deadlocks? Ist das möglich? Ja.
Wir tragen diese Zahlen in die Tabelle ein. Wir ändern 40 auf 40, wir machen eine Sperre.
Ändern Sie 60 auf 61, 80 auf 81.
Und dann ändern wir 80 und dann boomt es!
Und 714 wartet jetzt auf 715. 716 wartet auf 715. Und es gibt nichts, was man dagegen tun kann.
Es sind nicht mehr zwei Personen, es sind bereits drei Personen. Ich möchte etwas von dir, dieser möchte etwas von der dritten Person und die dritte Person möchte etwas von mir. Und am Ende warten wir zu dritt, weil wir alle darauf warten, dass die andere Person erledigt, was sie tun muss.
Und Postgres weiß, in welcher Zeile es passiert. Daher erhalten Sie die folgende Meldung, die darauf hinweist, dass ein Problem vorliegt, bei dem sich die drei Eingänge gegenseitig blockieren. Und es gibt keine Einschränkungen. Dies kann der Fall sein, wenn sich 20 Einträge gegenseitig blockieren.
Die nächste Ausgabe ist serialisierbar.
Wenn eine spezielle serialisierbare Sperre.
Und wir kehren zu 719 zurück. Er hat ein völlig normales Problem.
Und Sie können die Transaktion serialisierbar machen.
Und Sie verstehen, dass Sie jetzt eine andere Art der SA-Blockierung haben – das heißt serialisierbar.
Deshalb haben wir eine neue Art von Schloss namens SARieadLock, ein Serienschloss, mit dem Sie Seriennummern eingeben können.
Außerdem können Sie eindeutige Indizes einfügen.
In dieser Tabelle haben wir eindeutige Indizes.
Wenn ich hier also die Zahl 2 eintrage, habe ich deshalb eine 2. Aber ganz oben trage ich noch eine 2 ein. Und man sieht, dass die 721 eine exklusive Sperre hat. Aber jetzt wartet 722 darauf, dass 721 seine Operation abschließt, weil es keine 2 einfügen kann, bis es weiß, was mit 721 passieren wird.
Und wenn wir Subtransaktionen durchführen.
Hier haben wir 723.
Und wenn wir den Punkt speichern und dann aktualisieren, erhalten wir eine neue Transaktions-ID. Dies ist ein weiteres Verhalten, dessen Sie sich bewusst sein müssen. Wenn wir das zurückgeben, ist die Transaktions-ID weg. 724 fährt ab. Aber jetzt haben wir 725.
Und was versuche ich hier zu tun? Ich versuche, Ihnen Beispiele für ungewöhnliche Sperren zu zeigen, die Sie finden können: Seien es serialisierbare Sperren oder SAVEPOINT-Sperren, das sind verschiedene Arten von Sperren, die in der Sperrtabelle erscheinen.
Dies ist die Erstellung expliziter (expliziter) Sperren mit pg_advisory_lock.
Und Sie können sehen, dass der Sperrtyp hier als Empfehlung aufgeführt ist. Und hier steht in Rot „Beratung“. Und Sie können gleichzeitig mit pg_advisory_unlock blockieren.
Und zum Schluss möchte ich Ihnen noch eine umwerfende Sache zeigen. Ich werde eine andere Ansicht erstellen. Aber ich werde die pg_locks-Tabelle mit der pg_stat_activity-Tabelle verknüpfen. Und warum möchte ich das tun? Weil es mir ermöglicht, alle aktuellen Sitzungen zu sehen und zu sehen, auf welche Art von Sperren sie warten. Und es ist schon interessant, wenn wir eine Sperrtabelle und eine Abfragetabelle zusammenstellen.
Und hier erstellen wir pg_stat_view.
Und wir aktualisieren die Zeile um eins. Und hier sehen wir 724. Und dann aktualisieren wir unsere Zeile auf drei. Und was siehst du jetzt hier? Dabei handelt es sich um Anfragen, d.h. Sie sehen die gesamte Liste der Anfragen, die in der linken Spalte aufgeführt sind. Und dann sehen Sie auf der rechten Seite Schlösser und was sie erzeugen. Und es kann für Sie verständlicher sein, sodass Sie nicht jedes Mal zu jeder Sitzung zurückkehren und prüfen müssen, ob Sie daran teilnehmen müssen oder nicht. Sie tun es für uns.
Eine weitere sehr nützliche Funktion ist pg_blocking_pids. Sie haben wahrscheinlich noch nie von ihr gehört. Was macht sie? Dadurch können wir für diese Sitzung 11740 erkennen, auf welche Prozess-IDs sie wartet. Und Sie können sehen, dass 11740 724 erwartet. Und 724 steht ganz oben. Und 11306 ist Ihre Prozess-ID. Im Wesentlichen geht diese Funktion über Ihre Sperrtabelle. Und ich weiß, es ist ein wenig kompliziert, aber Sie verstehen, worauf es ankommt. Im Wesentlichen durchsucht diese Funktion diese Sperrtabelle und versucht herauszufinden, wo sich diese Prozess-ID befindet, angesichts der Sperren, auf die sie wartet. Außerdem wird versucht herauszufinden, welche Prozess-ID der Prozess hat, der auf die Sperre wartet. Sie können diese Funktion also ausführen pg_blocking_pids.
Und das ist sehr nützlich. Wir haben dies erst seit Version 9.6 hinzugefügt, diese Funktion ist also erst 5 Jahre alt, aber sie ist sehr, sehr nützlich. Und das Gleiche gilt auch für die zweite Anfrage. Es zeigt genau das, was wir sehen müssen.
Darüber wollte ich mit Ihnen sprechen. Und wie ich erwartet hatte, haben wir unsere ganze Zeit in Anspruch genommen, weil es so viele Rutschen gab. Und die Folien stehen zum Download bereit. Ich möchte Ihnen dafür danken, dass Sie hier sind. Ich bin mir sicher, dass Sie den Rest der Konferenz genießen werden, vielen Dank!
Fragen:
Wenn ich beispielsweise versuche, die Zeilen zu aktualisieren, und die zweite Sitzung versucht, die gesamte Tabelle zu löschen. Soweit ich weiß, sollte es so etwas wie eine Intent-Sperre geben. Gibt es so etwas in Postgres?
Wir kehren zum Anfang zurück. Sie erinnern sich vielleicht daran, dass wir bei jeder Aktion, beispielsweise wenn Sie eine SELECT-Anweisung ausführen, einen AccessShareLock ausgeben. Und es verhindert, dass der Tisch herunterfällt. Wenn Sie also beispielsweise eine Zeile in einer Tabelle aktualisieren oder eine Zeile löschen möchten, kann nicht jemand gleichzeitig die gesamte Tabelle löschen, da Sie diesen AccessShareLock über die gesamte Tabelle und über die Zeile halten. Und sobald Sie fertig sind, können sie es entfernen. Aber solange man dort direkt etwas ändert, werden sie es nicht schaffen.
Lass uns das nochmal machen. Fahren wir mit dem Löschbeispiel fort. Und Sie sehen, dass die Zeile eine exklusive Sperre für die gesamte Tabelle hat.
Es wird wie ein exklusives Schloss aussehen, oder?
Ja, es sieht so aus. Ich verstehe, wovon Sie sprechen. Wollen Sie damit sagen, dass es zu einem Problem wird, wenn ich eine SELECT-Anweisung ausführe, dann eine ShareExclusive-Anweisung habe und diese dann in einen Row Exclusive-Status versetze? Aber überraschenderweise stellt dies kein Problem dar. Es ist, als würde man den Grad der Sperre erhöhen, aber im Wesentlichen habe ich eine Sperre, die verhindert, dass sie gelöscht wird. Und wenn ich diese Sperre jetzt leistungsfähiger mache, verhindert sie immer noch das Löschen. Es ist also nicht so, dass ich nach oben gehe. Das heißt, es hat es auch verhindert, als es auf einer niedrigeren Ebene war. Wenn ich es also anhebe, verhindert es immer noch, dass der Tisch herunterfällt.
Ich verstehe, wovon Sie sprechen. Es gibt keinen Fall der Erhöhung des Blockierungsgrades, bei dem Sie versuchen, einen Block aufzugeben, um einen stärkeren einzuführen. Hier wird die Vermeidung überall nur noch verstärkt, sodass kein Konflikt entsteht. Aber es ist eine gute Frage. Vielen Dank für Ihre Anfrage!
Was müssen wir tun, um eine Deadlock-Situation zu vermeiden, wenn wir viele Sitzungen und eine große Anzahl von Benutzern haben?
Postgres erkennt Deadlock-Situationen automatisch. Und eine der Sitzungen wird automatisch gelöscht. Die einzige Möglichkeit, eine Deadlock-Situation zu vermeiden, besteht darin, Personen in derselben Reihenfolge zu blockieren. Wenn Sie sich also Ihre Anwendung ansehen, ist dies häufig die Ursache für Deadlocks ... Nehmen wir an, ich möchte zwei verschiedene Dinge blockieren. Eine Anwendung sperrt Tabelle 1 und eine andere Anwendung sperrt Tabelle 2 und dann Tabelle 1. Und der einfachste Weg, Deadlocks zu vermeiden, besteht darin, sich Ihre Anwendung anzusehen und sicherzustellen, dass die Sperre in allen Anwendungen in der gleichen Reihenfolge erfolgt. Und das beseitigt in der Regel 80 % der Probleme, da diese Anwendungen von allen möglichen Menschen geschrieben werden. Und wenn Sie sie in der gleichen Reihenfolge blockieren, geraten Sie nicht in eine Deadlock-Situation.
Vielen Dank für Ihre Leistung! Sie haben von „Vakuum voll“ gesprochen, und wenn ich das richtig verstanden habe, verzerrt „Vakuum voll“ die Reihenfolge der Datensätze in einem separaten Speicher, sodass die aktuellen Datensätze unverändert bleiben. Warum benötigt „Vakuum voll“ exklusiven Sperrzugriff und warum kommt es zu Konflikten mit Schreibvorgängen?
Das ist eine gute Frage. Der Grund dafür ist, dass das Vakuum einen Tisch vollständig einnimmt. Und wir erstellen im Wesentlichen eine neue Version der Tabelle. Und der Tisch wird neu sein. Es stellt sich heraus, dass es sich um eine völlig neue Version der Tabelle handelt. Und das Problem ist, dass wir dabei nicht wollen, dass die Leute es lesen, weil wir wollen, dass sie die neue Tabelle sehen. Das passt also zur vorherigen Frage. Wenn wir gleichzeitig lesen könnten, wären wir nicht in der Lage, es zu verschieben und die Leute an einen neuen Tisch zu leiten. Wir müssten warten, bis alle diese Tabelle zu Ende gelesen haben, und so handelt es sich im Grunde genommen um eine Sperren-exklusive Situation.
Wir sagen nur, dass wir von Anfang an sperren, weil wir wissen, dass wir ganz am Ende eine exklusive Sperre benötigen, um alle auf die neue Kopie zu übertragen. Wir können es also möglicherweise lösen. Und so machen wir es mit der gleichzeitigen Indizierung. Aber das ist viel schwieriger zu bewerkstelligen. Und das gilt ganz besonders für Ihre vorherige Frage zu Lock Exclusive.
Ist es möglich, in Postgres ein Sperrzeitlimit hinzuzufügen? In Oracle kann ich zum Beispiel „zum Aktualisieren auswählen“ schreiben und 50 Sekunden warten, bevor ich die Aktualisierung durchführe. Für die Bewerbung war es gut. Aber in Postgres muss ich das entweder sofort tun und nicht warten, oder bis zu einer gewissen Zeit warten.
Ja, Sie können sich für eine Zeitüberschreitung Ihrer Sperren entscheiden. Sie können auch den Befehl „no way“ erteilen, der … wenn Sie die Sperre nicht sofort erhalten. Daher entweder Sperrzeitlimit oder etwas anderes, das Ihnen dies ermöglicht. Dies geschieht nicht auf syntaktischer Ebene. Dies erfolgt als Variable auf dem Server. Manchmal kann es nicht verwendet werden.
Können Sie Folie 75 öffnen?
Ja.
Und meine Frage ist die nächste. Warum warten beide Update-Prozesse auf 703?
Und das ist eine tolle Frage. Ich verstehe übrigens nicht, warum Postgres das tut. Aber als 703 erstellt wurde, wartete es auf 702. Und wenn 704 und 705 auftauchen, scheinen sie nicht zu wissen, worauf sie warten, weil dort noch nichts ist. Und Postgres macht es so: Wenn Sie keine Sperre erhalten, heißt es: „Was bringt es, Sie zu bearbeiten?“, Weil Sie bereits auf jemanden warten. Lassen Sie es also einfach in der Luft hängen, es aktualisiert es überhaupt nicht. Aber was ist hier passiert? Sobald 702 den Vorgang abgeschlossen hatte und 703 seine Sperre erhielt, kehrte das System zurück. Und sie sagte, dass wir jetzt zwei Leute haben, die warten. Und dann lassen Sie uns sie gemeinsam aktualisieren. Und weisen Sie darauf hin, dass beides erwartet wird.
Ich weiß nicht, warum Postgres das tut. Aber es gibt ein Problem namens f…. Es scheint mir, dass dies kein russischer Begriff ist. Dies ist der Fall, wenn jeder auf eine Burg wartet, auch wenn 20 Instanzen auf die Burg warten. Und plötzlich wachen sie alle gleichzeitig auf. Und jeder beginnt zu reagieren. Aber das System sorgt dafür, dass alle auf 703 warten. Weil sie alle warten, und wir werden sie sofort alle in eine Reihe stellen. Und wenn eine andere neue Anfrage erscheint, die danach erstellt wurde, zum Beispiel 707, dann wird es wieder eine Lücke geben.
Und es scheint mir, dass dies getan wird, um sagen zu können, dass 702 zu diesem Zeitpunkt auf 703 wartet und alle, die danach kommen, keinen Eintrag in diesem Feld haben werden. Aber sobald der erste Kellner geht, erhalten alle, die in diesem Moment vor dem Update gewartet haben, den gleichen Token. Und so scheint es mir, dass dies geschieht, damit wir es in der richtigen Reihenfolge verarbeiten können, damit sie richtig geordnet sind.
Ich habe es immer als ein ziemlich seltsames Phänomen angesehen. Denn hier sind sie zum Beispiel überhaupt nicht aufgeführt. Aber es scheint mir, jedes Mal, wenn wir ein neues Schloss vergeben, schauen wir auf alle, die gerade warten. Dann ordnen wir sie alle an. Und dann wird jede neue Person, die hereinkommt, erst dann in die Warteschlange gestellt, wenn die nächste Person mit der Bearbeitung fertig ist. Eine sehr gute Frage. Vielen Dank für Ihre Frage!
Es erscheint mir viel logischer, wenn 705 704 erwartet.
Das Problem hierbei ist jedoch folgendes. Technisch gesehen können Sie entweder das eine oder das andere aufwecken. Und so wecken wir den einen oder anderen. Doch was passiert im Betrieb des Systems? Sie können sehen, wie 703 ganz oben seine eigene Transaktions-ID blockiert hat. So funktioniert Postgres. Und 703 wird durch seine eigene Transaktions-ID blockiert. Wenn also jemand warten möchte, wartet er auf 703. Und tatsächlich wird 703 abgeschlossen. Und erst nach seinem Abschluss wacht einer der Prozesse auf. Und wir wissen nicht, was für ein Prozess es sein wird. Dann verarbeiten wir nach und nach alles. Es ist jedoch nicht klar, welcher Prozess zuerst aufwacht, da es sich um einen dieser Prozesse handeln könnte. Im Grunde hatten wir einen Planer, der besagte, dass wir jetzt jeden dieser Prozesse aktivieren könnten. Wir wählen einfach zufällig eine aus. Deshalb sollten beide beachtet werden, denn wir können jeden von ihnen erwecken.
Und das Problem ist, dass wir CP-unendlich haben. Und deshalb ist es sehr wahrscheinlich, dass wir später aufwachen können. Und wenn wir zum Beispiel später aufwachen, dann warten wir auf denjenigen, der gerade die Sperre erhalten hat, wir bestimmen also nicht, wer genau zuerst geweckt wird. Wir schaffen eine solche Situation und das System weckt sie nach dem Zufallsprinzip.
Es gibt . Schauen Sie, sie sind auch interessant und nützlich. Das Thema ist natürlich furchtbar komplex. Vielen Dank, Bruce!
Source: habr.com