Warum Postgres Mastercards Geheimnis für null Ausfallzeiten ist
Mit freundlicher Genehmigung von EDB – Übersetzt aus dem Englischen (Why Mastercard’s Secret to Zero Downtime is Postgres | EDB (enterprisedb.com)
Mastercard setzt seit Jahren eine Reihe von Datenbanktechnologien darunter Oracle, MySQL, Microsoft SQL Server, Cassandra, Hadoop, DB2 und PostgreSQL ein. In meiner Rolle als Lead BizOps Engineer unterstütze ich das Zahlungsgateway, das Mastercard 2014 übernommen hat. Mit ihm kam Postgres, ein angenehmer Zufall für das Unternehmen.
Die bereits aktive Nutzung von Postgres trug dazu bei, die Disaster-Recovery-Strategie von Mastercard schnell zu verbessern. Zu dieser Zeit war die binäre Streaming-Replikation von Postgres das wichtigste Werkzeug dafür. Das funktionierte zwar gut, aber es stellte sich immer die Frage: “Wie können wir das besser machen?”
Wie man null Ausfallzeiten erreichen kann
Mastercard hatte mit zwei großen Problemen zu kämpfen: die Zeit, die für die Umstellung der Verarbeitung auf den Disaster-Recovery-Seite benötigt wurde, und die Methode zur Durchführung von Wartungsaufgaben auf den Servern, wie z. B. Vakuumfüllung, Neuindexierung usw. Eine Betriebszeit von 99,999 % war eine Mindestanforderung des Unternehmens, daher waren diese Probleme inakzeptabel.
Mit Postgres 9.4 kam die logische Replikation, und mit der logischen Replikation kam die Multi-Master-Replikation.
Postgres: Eine wirtschaftliche Notwendigkeit
Nach der Einführung von xDB MMR wurden die Vorteile sehr schnell erkannt. Vor allem der Wechsel zum DR-Standort wurde nicht nur schneller, sondern auch zuverlässiger.
Aber xDB MMR bot mehr als nur eine verbesserte DR-Lösung. Es lieferte auch ein Datenmigrations-Tool, das sich als unschätzbar erwies, als Mastercard Daten zwischen den Kontinenten transportieren musste, um die sich ständig ändernden Bestimmungen und Vorschriften in Bezug auf den Ort, an dem personenbezogene Daten gespeichert werden können, zu erfüllen.
Einer der großen Vorteile der logischen Replikation gegenüber der binären Streaming-Replikation ist ihre Fähigkeit, Daten zu filtern. Ein weiterer Vorteil ist, dass der Postgres-Zielserver mit Funktionen und Triggern konfiguriert werden kann, um die Daten beim Schreiben in die Zieldatenbanktabellen weiter zu manipulieren.
Für Mastercard war dies sehr nützlich, als man mit xDB Teilmengen von Daten über Kontinente hinweg migrieren wollte, um den sich ändernden Anforderungen der Aufsichtsbehörden gerecht zu werden.
Die xDB-Filterung verhinderte, dass Daten den Quellkontinent verließen, die dort beheimatet waren. Darüber hinaus ermöglichten Postgres-Trigger die nahtlose Anwendung zusätzlicher Geschäftslogik auf die Daten, während diese auf den Zielserver geschrieben wurden. xDB wurde als Echtzeit-Datenmigrationstool eingesetzt und diese Datenmigrationsstrategie war sehr erfolgreich.
“Postgres funktioniert einfach.”
In Zukunft wird Mastercard die Möglichkeit nutzen, mit xDB MMR Zahlungen in mehreren Rechenzentren gleichzeitig zu verarbeiten und die Standorte synchron zu halten. Es werden einige kleinere Änderungen an der Anwendung erforderlich sein, und es werden viele Tests durchgeführt werden müssen, insbesondere im Bereich der Datenkonflikte.
Diese Aktualisierungen und Korrekturen haben gezeigt, dass die Migration zu Postgres eine wirtschaftliche Notwendigkeit war. Weil so viele Kreditkartentransaktionen pro Sekunden stattfanden, musste die Failover-Zeit reduziert werden. Mit Postgres konnten wir wirklich “Null Ausfallzeit” zu bieten. Es funktioniert einfach!
