PostgreSQL in der Praxis
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 95 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/32310 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FrOSCon 201737 / 95
4
8
9
15
20
22
23
24
25
27
29
32
36
37
38
39
40
45
46
47
48
49
50
51
53
54
59
63
64
65
74
75
76
79
83
84
86
87
88
89
91
92
93
94
95
00:00
PostgreSQLHTTPHTMLHigh availabilityACCESS <Programm>Software repositoryCoin <Programmiersprache>PostgreSQLWikiSound <Multimedia>TOMScalabilityHigh availabilityXMLUMLLecture/ConferenceComputer animation
00:56
PostgreSQLHigh availabilityACCESS <Programm>Software repositoryDatabasePatch (Unix)Standard deviationVideoportalObject (grammar)Data typeScalabilityDatabaseOpen sourceGreat circleForceOperator (mathematics)PostgreSQLMySQLErweiterbarkeitMilitary operationComputer animation
03:31
Version <Informatik>EmailMittelungsverfahrenDirection (geometry)Lecture/Conference
04:31
DatabasePostgreSQLPatch (Unix)Windows AzureMicrosoftPoint cloudSQLGoogleSoliDZugriffDatabaseInternetdienstWindows RegistryDevice driverParallel programming modelConfiguration spaceHash functionSSLStatisticsComputer programmingPostgreSQLComplete metric spaceParallel programming modelTable (information)ZugriffBeta functionField extensionVersion <Informatik>Physical quantityDatabaseDevice driverFacebookTwitterMicrosoftDatabase transactionCodePatch (Unix)Open sourceSoliDData centerServer (computing)ErweiterbarkeitLinear regressionGraph minorStack (abstract data type)Software bugProduct (category theory)Sound effectMittelungsverfahrenPoint cloudBus (computing)Series (mathematics)Plane (geometry)Enterprise architectureProzedurDatabaseProgramming languageSource codeData typeQuery languageZeitraumWave packetWeb pageParallelenComputer animation
13:40
PostgreSQLParallel programming modelConfiguration spaceHash functionSSLStatisticsDatabaseInstanz <Informatik>Streaming mediaDatabase transactionData dictionaryMultiplicationVersion <Informatik>Database transactionInterface (chemistry)Hard disk driveSource codeClient (computing)IndexSound effectState of matterDatabaseVirtual memoryAuthenticationLevel (video gaming)MassLoginPasswordConfiguration spaceCommunications protocolTable (information)Bus (computing)Computer fileConstraint (mathematics)Noten <Programm>Set (mathematics)UpdateFunction (mathematics)Public key certificateCloningProgrammer (hardware)Query languageData dictionaryHigh availabilityPostgreSQLSystem administratorServer (computing)Cache (computing)Crash (computing)Instanz <Informatik>Computer animationDiagramProgram flowchart
22:48
Beat (acoustics)Computer fileComputer animation
23:52
PostgreSQLStreaming mediaPerturbation theoryServer (computing)Configuration spaceTape driveSlide ruleDefault (computer science)Data dictionaryData recoveryContinuous trackVersion <Informatik>State of matterMobile appComputer animation
26:25
PostgreSQLStreaming mediaClient (computing)Database transactionNoten <Programm>Lecture/ConferenceComputer animation
28:29
DatabasePostgreSQLField extensionBenchmarkBlogMobile appOverhead (computing)PostgreSQLConstraint (mathematics)Function (mathematics)User interfaceBlock (periodic table)Client (computing)Division (mathematics)BenchmarkDatabaseStreaming mediaTable (information)CalculationVersion <Informatik>WORKS SuiteUpdateRoute of administrationDurchschnitt <Mengenlehre>Sound effectBus (computing)Database transactionField extensionCodeBeam (structure)Computer animation
32:49
Computer filePostgreSQLDatabaseHigh availabilityVersion <Informatik>Constraint (mathematics)DatabaseTable (information)RhytidectomySet (mathematics)Server (computing)Database transactionUpdateForestMobile appRaw image formatMassComputer animation
37:55
Group actionDatabase transactionField extensionFunction (mathematics)Table (information)High availabilityNumberData recoveryVersion <Informatik>LogarithmLecture/Conference
41:20
Computer hardwareSoftwareBefehlsprozessorPostgreSQLOperating systemConfiguration spaceHigh availabilityAgent <Informatik>Data dictionaryData recoveryScaling (geometry)LogarithmClient (computing)Concurrency (computer science)Field extensionDatabase transactionConfiguration spaceHigh availabilityOperating systemTable (information)PostgreSQLMainframe computerServer (computing)Core dumpProduct (category theory)CalculationDatabaseProcess (computing)Version <Informatik>PROBE <Programm>Proxy serverHigh availabilityWorkstation <Musikinstrument>Canadian Mathematical SocietyBus (computing)Point cloudSound effectComputer animation
47:10
Data recoveryClient (computing)PostgreSQLORACLSLecture/ConferenceMeeting/Interview
48:27
High availabilityAgent <Informatik>Data dictionaryData recoveryCodeDevice driverData recoveryDatabasePostgreSQLLocal ringData dictionaryAgent <Informatik>Inequality (mathematics)Computer animation
51:01
Data recoveryTerm (mathematics)Stack (abstract data type)Version <Informatik>Structural loadPartition (number theory)Uniformer RaumLecture/ConferenceComputer animation
51:47
Structural loadPartition (number theory)Version <Informatik>Beat (acoustics)Social classNoten <Programm>Computer animation
52:37
Structural loadStack (abstract data type)Partition (number theory)Computer fileSummation9 (number)Mach's principleVersion <Informatik>BIOSUbuntu <Programm>Data storage deviceUSB <Schnittstelle>Database transactionAmerican Physical SocietyFamily of setsState of matterMoment (mathematics)Computer data loggingComputer animation
54:41
PostgreSQLHigh availabilityClient (computing)Computer animationLecture/Conference
55:51
Structural loadPartition (number theory)Version <Informatik>High availabilityPostgreSQLData modelAgent <Informatik>Streaming mediaUbuntu <Programm>Switch <Kommunikationstechnik>DatabaseCodePositionDatabase transactionoutputLocal ringUbuntu <Programm>PostgreSQLAbstract machineSlide ruleDatabaseStructural loadInformationComputer animation
58:29
FlagSoftware testingLecture/Conference
59:59
High availabilityComputing platformDatabaseStreaming mediaAgent <Informatik>PostgreSQLUbuntu <Programm>Structural loadStack (abstract data type)Partition (number theory)Computer fileAlgorithmPositionConfiguration spaceService (economics)HTTPMusical ensembleAPISocial classPostgreSQLComputer animation
01:01:32
Configuration spaceWorld Wide WebLecture/ConferenceComputer animation
Transcript: German(auto-generated)
00:07
Willkommen, auch von mir, zur Nachmittags-Session. Ich bin Michael Bank von Credative. Wir machen viel mit Postgres, aber auch sonst allen möglichen anderen Open Source-Sachen. Postgres deswegen, weil unser Geschäftsführer Michael Meskis ist einer der ältesten Postgres-Gemütter.
00:28
Das ist hier aus dem Postgres-Wiki. Bruce war der erste, Tom der zweite, Michael Meskis der dritte, der jetzt noch aktiv ist. Und ich glaube, Michael hat auch letzte Woche einen Commit gemacht. Er ist nicht mehr sehr aktiv im Vergleich zu den anderen beiden, aber er ist aktiv.
00:43
Und deswegen ist Postgres eines der großen Säulen unserer Firma. Ich habe den Vortrag schon mal ähnlich beim frühen Fachgespräch der German Unix User Group gehalten. Damals noch mit dem Titel Replikation, Hochverfügbarkeit und Skalierbarkeit.
01:01
Ich habe jetzt Skalierbarkeit rausgenommen, weil es damals schon ein bisschen eng wurde mit der Zeit. Aber wenn wir noch an der Zeit haben und nicht genug Fragen sind, kann ich dazu auch noch ein paar Folien dann zeigen. Wer kennt Postgres und benutzt Postgres von hier? Wer kennt es, aber benutzt es nicht, weil andere Daten machen sie nicht.
01:23
Ich würde einen kurzen Einblick oder Überblick in Postgres geben, was jetzt gerade so aktuell ist, weil das vielleicht jetzt noch nicht so bekannt ist. Es gab ja gestern auch einen Vortrag von Susanne Holzgräfe über die Unterschiede zwischen MariaDB, MySQL und Postgres. Aber das ist jetzt hier für Postgres spezifisch ein paar Sachen.
01:45
Generell erweiterbares Objekt, relationales Datenbanksystem, erweiterbar. In dem Fall heißt, der Benutzer ist generell selbst in der Lage, beliebige Objekte, Datentypen, aber auch Operatoren und wie die Operatoren miteinander wirken in Postgres selber zu implementieren und kann dadurch dann sehr starke Operationen machen.
02:09
Es ist entstanden als Forschungsprojekt, wurde in Mitte der 90er als Open Source dann freigegeben. Ursprünglich hieß es einfach Postgres als Nachfolger von Ingress und wurde dann als Postgres 95.95 freigegeben.
02:24
Und dann, als sie die SQL-Sprache hinzugefügt haben, früher war das nur QL, haben sie es nach Postgres QL umbenannt. Im Nachhinein ist der Name ein bisschen ungünstig. Man darf auch Postgres sagen, aber bitte nicht Postgre. Das ist falsch. Aber hört man relativ oft im deutschsprachigen Raum.
02:43
Es ist generell herstellerunabhängig. Das ist jetzt vielleicht mal so immer noch als Vergleich zu anderen beliebten Open Source-Datenbanken, die halt von einer Firma dominiert sind, aber Postgres ist herstellerunabhängig. Das heißt, es gibt keine Firma, die A, irgendwelche Copyrights hat oder B, alle Entwickler anstellt.
03:04
Man muss auch dazu sagen, dass die alle mehr oder weniger aktiven Postgres-Committer sind bei einer Firma, die irgendwie was mit Postgres machen, aber die Unterschiede ändern sich halt immer mit der Zeit. Mal hat eine Firma ein paar mehr, mal eine andere, dann gibt es mal eine neue. Aber es ist nicht so, dass seit zehn Jahren eine Firma 90 Prozent aller Postgres-Entwickler beschäftigt.
03:24
Insofern gibt es auch den kommerziellen Support von vielen Firmen, unter anderem eben auch von uns im deutschsprachigen Raum. Die sogenannte Legal Entity, die aber nicht wirklich irgendwie als Firma meines Wissens oder auch noch nicht mal als Non-Profit existiert, ist die Postgres Global Development Group.
03:41
Der gehört das Copyright. Ich will jetzt da nicht drüber näher eingehen. Das ist auch nicht wirklich sehr spezifisch, aber der Punkt, das gehört keiner Firma. Es gibt ein fünfköpfiges Core-Team, das projektrichtungsweise eine Entscheidung trifft. Wie zum Beispiel letztens hat es entschieden, es soll jetzt ein Release-Team geben. Das ist dreiköpfig. Das ist sehr hilfreich, weil es in der Vergangenheit dieses Debian-Problem gab.
04:07
Wir freezen zeitbasiert, aber wir releasen when it's ready und jeder hat dann schon für die nächste Version programmiert und dann hat sich das immer weiter hinausgezögert und jetzt dieses dreiköpfige Release-Team hat da wirklich die Hand drauf, dass die Open Items abgearbeitet werden und schreibt den Leuten zweimal die Woche eine E-Mail.
04:21
Wie schaut es denn aus? Und das funktioniert jetzt ganz gut. Die letzten zwei Releases waren dann wieder on time und das nächste Release wird auch vermutlich demnächst on time rauskommen. Generell war es so, dass die Major Releases immer jährlich rauskommen. Wir haben einen Beta oder einen Freeze der Features im Frühjahr und stabilisieren das dann über eine Beta-Phase, die momentan läuft.
04:46
Es kam letzte Woche die Beta 3 raus, bis dann im allgemeinen September, Oktober die final general availability erfolgt. Das waren bis jetzt die neuen Serien, 91, 92, 93, 94, 95, 96 waren die Major Releases.
05:01
Die nächste Version wird 10 sein. Postgres hat dann diese zwei Punktversionen gedroppt. Das wird jetzt 10 sein. Danach in einem Jahr gibt es dann 11 und 12 und so weiter. Einfach deswegen, weil nie so genau klar war, was ist jetzt der Unterschied zwischen 95 auf 96 oder von 95 auf 10. Da gab es jedes Jahr Diskussionen. Jetzt haben wir gesagt, okay, das ist jetzt 10.
05:20
Es gibt schon recht viele Features, die werde ich auch gleich vorstellen, aber es gibt keinen wirklichen Grund, dass jetzt die Kompatibilität unglaublich entfernt wurde. Das jetzt 10 heißt, es wurde einfach aus sinnvollen Gründen gemacht. 5 Jahre Wartungszeitraum, das hatte Susanne auch schon gestern gesagt, pro Release. Die Postgres Entwickler sind sehr gut daran, hier nur Bugs und Sicherheitsprobleme zu fixen.
05:44
Die machen das auch sehr zuverlässig. Es gibt dann jede drei Monate, das war gestern nicht so ganz klar, glaube ich. Es ist jetzt inzwischen so, es gibt auch eine Webseite, es gibt alle drei Monate Firma im Jahr an einem Donnerstag. Das war wie gesagt, nicht jetzt am Donnerstag, sondern am Donnerstag davor.
06:02
Der Fall gibt es dann einen Patch Release von allen Backbranches, was jetzt momentan die letzten fünf Jahre an Major Releases released wurden. Da kann man dann die Urnacht darstellen. Das hat in den letzten Jahren gut funktioniert. Und man weiß, dass sie rauskommen. Außerdem gibt es wirklich gravierende Sicherheitsprobleme, denke ich. Oder gravierende Regressions in einem Minor Release, aber das ist in den letzten zwei Jahren jetzt nicht vorgekommen.
06:25
Oder in den letzten Jahren, glaube ich mal, seitdem sie das gemacht haben. Insofern ist das schon für ein Open Source Projekt relativ stabil und relativ überschaubar. Und man kann relativ gut die Urne nachstellen, dass das so funktioniert. Ansonsten wichtig eben auch keine Copyright Assignments, kein Open Core, BSD-Lizenz.
06:43
Damit BSD bedeutet eben auch, dass jeder das forken kann und jeder das forken soll oder will. Das kommt ja aus Berkeley. Wobei die Lizenz ironischerweise eher die MIT-Lizenz ist, wenn man sich das genau anschaut. Aber im Endeffekt genau das Gleiche.
07:00
Jeder kann den Code nehmen und machen damit, was er will. Da muss nur das Copyright dafür nicht rausnehmen. Damit, wie gesagt, gibt es viele Forks. Ich habe jetzt mal hier ein paar zusammengefasst. Das sind eher so, Amazon hat Postgres genommen und Redshift draus gemacht. Man weiß nicht so genau, was das genau ist.
07:21
Vielleicht ist es sogar gar nicht Postgres, sondern man spricht nur das Protokoll. Das ist unklar. Es gibt dann so ein paar Teradata-Aster. Die Tetsa sind noch von Michael Stormbreaker, dem ursprünglichen Professor in Berkeley, dann gemachte Abänderungen. Da weiß man jetzt auch nicht so genau, weil die halt proprietär sind, wie viel Code da jetzt wirklich noch von Postgres drin ist. Greenplum hat irgendwann vor 15 Jahren Postgres geforkt.
07:43
Die haben es inzwischen Open Source gemacht und sie versuchen jetzt verzweifelt, da wieder ranzukommen und das Delta zu verringern. Diese drei Sachen sind eher jetzt momentan Standard oder Postgres Professional. Das ist eine russische Firma, EDB. Die haben halt so eine Art Open Core-Modell selber gemacht. Dass sie proprietäre zusätzliche Features, in dem Fall Multimaster-Replikation und sowas
08:03
und hier auch Oracle-Kompatibilität in ihr Produkt reinhaben und dann versuchen, immer möglichst schnell nach einem Postgres-Release dann selber ihr Produkt zu aktualisieren. Was interessant ist, Citus Data und PipelineDB sind zwei Projekte, die aufgrund der Erweiterbarkeit von Postgres und dieser API geschafft haben, jetzt anzuforken.
08:23
Das heißt, die neuen Versionen bzw. PipelineDB ist glaube ich noch dabei. Das sind einfach nur noch Erweiterungen. Man nimmt den Postgres-Vanilla-Qualcode und macht dann Create-Extension-Citus auf verschiedenen Knoten und hat dann ein spaltenbasiertes Data-Warehouse-Multi-Parallel-Processing-Ding über diese Citus-Erweiterung, die halt relativ mächtig ist, kann man sich vorstellen.
08:43
Aber die haben es geschafft, das nur noch über die Erweiterungs-API von Postgres zu implementieren. Deswegen sind das auch keine Forks. Ist auch inzwischen Open Source, aber auch wieder Open Core. Sie haben dann noch gewisse Enterprise-Features obendrauf in ihrer Version. Ansonsten gibt es Postgres auch inzwischen bei allen großen Cloud-Anbietern.
09:01
Seit kurzem auch auf Azure, ansonsten Google Cloud, SQL und Amazon und halt dann noch so ein paar kleine, aber gut Open Stack. Ist ehrlich gesagt die Postgres-Funktionalität nicht so super groß, aber habe ich der Vollständigkeit halberhin zugefügt. Kurz noch die Hauptfeatures, bevor ich dann zum eigentlichen Teil komme.
09:25
Bekannt ist Postgres dafür, dass es Rock Solid ist, also Stabilität zuerst und Optimierung danach. Stabilität war so Ende der 90er, Anfang der Nullerjahre und seitdem versuchen sie dann auch die Features und die Performance zu verbessern.
09:40
Es gab, muss man auch dazu sagen, mit der Replikation am Anfang, in den ersten Jahren immer mal wieder ein bisschen Probleme. Wir sind dabei inzwischen auch eigentlich beseitigt und seit einigen Jahren ist es stabil. Ansonsten hat es einen kostenbasierten Query-Planner, der versucht auszurechnen, wie der sinnvollste Weg ist, eine Abfrage auszuführen.
10:02
Und auch interessant, große Anzahl Erweiterungen habe ich schon ein bisschen erwähnt, dass Erweiterungen wichtig sind und es da viele gibt. Zum Beispiel für verschiedene Datentypen, aber auch für verschiedene administrative Sachen wie Tabellen reorganisieren und so weiter. Transaktionale Änderungen in der Datenbankstruktur, das heißt, man kann ein Droptable,
10:21
wenn man es in einer Transaktion gemacht hat, wieder zurückrollen, was nicht jede Datenbank kann. Und ansonsten hohe Anzahl an Treiber für Programmiersprachen, man kann das in allen möglichen Sprachen schreiben und man hat auch viele verschiedene prozedurale Sprachen. Also man kann eine Funktion in der Datenbank auch in R schreiben oder in Python oder Perl oder was einem da gefällt.
10:44
Was inzwischen auch immer wichtiger wird, sind Fremddatenwrapper, FDW, Foreign Data Wrapper, für den Zugriff auf viele andere Datenquellen oder Postgres selber. Es gibt dieses genannte Postgres FDW, dass man mit einem Postgres-Datenbank transparent auf eine andere Postgres-Datenbank, die eventuell in einem anderen Rechenzentrum steht, zugreifen kann.
11:03
Und da dann auch lokal macht man dann ein Update, blablabla, auf eine Tabelle, aber das ist tatsächlich dann eigentlich eine Änderung auf dem entfernten Server. Da gibt es schon sehr viele interessante Möglichkeiten, Postgres so zu erweitern. Werde ich auch später noch ein bisschen dazu kommen. Aber auch für Zugriff auf andere Datenbanken, Oracle, MySQL, Informix,
11:24
gibt es da Möglichkeiten oder bei SQL Alchemy gibt es ein Ding, Multicorn heißt das, mit dem man dann praktisch alle SQL-Anwendungen macht. Es gibt sogar was für Twitter und solche Geschichten. Nur noch ganz kurz eine kurze Übersicht.
11:40
Wer benutzt Postgres überhaupt? Was interessant ist, es ist sowohl Skype, was von Microsoft übernommen wurde, als auch Instagram, was von Facebook übernommen wurde und eigentlich ein MySQL-Shop ist, benutzen weiterhin Postgres, wie man in letzter Zeit wieder erfahren hat. Reddit benutzt es, glaube ich, noch. Und ansonsten gibt es auch, Zalando ist ein großer Nutzer in Deutschland, die auch viel selber beitragen und da komme ich auch später noch ein bisschen dazu.
12:07
Um zu zeigen, dass diese Stabilität First eine Sache war, aber inzwischen sehr viele Features gemacht wurden, das habe ich mal zusammengetragen aus zwei oder drei damaligen Fragen
12:21
oder Stellen, was die User damals gerne hatten. Das ist vor acht Jahren gewesen. Diese Sachen gab es aber nicht im Postgres im Endeffekt oder waren halt relativ schlecht. Und wenn man sich das heute anschaut, wurde das alles inzwischen implementiert, bis auf autonome Transaktionen. Da gab es auch schon Patches, aber die sind noch nicht drin.
12:41
Man kann das über dieses Postgres-FTW oder Debilink irgendwie implementieren, aber ist nicht besonders toll. Also über einen Umweg geht das auch noch. Aber alle anderen Sachen sind eigentlich inzwischen durch. Also da wurden diese Sachen alle fertig gemacht und sind in der heutigen Version, also in 9.6, enthalten. Ich will jetzt noch ganz kurz erst, bevor ich dann eben auf Replikationen komme,
13:05
eine Aussicht auf Postgres 10 machen, weil das die neue Version sein wird, die in einer Weile rauskommt, und da ist vielleicht noch nicht eben klar, was es an neuen Features gibt. Die drei Hauptfeatures sind logische Replikationen. Das erkläre ich auch gleich. Weitergehende Parallelisierungen. Also es gibt parallele Queries seit der Version 9.6.
13:24
Dieses wird jetzt deutlich besser sein. Wenn da noch Zeit ist, werde ich das am Ende auch noch zeigen. Und native deklarative Partitionierungen. Man konnte immer schon über Vererbung von Tabellen und genug Tooling oder Erweiterung Partitionierungen implementieren, aber jetzt ist es nativ in der Datenbank drin.
13:42
Sicherlich noch zu verbessern. Es gibt auch schon jede Menge Patches für die nächste Version. Robert Haas hat gerade vor ein paar Tagen einen Blogpost dazu geschrieben, der Architekt bei EnterpriseDB, was alles noch kommt. Aber das ist in 10 drin und funktioniert soweit. Ansonsten ein kleines, basiertes Verbindungsfailover.
14:00
Würde ich vielleicht auch versuchen, nachher zu zeigen, wenn es klappt. Voren commit für Synchrones Stampers. Das ist jetzt schon etwas spezifisch. Da gehe ich gleich noch drauf ein. Vereinfachte Konfiguration von Replikationen. Das kommt auch gleich noch. Ansonsten wurde das Scram-Protokoll implementiert. Anstatt von MD5-gehashten Passwörtern. Also eine sichere Authentifizierung. Und Hashindexe können jetzt endlich verwendet werden.
14:22
Es gab Hashindexe schon lange, aber sie waren nicht crashsicher. Das heißt, sie wurden nicht repliziert. Und nach dem Crash musste man den Index neu anlegen. Das wurde jetzt endlich geändert. Und die sind jetzt produktiv einsetzbar. Stellere Ausführungen von Expressions. Was für Administratoren vielleicht auch interessant ist, man kann jetzt die SSL-Einstellung oder SSL-Anschalten machen,
14:41
ohne dass man die Datmark neu starten muss. Eine Datmark Neustart ist halt immer mit einer Downtime im Endeffekt verbunden. Die Clients werden alle erst mal rausgeschmissen und müssen sich neu verbinden. Das macht man normalerweise nicht gerne. Außerdem sind die Caches dann nicht warm. Deswegen ist das auch ein großer Vorteil. Also wenn man den spezifischen Anwendungsfall hat
15:01
und gerade zum Beispiel die Zertifikate auswechseln will, da musste man früher immer einen Neustart machen. Und das kann man jetzt online machen. Jetzt aber zu Replikationen. Generell ist es so, dass Postgres seit Revolution 9.0, und das war damals auch ein Grund, wieso man diesen Sprung von 8.4 auf 0.0 gemacht hat,
15:24
physikalische Replikationen hat. Das nennt sich Streaming Replication. Dabei wird das Transaktionslog, also die Datei, in die alte Transaktion zunächst geschrieben werden, bevor sie dann in die Tabellen auf der Festplatte weitergeleitet werden.
15:40
Dieses Transaktionslog wird über die Netzwerkverbindung oder sogar eine direkte Datenmarkverbindung an die Standbys übertragen und dort fortlaufend in das eigene Transaktionslog geschrieben, sodass man dann der Standby wendet diese an und simuliert so eine Art Wiederherstellungsmodus.
16:01
Also wie wenn man dann Crash Recovery macht, wo dann die noch ausstehenden Transaktionslogs durchgenommen werden und alle Änderungen ins Datenverzeichnis geschrieben werden, bevor der Server dann zur Verfügung steht. Eines der Hauptfeatures davon ist, dass man lesende Abfragen machen kann auf dem Standby, aber eben keine schreibenden Abfragen.
16:21
Also es ist kein Multimaster, sondern es ist ein Master oder Primary Standby, Master Slave. Also vor allem letzte Woche gab es den Commit, den Sie letzten Slave aus dem Quellcode rausgenommen haben. Sie nennen es nur noch Primary Standby jetzt. Ist aber natürlich dasselbe. Die beiden großen Einschränkungen davon sind,
16:42
die gleiche Major Version zwischen Primary und Standby. Das heißt, man kann damit keine Upgrades machen. Man kann nicht sagen, hier ist mein Postgres Server mit 9.5 und hier ist mein anderer, dann mache ich mal einen mit 9.6 und dann mache ich eine Replikation und sobald das fertig ist, switche ich einfach meinen Client und ich habe einen Versionsupgrade gemacht.
17:01
Das geht leider nicht. Man muss immer die gleiche Version haben. Und man muss immer die gesamte Instanz nehmen. Also man kann nicht sagen, ich möchte nur die Datenbank oder nur die und die Tabellen replizieren. Man muss immer alles replizieren. Das sind die beiden Einschränkungen. Um das ein bisschen zu zeigen, wie das funktioniert, finde ich das Bild eigentlich ganz gut
17:20
von einem Vortrag in Tallinn letztes Jahr. Die Anwendung schreibt lesend oder schreibend auf den Master und kann halt lesen vom Standby. Die Transaktionslogs werden so genannte Write-Ahead-Log geschrieben. Das ist der Datenbestand. Und dann gibt es einen Prozess, den sogenannten Wahlsender, der dann die Transaktionslogs an den Standby schickt
17:43
und der dann diese hier sozusagen dann ins eigene Transaktionslog schreibt und dann in den Heap und dann in den Executor und dann stehen sie dem Standby zur Verfügung. Da sieht man auch schon, dass es dann verschiedene Levels von Synchronen oder Asynchronen Standby gibt.
18:01
Normalerweise ist es asynchron. Das heißt, sobald das hier rübergeschickt wurde, ist das aus Sicht des Masters okay. Und die Transaktion wird dann dem Client als fertig mitgeteilt. Aber man kann dann sagen, nee, ich möchte das synchron machen, ich möchte, dass der das empfangen hat, ich möchte, dass der das in seinen Transaktionslog geschrieben hat, ich möchte, dass er das auf dem Datenmarkt geschrieben hat
18:22
oder ich möchte, dass es für lesende Abfragen bereit steht. Das sind die Möglichkeiten hier. Und das ist halt gerade hier der letzte Punkt, den es jetzt seit 96 gibt, ist auch wichtig, wenn man eben dann verschiedene Standbys hat und die Anwendung dann loadbalancen will, zum Beispiel über irgendwelche Möglichkeiten,
18:43
sodass dann man schreibt etwas auf den Master und hat dann sofort den gleichen Startbestand auf dem Standby. Das bedeutet natürlich, dass das Ganze länger dauert. Also ein Commit muss halt dann durch den ganzen Weg gehen und der Client wartet in dem Fall auf solange bis das der Fall ist.
19:00
Ansonsten operativen Features. Also das Hauptproblem war immer, oder eines der Hauptprobleme war, dass man die Transaktionslogs auf dem Primary vorhalten muss. Wenn der Standby für eine Weile nicht da ist oder wenn man fünf Standbys hat und einer ist down und dann irgendwie nach zwei Tagen merkt man das und schaltet ihn wieder an und dann fordert er die Transaktionslogs an,
19:21
aber der Master hat oder der Primary hat die inzwischen schon gelöscht. Das kann man jetzt mit Replikationsslot sagen, okay, also dieser Standby hat den Slot und bitte den richtigen Transaktionslogs löschen, bis das von dem abgearbeitet wurde. Das hilft im operativen Operation.
19:42
Man muss natürlich dann aber schauen, dass die Transaktionslogs auf dem Primary nicht so lange auflaufen, dass irgendwann die Festparte voll ist. Und dann vorher den Standby entweder abschalten oder was machen. Aber zumindest hat man das Problem mit dem Standby nicht. Früher war das so, wenn die Transaktionslogs nicht mehr vorhanden sind,
20:01
da hat man noch die Möglichkeit über ein Archiv, eine zentrale Archivierung zu machen. Aber wenn man das auch nicht gemacht hat, dann ist der Standby einfach nicht mehr verwendbar. Man muss ihn neu aufsetzen, wenn es die Transaktionslogs nicht mehr gibt. Ansonsten kann man relativ einfach einen Standby klonen über das PG-Base-Backup-Programm. Man kann Switchover, Switchback, Promote und Remastering machen
20:21
mit verschiedenen Funktionen. Und man kann auch kaskadierend, also man hat einen Standby und an dem Standby hängt dann noch ein Standby dran. Oder auch zeitverzögert, dass man sagt, ich möchte bitte fünf Minuten warten, bis ich die Transaktion anwende, falls irgendjemand dann doch ein Droptable macht oder ein Delete From ohne Wer,
20:42
dass man das dann anhalten kann und dann zu Not irgendwie noch reagieren kann. Ansonsten wird das natürlich alles sofort auf dem Standby weitergeführt und gegen solche Sachen hilft dann die Hochverfügbarkeit nichts. Ja, die Frage ist, was passiert, wenn das Netzwerk unterbrochen ist,
21:12
dann würde keine Transaktion laufen. Das ist korrekt und das ist auch das Problem. Also man sollte deswegen nie synchrone Replikationen mit nur einem Standby machen.
21:21
Normalerweise hat man zwei Standbys und einer davon ist synchron und der andere ist asynchron. So dass der zweite dann... Entschuldigung, ja, also ich habe... Genau, es gibt auch asynchron, das ist der normale Fall, beziehungsweise was man dann machen kann, ist halt synchron lokal zu machen.
21:44
Das heißt, man hat dann ein Synchron-Commit, das ist dann sicher, dass es auf den Primary geschrieben wurde, dann sagt einem Client alles okay und dann ob der Primary das dann an den Standby geschickt hat, das ist dann nicht mehr das Problem von dem Commit. Das ist der Default, sage ich mal.
22:01
Und dann kann man halt sagen, okay, ich habe so und so viele inzwischen eben dieses Quorum-basierte synchrone Replikation, das heißt, ich habe fünf Standbys und die Standbys A, B und C sind meine synchronen Standbys und ich will, dass mindestens zwei von den dreien das dann committet wurde, dann ist es für den Client okay, das kann man inzwischen auch machen. Dann ist man sicher, dass wenigstens zwei das haben.
22:21
Aber man muss halt dann immer schauen, dass man mindestens einen zweiten potenziellen synchronen Standby hat, der dann übernehmen kann, wenn der erste es nicht mehr hat, weil sonst in der Tat der Stand der Master einfach stehen bleibt. Das ist dann ein großes Problem, da muss man aufpassen. Genau, ich glaube, dann habe ich soweit alles gesagt,
22:41
außer einfache Konfiguration. Ich versuche jetzt mal das zu zeigen.
23:05
Und zwar links würde ich jetzt einen Master. Okay, funktioniert leider nicht gut. Ah, doch. Also links, kann das jeder sehen? Geht es einigermaßen? Ich habe vorhin versucht zu schauen, okay. Links wird ein Master aufgesetzt.
23:21
Also hier ist jetzt erstmal nichts drin. Im Datenplatz ein ist das Date 1. Erstmal mit Inidb initialisiert. Und dann mit ... Schön. Na gut, also dann hat das nicht funktioniert.
23:47
Ich habe es ... Dann zeige ich es ja so, tut mir leid.
24:02
Vielleicht habe ich jetzt dann irgendwas noch in der letzten Zeit gemacht. Also im Endeffekt, man setzt es auf, man startet den Primary und kann dann über das PG Base Backup sagen, ich habe ein zweites Datenverzeichnis und schreibt mir an der Recovery Conf, das ist die Konfigurationsdatei des Standbys. Man muss dann den Port ändern.
24:24
Man muss inzwischen in C nicht mehr Hot Standby auf On setzen. Das ist nicht mehr der Fall inzwischen. Das wurde noch geändert. Das habe ich jetzt noch nicht in den Slides hier überarbeitet. Hot Standby ist der Default. Das heißt, das Einzige, was man machen muss, man muss den Port von 5432, das ist der Standardport,
24:42
auf 5433 zum Beispiel ändern. Und dann kann man den Standby starten und sieht dann, der Standby ist da. Insofern ist die Einrichtung inzwischen sehr einfach. Diese drei oder vier Kommandos im Endeffekt reichen aus, um ein Primary und dann ein Standby mit Stream Replication.
25:00
Also jetzt mit 10 zu machen. Mit 9.6 muss man eben noch ein paar Konfigurationsparameter zusätzlich ändern. Aber in 10 wird es dann so einfach sein. Mal schauen, dann werden wahrscheinlich die anderen Demos auch nicht gut funktionieren, aber dann sehen wir mal weiter. So weit jetzt zur Stream Replication,
25:21
also der Start. Eben wollte ich gerade fragen, sind Fragen. Kann man das auch machen, wenn ein Server schon existiert, den dann quasi replizieren? Ja, kann man das auch machen, wenn ein Server schon existiert. Genau, man kann das online machen. Das Einzige, was der Server muss, eben gewisse Konfigurationsparameter haben,
25:41
dass er erlaubt, Replikationsverbindungen anzunehmen und so. Also wenn er dementsprechend aufgesetzt ist und er muss, also wie gesagt, bei 10 ist das automatisch in Version 10. In 9.6 muss er eventuell noch ein paar Konfigurationsparameter ändern. Vor allem den Wahllevel auf Replika oder Standby stellen.
26:02
Aber dann geht das so. Man kann das später noch machen, man muss auch nicht den Master deswegen neu starten. Außer man hat eben die Konfiguration nicht so, dass das funktionieren würde, aber im Allgemeinen geht das. Sodass man für den Aufsetzen eines Standbys, das ist eigentlich ein wichtiger Punkt, muss man den Master nicht neu starten. Man kann das online machen.
26:21
Sonst noch Fragen? Ja.
26:43
Der Client, also die Frage ist, wie man eine synchrone Replikation konfiguriert. Also es gibt dann die Konfigurationsparameter Synchronous Standby Names, soweit ich was weiß. Und da schreibt man dann eben rein, die und die Standbys, die haben dann,
27:01
man kann denen normalerweise einen Namen dazugeben als Identifikation. Oder sinnvoll im größeren Rahmen das zu machen. Und dann kann man sagen, die und die sind meine Synchrone Standbys und dann wartet er eben darauf. Den Level der Synchronicität kann man auch gleichzeitig machen. Und das ist auch ein wichtiger Punkt, den ich jetzt vielleicht nicht so erwähnt habe bis jetzt,
27:22
aber gut, dass ich mich dran erinnere. Man kann das auch pro Transaktion machen. Das heißt, man muss nicht sagen, irgendwie seine Anwendung, okay, ich mache jetzt die Synchrone oder Asynchron, sondern die Anwendung kann, sofern generell die Einstellungen so sind, dass es theoretisch möglich ist, kann die Anwendung sagen, oh, das ist aber eine wichtige Transaktion.
27:41
Bevor ich die kommite, stelle ich doch mal meinen Synchronous Commit auf RemoteApply oder auf Write oder so. Das er ja auf dem Standby ist und nicht nur auf dem Master. Und dann kommite ich und dann gehe ich wieder auf Asynchron zurück, zum Beispiel. Sodass man das nur für wichtige Sachen macht, weil eben da ein Performanceverlust ist, aber da kann man eben sicher sein, dass die dann auch wirklich auf dem Standby geschrieben sind.
28:02
Und das kann nicht jede Art machen. Genau. Sonst noch Fragen? Oder hat das dann so einigermaßen die Frage beantwortet? Wenn keine Fragen mehr sind, dann komme ich jetzt zu den logischen Replikationen, weil, wie gesagt, das eines der Features ist von 10.
28:24
Beziehungsweise logische Replikation gab es im Prinzip auch vorher schon. Die Hauptpunkt von logischer Replikation, also logische Replikation bedeutet dann, es wird nicht einfach der physikalische Transaktionslog streamen, wo dann halt steht, schreibe in Block 387 die so und so folgenden Bytes,
28:43
sondern da wird dann gesagt, okay, wir updaten, wir machen ja immerhin diese und diese SQL-Befehle als Update, also jetzt mal so vereinfacht formuliert. Der Vorteil davon ist dann eben, dass es versionsunabhängig ist. Man kann es dann von 9.5 auf 10 replizieren und so weiter.
29:02
Und man kann im Allgemeinen auch, je nach Lösung, einzelne Datenbanken oder sogar nur Teile von Tabellen oder Datenbanken replizieren. Also das sind genau die beiden Einschränkungen für physikalische Replikation. Wer mit logischer Replikation abgedeckt. Es gibt schon sehr lange trigger-basierte logische Replikation.
29:24
Slony 1, Blondist, Bukado, was sogar Master Master kann, sind so die drei großen, die es schon sehr lange gibt, wobei Slony eigentlich die Version ist, die bei uns und bei unseren Kunden normalerweise verwendet wird für solche Major Upgrades. Ansonsten gibt es seit Division 9.4 das sogenannte Logical Decoding,
29:43
was man so als Change-Data-Capture auch kennt, wo dann die Transaktionslogs dekodiert werden und eben durch beliebige Outputs, entweder als JSON oder wie auch immer, versendet werden können. Und darauf basierend gibt es PG-Logical als Erweiterung,
30:03
die dann auf beiden Rechnern installiert wird und durch dieses Logical Decoding dann logische Replikation implementiert und eben seit 10 Nativ Logical Replication. Im Endeffekt wurde hier Teile des Codes verwendet. Das User Interface ist einfach anders.
30:20
PG-Logical verwendet hauptsächlich Funktionen. Native Logical Replication verwendet dann SQL-Befehle. Das zeige ich gleich. Es gibt dann noch B-Directional Replication, BDR, was im Endeffekt das Oberprojekt ist. PG-Logical ist dann auch wieder ein Teil davon. Das ist im Endeffekt dann Master Master. Also diese logischen Replikationslösungen haben auch zusätzlich noch den Punkt,
30:42
dass man auf den Standby schreiben kann. Das wird nicht verhindert. Nur verhindert auch niemand, dass man dann Konflikte reinschreibt. Dann hat man halt irgendwann ein Problem und BDR ist dafür da, dieses Konflikt Resolution zu machen und noch andere Sachen wie globale Sequenzen, die noch nicht in Postgres drin sind. Das kommt immer mehr rein.
31:01
Das wird auch irgendwann kommen, gehen wir davon aus, aber ist noch nicht in Postgres drin. Kurz zur, wieso man Logical Decoding benutzt und nicht triggerbasiert, ist hier so ein Benchmark auch aus einem Blogpost. Das ist Streaming Replication, wenn man einen Benchmark-Test laufen lässt auf dem Master,
31:23
wie das mit wie vielen Clients dann immer schlimmer wird. Und hier sieht man, dass PG-Logical einigermaßen gut skaliert, aber diese triggerbasierten Systeme, wo im Endeffekt dann die lokalen Änderungen erstmal durch einen Trigger, also alle Änderungen werden abgefangen
31:41
und dann in eine lokale Tabelle geschrieben und die dann synchronisiert auf den Standby und dort angepasst. Da hat man dann halt zusätzliche Schreiblast und Overhead und die sind halt recht schlecht, wenn man hier sieht. Deswegen ist diese interne logische Replikation schon ein großer Fortschritt.
32:01
Und das funktioniert sehr ähnlich wie die Streaming Replication. Das ist ungefähr das gleiche Bild wie vorhin.
32:20
Der folgt mir, wie man hier sieht. Man kann jetzt auch schreiben auf den Subscriber. Das ist ein Provider-Subscriber-Modell. Aber im Endeffekt hat man das gleiche, außer dass es hier statt dem Wahlsender jetzt ein Output-Plugin gibt und hier eine Applied-Plugin. Und das eben dann nicht mehr physikalisch ist, sondern logisch.
32:40
Das Setup ist auch mit 10 relativ einfach. Wir können ja schauen, ob es jetzt noch mal funktioniert. Aber ich fürchte nicht. Mal sehen.
33:09
Ich lasse es hier. Tut mir leid. Aber das wäre das, was halt passiert ist. Man hat ein Primary. Man muss den Primary, also das, was man einen noch einstellen muss,
33:21
dass man muss eine Konfigurationsänderung in 10 noch ändern, nämlich den Wahllevel von Replika auf Logical ändern, dass eben dann mehr, noch ein paar Sachen zusätzlich geschrieben werden in den Transaktionslogs. Das kann man aber auch online machen. Und dann ist die Syntax Create Publication for all Tables.
33:42
Man kann dann auch verschiedene Sets nehmen von Tabellen. Aber im Allgemeinen oder zum Zeigen kann man einfach eine Publication machen. Auf dem Standby macht man eine Subscription. Man muss eine Verbindungstring angeben. Und man muss die Publication referenzieren. Dann wird automatisch so ein Replikationsslot,
34:01
den ich vorhin erwähnt habe, erstellt. Und dann wird auch automatisch der Datenbestand synchronisiert. Außer man will das explizit nicht machen. Und wie man hier sieht, die Being-Named-Primary, das wäre jetzt eben die Datenbank, ist es pro Datenbank. Man kann aber auch...
34:20
Ja, okay, das ist pro Datenbank für die Tabellen, die man hier in dem Publications Set drin hat. Die momentanen Einschränkungen sind noch, man muss die Tabellenstruktur separat synchronisieren oder aufsetzen. Das heißt, man muss die Tabelle dann auch anlegen auf dem Standby. Und man braucht Superuserrechte.
34:43
Zumindest auf der Publications-Seite sind dann ein paar Einschränkungen dazu. Man kann das ein bisschen abändern, aber das ist momentan noch so. Da wird es auch in 11 sicher Verbesserungen geben. Und vor allem, was in der Version 10 noch nicht drin ist, ist Failover, Failback. Also für solche Sachen ist es noch nicht sehr gut geeignet.
35:00
Das ist so eine Art 1.0-Version. Funktioniert, es gab da ein paar Probleme. Ich würde es jetzt vielleicht nicht sofort, nachdem die Version 10.0 rauskommt, produktiv einsetzen. Erst mal ein bisschen warten. Aber für nicht-kritische Sachen ist das schon eine gute Sache.
35:41
Die Frage ist, ob dieses Four-All-Tables auch Tabellen umfasst, die danach noch geschrieben werden. Das ist eine gute Frage, kann ich jetzt auf Anheben nicht genau sagen. Man kann auf jeden Fall meines Wissens die Subscription refreshen.
36:01
Das wäre dann sicherlich der Fall. Ich bin mir nicht sicher, ob das bei All-Tables so als Catch-All eventuell auch automatisch passiert. Kann ich leider jetzt nicht genau sagen. Bitte? Bei Grants funktioniert es nicht. Ja, bei Grants funktioniert es nicht. Gab es noch eine Frage? Was ist mit All-Tables? Kommt das mit rüber oder auf?
36:22
Wenn ich ein Alter-Table mache auf dem High-Grade? Die Frage ist, was mit dem Alter-Table passiert, und das ist eben auch das Problem. Eines der Sachen, die für so eine Master-Master-Replikation noch fehlen, ist eben die Tabellenstruktur. DDL ist generell immer ein Problem bei diesen logischen Replikationslösungen
36:43
im Postgres-Bereich. Für Pygeological gibt es dann so eine Funktion, die dann alles sperrt und das dann auf dem Stand-By macht. In dem Fall ist es glaube ich auch nicht dabei. Die Sachen werden nicht, oder bin ich jetzt auch nicht 100% sicher ehrlich gesagt,
37:00
aber meines Wissens muss man da dann auch sehr stark aufpassen. Insofern ist es schwierig, das für längeren Zeitraum einzusetzen. Es ist sinnvoll für Upgrades zum Beispiel zu machen, dass man sagt, wir machen jetzt hier einen Upgrade
37:21
und replizieren das logisch. Da haben wir jetzt eine Frozen Zone. Wir machen keine DDLs, keine Änderungen in der Datenbankstruktur. Machen das Upgrade und dann haben wir den neuen Server und dann können wir wieder Änderungen machen. Das funktioniert, aber wenn man dazwischen Änderungen machen will, muss man immer mal aufpassen bei Postgres.
37:41
Gibt es sonst noch Fragen zur logischen oder generellen Replikation? Die Frage ist, ob man im Standardfall physikalische Replikation
38:03
und dann halt nur für Upgrades logische nimmt. Das wäre das, was ich momentan empfehlen würde, weil auch die Performance besser ist und wenn man eh jetzt einen vollen Stand-By braucht, dann ist das sicherlich sinnvoller momentan, dass es etabliert. Es kann eben keine Major Version Upgrades, da komme ich auch gleich noch dazu,
38:21
aber das ist das, was sinnvoll ist. Und man für Sonderfälle, also diese Physiological-Erweiterung jetzt in der neuen Version kann zum Beispiel auch innerhalb von Tabellen filtern, dass man dann nur bestimmte Zeilen repliziert. Und dann, wenn man diese Sonderfälle hat, also irgendwie jetzt eine Art Stand-By hat,
38:41
der halt nur irgendwelche, einige Daten braucht, aber nicht alle, dann ist es auch sehr sinnvoll, sowas dafür einzusetzen, aber wenn man halt für eine Art Failover oder Hochverfügbarkeit sollte man momentan eine physikalische Replikation benutzen. Ja, man kann das auch beides gleichzeitig machen.
39:04
Halt dann mit zwei verschiedenen Stand-Bys. So eine zeitversetzte, asynchrone Replikation, wie wird die denn angetrigert, dass man jetzt dann sagt, okay, ich möchte dann halt in zwei Stunden, in zwei Stunden möchte ich eine Replikation haben.
39:21
Also was man machen kann, man kann diese Recovery Conf, kann man das reinschreiben, dass es ein Delay hat. Aber ich weiß nicht genau, wie der Konfigurationsparameter heißt, aber der ist halt dann generell für alle. Man kann jetzt nicht pro Transaktion sagen, okay, jetzt bitte erst, weil das macht auch keinen Sinn. Oder? Und der Stand-By würde die Daten sofort bekommen.
39:42
Aber der Stand-By sagt dann nein, ich warte jetzt zwei Stunden, bis ich das wieder einspiele. Ach so, aber wenn ich erst, ich sammle erst mal diese Eränderung und sage dann, nachts haben wir eine Zeitung, nachts machen wir die Replikation. Okay, also die Frage war, wie geht das mit dem Zeitverzögerten? Die eine Antwort ist, das kommt alles am Stand-By an,
40:01
die Transaktionslogs, und werden halt erst später angeführt. Man kann auch dem Stand-By sagen, bitte warte, bitte Transaktion, Replikation anhalten. Das ist halt ein Select PG Recovery Pause oder sowas. Also ich weiß nicht genau, PGXLogApplyPause. Und Resume, da gibt es zwei Funktionen, wo man die Replikation anhalten und wieder weitermachen kann.
40:23
Da gibt es halt gewisse operative Probleme, dass man das nicht zu lange rauszögern sollte, weil je nachdem, wenn man dann noch Lesenabfragen auf dem Stand-By macht, die irgendwelche Logs benötigen, damit der Stand-By, wenn man das langlaufende Transaktionen hat,
40:40
da sollen ja nicht einfach die Daten plötzlich nicht mehr da sein am Ende. Das heißt, der Stand-By muss dann auch Logs machen und die verhindern dann, dass der Master oder der Primary die Transaktionslogs oder die Transaktionen aufräumen kann. Da wird dann die Replikation auch angehalten. Also man muss da ein bisschen aufpassen bei langhalten Sachen.
41:01
Das läuft dann auch alles an auf dem Master. Aber prinzipiell geht das. Man kann es abschalten, man kann es anhalten, man kann es zwar zeitverzögert ansetzen. Gut, sonst noch Fragen. Dann Hofverfügbarkeit. Hofverfügbarkeit ist natürlich ein großes Feld, deswegen müssen wir schauen, wie weit wir jetzt noch Zeit haben.
41:23
15 Minuten, danke. Generell ist es halt bekannt, Schutz gegen Hardware-Ausfall, CPU-Defekt, Netzwerkkarteausfall, Kernelpanic, Absturz des Postgres-Prozesses hoffentlich nicht, aber kann vielleicht auch vorkommen. Aber man kann das auch so definieren, dass die Wartung den Betrieb nicht beeinträchtigt.
41:42
Neustart des Postgres-Prozesses nach einem Patching, also man macht eine Minor-Versionsupgrade, dass da eben nicht alle Clients rausgeschmissen werden. Postgres hat sehr viele Konfigurationen und einige kann man nur durch einen Restart anwenden, einige kann man durch einen Reload anwenden,
42:00
der halt online geht. Einige kann man einfach so innerhalb von einer Transaktion oder als Client machen. Major-Versionsupgrade ist ein genereller Punkt. Major-Version bedeutet normalerweise immer, man muss einen Dump machen des Tabellenbestands oder einen Restore, oder man macht ein sogenanntes In-Place-Upgrade. Aber auch da ist eine Downtime verbunden, die vielleicht nicht lang ist, aber auf jeden Fall da.
42:25
Ansonsten aktuellisierung des Betriebssystems ist prinzipiell natürlich auch ein Punkt von Hofverfügbarkeit, aber da gehe ich jetzt nicht drauf ein. Macht man normalerweise, dass man halt einen Switchover macht auf den anderen, dann ist das Betriebssystem aktualisiert und dann switchback.
42:40
Ansonsten auch die Anwendung ist durchgehend verfügbar, ist ein Punkt, auf den ich nicht eingehe, aber das ist natürlich auch ein Punkt. Keine langen Halten in Logs, während Schemaeinungen zum Beispiel. Man fügt eine Spalte hinzu und dann gibt es einen exklusiven Log auf die Tabelle und während die Spalte irgendwie geschrieben wird auf den Datenbeschlang können dann die Clients nicht mehr auf diese Tabelle zugreifen.
43:01
Das ist im Endeffekt dann auch keine Hochverfügbarkeit, könnte man so definieren. Und daher hilft Postgres auch durch einige Änderungen an Tabellenstruktur, können da ohne exklusive Logs durchgeführt werden. Genau, aber jetzt erst mal zu dem ersten Punkt, nämlich ein Failover sozusagen
43:22
von einem Primary auf einen Standby. Was passiert bei Hardwareausfall? Da gibt es standardmäßig, ist im Allgemeinen eine Benutzung Pacemaker und Corosync, das ist der hohe HA-Stack von Linux. Als Ressourcenagent gibt es den PGSQL Ressourcenagent, der ist der Standard bei Pacemaker.
43:42
Und es gibt seit einiger Zeit auch den sogenannten Postgres Automatic Failover Ressourcenagent, der jetzt als Konkurrenz sozusagen, als von einer anderen Firma geschrieben wurde. Und einige weitere Produkte sind Rapmanager, PGpool 2, auf die beiden würde ich jetzt nicht so sehr eingehen,
44:00
aber die können beide auch mit Hochverfügbarkeit zu einem gewissen Punkt abdecken. Patroni ist ein Projekt, was ich noch nachher vorstellen werde, wenn Zeit ist. Und darauf Compose Governor und Stolon sind auch zwei. Also diese drei sind im Endeffekt so Cloud-Native-Geschichten zwischen Compose Governor, Patroni ist im Endeffekt ein Falk von Compose Governor,
44:20
die ja für so Cloud-Geschichten und automatische Skalierungen und so geschrieben sind. Das ist sozusagen der Server Failover in dem Punkt, also was passiert, wenn irgendein Rechner nicht mehr funktioniert? Was geht das dann, aber was passiert, was macht der Client, was machen die Anwendungen?
44:43
Da gibt es dann den Punkt, man hat eine virtuelle IP, das macht Pacemaker, das heißt, der fährt dann die virtuelle IP runter oder fährt sie halt dann auf dem Standby nach dem Promote dann für den neuen Primary dort hoch und der Client verbindet sich dann auf diese virtuelle IP und hat dann immer die aktuelle.
45:02
Man kann auch DNS machen mit kurzem Time-to-Life, aber da muss man schon ein bisschen aufpassen. Was man verwenden kann ist HAProxy mit Health Check, dass HAProxy dann schaut, ist das noch der Primary? Da gibt es ein paar Erweiterungen zum Beispiel vom Postgres, die dann ein HTTP-Port exposing oder Patroni macht das auch,
45:24
wo er sagt, okay, ich bin der Primary und HAProxy kann dann immer den Health Check machen und verbindet dann halt die Clients dementsprechend mit dem richtigen. Man kann versuchen automatisiert, PGBoundser ist ein Connection-Pooler oder Proxy, die Verbindung, die Konfiguration von diesen Sachen zu schreiben,
45:41
das macht Rap Manager zum Beispiel oder schlägt das vor, dass man dann eine neue Konfiguration schreibt und dann den neu lädt und der dann die Clients auf die neue IP oder den neuen Hostnamen schickt. Ansonsten, was es auch seit einiger Zeit gibt, PGJDBC hat das schon eine Weile, es ist ein kleinbasiertes Failover, in dem man einfach sagt, okay, das sind meine Hosts
46:01
und die sind prinzipiell alle Master und verbindet sich halt mit dem Primary. Der schaut dann bei jedem Verbindungsaufbau, okay, bist du überhaupt ein Primary, kann man da auf dich schreiben und wenn das der Fall ist, dann verwendet er den LIPPQ, also der Standard Client Bibliothek von Postgres, wird das auch ab 10 können. Da kann man dann zwei oder mehrere Hostnamen eintragen
46:22
und wenn der erste plötzlich nicht mehr geht, verbindet er sich mit dem zweiten oder dritten. Ich würde jetzt noch ein paar Vorschläge machen oder ein paar Sachen zu Pacemaker sagen. Prinzipiell, ja, oder erstmal eine Frage? Ja, es ist die Frage, was?
46:56
Okay, die Frage ist, dieses kleinbasierte Failover,
47:04
ist das transparent für den Client, weil es CMS-Systeme und so gibt, die einen Neustart der Datenbank nicht überleben und nee, das ist nicht so, der Client bekommt, also es kommt drauf an, wenn man zum Beispiel das mit PG Bouncer hier macht,
47:22
PG Bouncer kann man so einstellen, dass er die Verbindung erst, weil er da halt zwischen ist, sagt, okay, halte die Verbindung, dann wird das umgehändert und dann macht er das neu. Aber es kann sein, dass wahrscheinlich trotzdem der Client dann erst mal
47:43
sich neu verbinden muss und wenn er das nicht kann, dann ist es ein Problem. Also das ist dieses Rack, was Oracle im Endeffekt macht, wo halt dann auf dem Client versucht, der State zu sein, aber auch nur lesen, das kann Postgres bis jetzt nicht. Also normalerweise hat man da halt einen Verbindungsabbruch
48:02
und muss sich neu verbinden und die Anwendung, ich meine der Vorteil ist, man muss die Anwendung nicht neu konfigurieren, also hier ist jetzt der neue Host, aber die Anwendung sollte schon hoffentlich damit zurechtkommen, dass Postgres halt nicht immer da ist, oder man muss sie halt dann automatisch neu starten.
48:21
Okay, gut, Pacemaker ist wie gesagt mehr oder weniger der Standard, man benutzt virtuelle IPs, man muss aufpassen, dass man Fencing hat, also dass der Pacemaker, der nach einem Failover in der Lage ist, den alten Primary klar runterzufahren, dass es keinen Split Brain gibt,
48:41
und das macht man normalerweise über ein Stoneth Device, should you have a node in the head, also da gibt es verschiedene Treiber dazu, da sollte man auf jeden Fall aufpassen, dass das gut funktioniert. Generell gibt es verschiedene Möglichkeiten, das zu konfigurieren, früher hat man öfters Code Standby mit Shared Storage gemacht, über SAN oder über DRBD Replikation,
49:04
dann wird einfach das Postgres Datenverzeichnis geschwenkt und man macht einen Recovery beim Starten, aber das ist dann nicht diese Replikation, die ich vorhin gezeigt habe, und das ist auch synchron per Definition, weil es im Endeffekt der gleiche Datenbestand ist, der geschwenkt wird. Die andere Möglichkeit ist eine Replikation über ein Master Slave Set,
49:23
also das ist jetzt die Pacemaker Terminologie über lokale Storage, und da wird dann eben die Postgres Streaming Replikation verwendet, da wird dann der Standby automatisch promoted, wenn der Primary wegbricht, und es gibt aber kein automatisches Recovery des alten Primaries, das muss man dann manuell machen,
49:41
und da kann man es synchron oder asynchron machen, sollte man halt aber aufpassen, weil man halt typischerweise einen Zwei-Knoten-Cluster, und wie gesagt, da ist das Problem, bei zwei Knoten synchron, oder dieser Ressourcenagent hat dann allerdings die Möglichkeit, in dem Fall den neuen Primary dann auf so umzustellen,
50:02
dass es asynchron ist und der nicht auf den anderen wartet und das dann weitergeht, aber da muss man eben auch aufpassen, das ist typischerweise zwei Knoten und kein automatisches Scale-Out. Ich habe jetzt irgendwie ein Verständnisproblem in meiner Hotelvorstellung. Wenn ich hochverfügbarer Teilen ab will, dann will ich sie durchgehen, entlaufen wir mit A.
50:21
Das heißt, ich reiche mir damit, dass in der Datenbank zum Beispiel auch EDL gemacht wird, das heißt, ich muss die physische Replikation nehmen. Die physische Replikation ist aber eine, wo der Slave oder Standby per Definition gar keine Kommandos akzeptiert nach dem Schaubild von ihm?
50:42
Entschuldigung, keine schreibenden Kommandos. Ach so, keine schreibenden? Okay, und das muss sich ja dann, wenn der jetzt plötzlich der aktive Knoten werden soll, ganz radikal drastisch ändern? Die Frage ist, was ist, man benutzt physikalische Replikation und der Standby kann keine schreibenden Transaktionen machen
51:04
und das muss sich ändern bei einem Failover und das ist eben der, der automatisch promotet. Also das macht Pacemaker, der Ressourcenagent merkt dann, ohje, der Master ist weggebrochen und ich mache einen Promoter. Vielleicht haben wir Glück und ich kann das zeigen.
51:22
Ups, das war schlecht.
51:41
Das ist jetzt hier der Output von CRM-ON,
52:00
also Pacemaker-Output von einem 2-Knoten-Cluster und das ist eigentlich ein Testsystem für ein Kundenprojekt im Endeffekt und man sieht hier, der hat Score 1000, das ist der Master, die Node H1 DB2 und 100 ist der Standby und wenn ich jetzt über diesen hier das Ausschalten zwinge,
52:53
sollte im Prinzip der Standby- oder Pacemaker merken, okay, der ist weg und macht jetzt einen Promoter
53:01
und der Standby ist jetzt der Primary und die andere Dinge ist offline. Und dann kann man schreibend normal drauf zugreifen. Ob jetzt die letzte Transaktion weg ist oder nicht, ist eben dann die Frage, ob es asynchron oder synchron ist. Wenn man den jetzt wieder hochfährt,
53:22
dann muss man eben aufpassen, dass der nicht eben hochfährt, deswegen, wenn der halt jetzt den Pacemaker nur merkt, oh, der reagiert nicht mehr, dann würde ich ihn erstmal forciert ausschalten und dann muss man als Admin eingreifen und schauen, dass der nicht einfach so wieder hochfährt. Dieser Ressourcenagent schreibt dann auch so eine Logdatei rein,
53:42
wenn es geht, damit man das nicht macht. Und dann gibt es, es gibt aber inzwischen seit 9, 4 oder 9, oder seit 9, 6, spätestens in, ist es ein Upstream, also im Postkast drin, aber es gibt es als Projekt, sogenanntes PG Rewind heißt es, was man auf dem alten Stand Primary starten kann, der sich verbindet mit dem neuen Primary
54:01
und alle Änderungen, die er neu inzwischen gemacht hat, anwendet und dann kann man den wieder als Standby benutzen. Die andere Alternative, die früher war, ist halt, alles neu machen, als Standby neu aufsetzen. Das ist dann natürlich, je nachdem, wie viel Datum man hat, ein Problem.
54:23
Okay, Moment. Entschuldigung, wenn man einfach hochfährt, was ist dann, ja, man muss eben dann aufpassen, dass das nicht passiert,
54:42
weil sonst im Prinzip, je nachdem, man macht dann Crash Recovery und wenn da nichts sich geändert hat, dann, oh je, dann wären dafür schreibende Verbindungen verfügbar und Clients würden eventuell noch auf ihn zugreifen,
55:01
immerhin Pacemaker hat ja dann die Virtual IP geändert, aber theoretisch könnte man dann Änderungen machen und die beiden wären ausversinkt. Deswegen sollte man halt immer aufpassen, das wäre halt eine Split-Brain-Signale.
55:29
Das versuche ich mal zu nehmen. Gut, wir haben jetzt nicht mehr besonders viel Zeit,
55:45
insofern ist jetzt leider, kann ich noch schauen, ob ich noch ein paar Punkte zu Pacemaker,
56:09
was wir so in der Vergangenheit bei Kunden als wichtige Punkte haben. Gut, die Slides, ich werde die Slides hochladen oder der Forstkontroller für mich stellen, kann sich jeder anschauen, aber wichtig ist,
56:20
dass man hier die Abhängigkeiten der Virtual IPs und Postgres richtig macht, damit Pacemaker bei einem Failover nicht zuerst irgendwie die Virtual IP runterfährt und Postgres dann Probleme hat beim Runterfahren. Man muss die Sonneproduktoren immer nur auf dem anderen Knoten haben,
56:40
das kann man damit einmachen, und man muss die Master-Slave-Virtual-IPs entsprechend so machen, dass die dann auf den richtigen Knoten sind. Das Wichtigste bei Pacemaker sind immer die Timeouts, dass man die Timeouts richtig setzt und dass man das auch testen kann, am besten halt unter Last, wenn das möglich ist.
57:03
Gut, jetzt vielleicht noch ein zweites Kundenbeispiel, das wäre jetzt mit dem PGSQL-Agenten, das haben wir so umgesetzt, 2-Knoten-Cluster, das ist so das übliche Ding, IPMI-Fencing, lokale Datenhaltung über Streaming Replication,
57:22
automatisches Standby, das Problem hierbei ist, wir hatten das mit 14.04 gemacht, und leider unter 14.04 hat ein Problem mit den Ressourcen-Agenten, das als Information, da muss man aufpassen, die passen nicht zusammen, es gibt einen Patch, aber leider hat Ubuntu es noch nicht geschafft, das in die Distribution einzukriegen.
57:41
Ja, da war eine Frage.
58:02
Die Frage ist, wie lange wird das sehr aufwendig, also jetzt Pacemaker konkret oder Replication im Allgemeinen? Ich weiß gar nicht, was ich da machen soll. Vorhin war ein Master-Master-Replication-Beispiel, jetzt nehme ich einfach das, also ich bin voll ins Verwirr.
58:20
Also ich habe kein Beispiel mit Master-Master-Replication gemacht. Das ist immer Master-Standby-Replication. Man kann halt schreibend auf den Standby eventuell zugreifen, aber man sollte es nicht, weil dann eben keine Sicherheit besteht, dass man sich nicht gegenseitig die Änderungen überschreibt.
58:41
Es gibt keine Konflikt-Resolution oder Sequenzen werden nicht repliziert. Also man sollte immer nur auf den Primary schreiben bis jetzt, oder es sei denn, man nimmt dieses BDR-Projekt, was ich erwähnt habe, oder ein anderes Projekt. Ansonsten, wie kompliziert ist das? Gut, Pacemaker gut aufzusetzen, das ist halt eine Frage des Testens.
59:05
Das Stat-Tab ist nicht so furchtbar riesig kompliziert, aber man muss halt schauen, dass es da halt keine Probleme mit Timeouts gibt. Prinzipiell ist das natürlich schon ein bisschen Arbeit,
59:22
aber weil es halt so Replikation selber ist, inzwischen nicht mehr sehr schön aufzusetzen. Und, eine Sekunde, ich meine, was es halt inzwischen gibt, sind so Sachen wie dieses Patroni, was jetzt leider hier nicht mehr gut erklären kann. Die dann in der Lage sind, so was cloud-native zu machen,
59:46
in die Konfigurationen des Setup automatisiert sind und dann auch automatisch Primaries sich aussuchen. Ich kann schauen, dass vielleicht wenigstens das als Übersicht noch machen.
01:00:10
Patroni wäre so ein Beispiel, was auch Kunden von uns inzwischen verwenden, für drei oder mehr Cluster dann allerdings Noten, das benutzt Raft und etcd, um halt zu schreiben,
01:00:22
ok, das ist der Master, der hat dann Time to Live und macht eine Leaderelection und der weiß dann, wo der Postgres Cluster ist und was die Standbys sind und wie man das machen kann, macht im Falle eines Failovers eine Leaderelection und der alte Master kann dann als neuer Standby wieder eingefügt werden und das vom operativen
01:00:44
Handling dann vielleicht einfacher. Da ist halt dann, man muss halt dann zusätzlich noch Tooling draußen rum machen, dass dann eben neue Knoten drin sind, das macht Zalando über ConfD zum Beispiel, was dann die HAProxy automatisch updatet, also ConfD schaut dem
01:01:00
etcd nach, was ist, auch inzwischen wird das in Kubernetes integriert, das dann automatisch, die hochgefahren werden, ConfD dann sieht, da ist was Neues, wird ihr HAProxy aufgemacht, HAProxy schaut dann, das ist so ein Rest API Endpunkt, der Patroni bereitstellt, ist es ein Master, ist es ein Standby und dementsprechend wird dann der Climb dann
01:01:22
gemacht. So, das dazu, aber jetzt ist für mich dann die Zeit vorbei. Insofern, wenn noch Fragen sind, stehe ich auch gerne noch draußen zur Verfügung, aber leider waren es halt ein bisschen viele Zwischenfragen, deswegen bin ich nicht ganz durchgekommen. Aber danke trotzdem für die Aufmerksamkeit.