Welche Methoden oder Tools ermöglichen die kontinuierliche Bereitstellung von Datenbanken?

Continuous Delivery oder Continuous Deployment von Infrastruktur und Code ist im Vergleich zu den gleichen Ansätzen für Datenbanken, insbesondere RDBMS, vergleichsweise einfach. Code und Infrastruktur werden sich nach Abschluss der Bereitstellung nicht ändern oder weiterentwickeln. Den Datenbanken werden jedoch neue Daten hinzugefügt, wodurch die Daten erstellt werden, sofern das Schema keine inhärent veränderlichen Komponenten sind.

Mir ist bewusst, dass es Verfahren gibt, bei denen nur Datenbankobjekte, dh Tabellen und Spalten, hinzugefügt, jedoch nie geändert oder entfernt werden. Diese rein additive Methode zur Annäherung an Datenbankschemata bietet den Vorteil, dass Schemata abwärtskompatibel sind, was zu einer immer höheren Komplexität führt Schemata.

Ebenso gibt es Produkte wie Flyway und Ready Roll, die das Schreiben von Migrationen unterstützen, die zwischen Versionen eines Schemas geschrieben werden sollen.

Welche anderen Methoden und Tools stehen derzeit zur Verfügung, um die kontinuierliche Bereitstellung von Datenbankschemata in einer Produktionsumgebung zu ermöglichen, in der die Datenintegrität ein Problem darstellt?

Pramod Sadalage und Scott Ambler haben ein Buch Refactoring Databases: Evolutionary Database Design geschrieben , das eine unglaublich solide Einführung in das Thema DBs in einer CD-Organisation / einem CD-Team bietet.

Die Herausforderungen

Mir ist bewusst, dass es Verfahren gibt, bei denen nur Datenbankobjekte, dh Tabellen und Spalten, hinzugefügt, jedoch nie geändert oder entfernt werden

Bei einem Unternehmen, für das ich gearbeitet habe, entsprach ein rollierendes Fenster mit Rohdaten etwa 6 Monaten und verbrauchte 10 TB. Die Daten wurden dann in ein RDBMS-Format verarbeitet, das 6 TB nutzbarer Daten kostete, was etwa 10 Jahren meldepflichtiger Daten entsprach. Der Punkt ist, dass diese Art von Praktiken auf der Skala einfach nicht praktikabel sind. Speicher ist teuer - wahrscheinlich der größte Rechenaufwand. Dies bietet einige interessante Herausforderungen:

1. Backups - die innodb-Plugins sind großartig, aber die Backup-Zeiten für so viele Daten sind einfach nicht so praktisch
2. Wiederherstellungszeiten - für große Datasets - insbesondere, wenn Sie eine Replikation benötigen, um nach einer Wiederherstellung den Betriebszustand wiederherzustellen, kann dies Tage oder sogar Wochen dauern
3. Erstellen / Einfügen neuer Instanzen - Bei der Arbeit, die Sie möglicherweise in dev / test ausführen, handelt es sich häufig um ETL-Jobs (Extrahieren, Transformieren und Laden) für Ihr Dataset. Diese müssen mithilfe von QS-Testeinheiten validiert werden. Dies muss jedoch zerstörungsfrei erfolgen, damit der ursprüngliche Produktionsdatensatz erhalten bleibt. Während einer Katastrophe sind Sie möglicherweise bereit, eine lange Wiederherstellungszeit in Kauf zu nehmen, wenn Sie verstehen, dass Sicherungen eine Versicherungspolice sind und sie vermieden werden sollen. Der DevOps-Entwicklungsworkflow erfordert im Wesentlichen, dass Sie in der Lage sind, eine Wiederherstellung durchzuführen oder Kopie Ihrer Daten in regelmäßigen Abständen (möglicherweise mehrmals am Tag)
4. Kapazität - Das Herumschleudern so vieler Daten auf der eben beschriebenen Skala kann sehr E / A-intensiv sein. Sie müssen nicht nur die in den Abschnitten 1-3 beschriebenen Probleme beheben, sondern auch so vorgehen, dass keine Ausfälle oder Leistungseinbußen bei Ihren Produktionssystemen auftreten.

Während die obigen Überlegungen bei kleineren Maßstäben möglicherweise kein Problem darstellen, werden diese bei größeren Maßstäben zu großen Problemen. Aus diesem Grund ist es äußerst wichtig, dass Sie Ihre Anforderungen definieren und die Größe Ihres Datensatzes vorhersagen.

Anforderungen definieren

Daher müssen Sie mehrere Anforderungen definieren:

1. RTO - RTO oder Restore Time Objective für Backups sind einer der wichtigsten Treiber für Datenbank-Backup-Lösungen. Während es auf den ersten Blick für die meisten anderen Probleme möglicherweise nicht relevant erscheint, wird es äußerst relevant, wenn Sie gefragt werden, was passiert, wenn ich meine Sicherungslösung zum Erstellen oder Einspielen neuer Instanzen verwendet habe. Im nächsten Abschnitt werde ich einige Techniken dafür behandeln.
2. RPO - RPO oder Wiederherstellungspunkt Ziel für Sicherungen definiert A) wie weit zurück Sie wiederherstellen können (Minuten, Stunden, Tage, Wochen, Monate oder Jahre) B) das Sicherungsintervall auf verschiedenen Ebenen und C) wie detailliert Sie wiederherstellen können . Beispielsweise wird bei E-Mail-Datenbanken häufig nach Backups auf Nachrichtenebene gesucht, bei denen eine bestimmte E-Mail wiederhergestellt wird. In ähnlicher Weise können Sie feststellen, dass Daten, die sich über einige Tage erstrecken, völlig unbrauchbar sind - es macht also keinen Sinn, ein Jahr später wiederherzustellen.
3. Größe Ihres Datensatzes - Dies ist wichtig, da für eine 1-MB-Datenbank Ihre RTO mit den meisten Sicherungsprodukten und -lösungen erzielt werden kann. Bei einer 10-TB-Datenbank werden Sie jedoch feststellen, dass eine vollständige Sicherung auf Zeilenebene auf LTO 3-Band Ihre RTO wahrscheinlich nicht erreicht und Ihr RPO beeinträchtigen kann, da Sicherungen beginnen, Ihr Sicherungsfenster zu überschreiten. Sie können nicht genau nur einen mysqldump für dieses große Dataset ausführen, sondern könnten dies wahrscheinlich auch für die 1-MB-Datenbank tun.
4. Datenbankkonsistenz - Ein letztes Kriterium für die kontinuierliche Bereitstellung, die Zuverlässigkeit der Site, die Skalierbarkeit und die Hochverfügbarkeit bei der Arbeit mit Datenbanken ist Ihr Bedürfnis nach Konsistenz (oder ein Mangel daran). Es gibt drei Grundtypen: Sofortkonsistenz, Just-In-Time-Konsistenz (JIT) und Endkonsistenz

Zusätzlich zu den oben genannten wichtigen Überlegungen müssen Sie auch die Lizenz- und Supportanforderungen (Open Source oder Closed Source; Inhouse-Support, Support von Drittanbietern oder Anbietersupport) sowie die Anwendungs- / Sprachanforderungen berücksichtigen (die Konnektoren für viele Datenbanken können wichtig sein) Ihre App wurde kompiliert? Haben Sie Zugriff auf den Quellcode? Können Sie sie erneut kompilieren oder wird sie von einem Anbieter bereitgestellt? Oder wird sie in einer interpretierten Sprache ausgeführt?) Politische Anforderungen (Traut Ihre Organisation nur Oracle? Hassen sie Oracle? Trauen sie MySQL nicht? Wie stehen Sie zu MariaDB oder Postgres?) Und der Datenbank-Engine (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Sowie den historischen oder Kompatibilitätsanforderungen (wir haben PL / SQL für anderthalb Jahre unseres Codes verwendet) ist in die Orakelmaschine eingebaut! Wie könnten wir jemals auf MariaDB portieren?!?)

All diese Dinge wirken sich (erheblich) auf die Tools aus, die Ihnen zur Verfügung stehen.

Einige Optionen für die interne Datenverwaltung

Hinweis: Das Folgende ist in keiner Weise erschöpfend, und andere SE-Benutzer sollten zusätzliche Vorschläge unterbreiten.

Lassen Sie mich Ihnen mit den allgemeinen Überlegungen einige Techniken und Technologien zur Verfügung stellen, mit denen Sie die oben genannten Probleme angehen können. Fragen Sie sich zunächst, ob Sie wirklich ein RDBMS benötigen oder ob unstrukturierte Daten mit etwas wie Hadoop, CouchDB oder sogar objektorientiertem Speicher (etwas wie Swift) eine Option sind.

Zweitens sollten Sie eine Cloud-basierte Lösung in Betracht ziehen. Dies lagert einige dieser Kopfschmerzen aus und überlässt die komplizierten Probleme hochqualifizierten (und bezahlten) Personen. Auf der Skala können Sie jedoch feststellen, dass sich dies wirklich negativ auf Ihr Budget auswirkt (Cloud-Anbieter erzielen damit einen Gewinn, und auf einer bestimmten Skala können Sie es sich leisten, diese Experten selbst zu beschäftigen) oder wenn Sie unter bestimmten Sicherheits- oder politischen Bedingungen arbeiten Anforderungen (lesen Sie: Wir können keine Clouds erstellen) betrachten einen hybriden NFS / FibreChannel Filer. Die meisten dieser Filer, wie die von NetApp, Pure Storage und Tegile, unterstützen eine Delta-basierte Snapshot- und Cloning-Technik, die sehr nützlich sein kann, um A) Backups zu erstellen, B) Backups wiederherzustellen und C) neue Backups zu erstellen.

An dieser Stelle muss ich beachten, dass ich kein Backup- und Speicherexperte bin. Daher gab es einige Teile dieses Problems, die ich nicht ganz lösen konnte, bevor ich mich anderen Problemen (und grüneren Weiden) zuwandte.

Mit diesen Produkten können Sie jedoch differenzielle Snapshots unter Ihrer Datenbank erstellen. Sie müssen ein Skript für eine vollständige "Sperrtabelle mit Lesesperre" für eine Ihrer Datenbankinstanzen erstellen (ein schreibgeschützter Slave wird empfohlen) und Ihre Binlog-Position oder GTID sichern. Wenn Sie dies jedoch tun, können Sie dies für diese Filer tun Verwenden Sie diese Snaps, um neue Instanzen Ihrer Datenbank zu erstellen. Sie möchten Binlogs auf einer separaten Partition ablegen und nur Ihre Datenbankdaten auf diesen Partitionen ablegen. Sobald Sie dies getan haben, können Sie diese Partitionen klonen (auf NetApps wird dies als " FlexClone " bezeichnet).

Dies liegt daran, dass der Filer für jeden gelesenen Block bestimmen muss, ob sich die Daten im eingefrorenen ursprünglichen Snapshot oder im Delta befinden. Bei Volumes / Stores mit mehreren Snapshots muss dies möglicherweise mehrmals überprüft werden. Sie können dies umgehen, indem Sie die Daten aktualisieren (dh Ihren Snapshot verwerfen und in regelmäßigen Abständen erneut klonen - was für eine gute kontinuierliche Bereitstellungsumgebung natürlich und organisch vorkommen kann) oder indem Sie das Volume dauerhaft aufteilen (in der NetApp-Terminologie als "Flex Split" bezeichnet) ), was einen Moment dauern wird, um die Deltas dauerhaft aufzulösen und ein völlig neues und getrenntes Volumen zu schaffen.

Diese Delta-Klone haben den zusätzlichen Vorteil, dass Sie weniger Speicherplatz benötigen. Sie können mehrere Klone oder Instanzen Ihrer Produktionsdatenbank erstellen, um sie zu entwickeln, zu testen und zu validieren. Wenn Sie nur eine Kopie Ihres großen Datensatzes plus der (voraussichtlich) kleinen Deltas aufbewahren, reduzieren Sie Ihre gesamten Speicherkosten und Ihren Platzbedarf.

Der einzige Trick dabei ist, dass dies möglicherweise keine vollständige Backup-Lösung darstellt, da sich das "Backup" immer noch auf Ihrem Filer befindet. Zu diesem Zweck müssen Sie möglicherweise einen Snap Mirror verwenden, der Daten (mithilfe der Rsync-Technologie) zwischen Filern und sogar Datencentern spiegelt, oder eine integrierte Sicherungslösung verwenden, mit der Sie einen Ihrer Delta-Snapshots oder einen Backup auf Band erstellen können Flex-Clone.

Dies hat jedoch einen großen Nachteil: Alle Ihre Daten - Entwickler, Test und Produkt - verwenden immer noch E / A auf demselben Filer und Speicherkopf. Abhilfe Ziehen Sie in Betracht, eine Slave-Datenbankinstanz auf einem zweiten Filer zu erstellen, der der Ausgangspunkt für Ihren Test- und / oder Entwickler-Filer sein kann, oder verwenden Sie einen Load Balancer / Application Delivery Controller für Ihre Anwendungsebene, um Produktionsanforderungen in Ihre zu spiegeln Testumgebung (en) (und / oder Entwicklungsumgebung). Dies hat den zusätzlichen Vorteil, dass der Produktdatenverkehr in Ihre QS / Test-Umgebung geworfen wird, bevor Probleme, die möglicherweise nicht sofort bemerkt werden, in die Produktion übernommen werden. Anschließend können Sie Ihre Protokolle basierend auf dem Produktionsdatenverkehr und dem Benutzerverhalten auf Fehler überprüfen.

Dies sollte es Ihnen dann ermöglichen, mit wenigen Skripts ganze (und große) Datasets programmgesteuert für die Verwendung mit kontinuierlichen Bereitstellungsmethoden zu erstellen und zu zerstören.

Skalierbarkeit und hohe Verfügbarkeit

Während Sie nach einer kontinuierlichen Bereitstellung gefragt haben, geht es bei DevOps nicht nur um eine kontinuierliche Bereitstellung. Ich werde daher einige Aspekte in Bezug auf Redundanz, Skalierbarkeit und Hochverfügbarkeit berücksichtigen .

Ich erwähnte, JIT, sofortige und mögliche Konsistenz. Hier kommen verschiedene RDBMS-Engines ins Spiel. Eine spätere Konsistenz ist relativ einfach, indem einfach die zirkuläre asynchrone Replikation konfiguriert wird. Dies kann jedoch zu einigen Kollisionen führen. * (Was passiert, wenn Ihre Anwendungsebene Daten auf einer Seite des Clusters und auf der anderen Seite des Clusters aktualisiert, bevor die Replikation abgeschlossen ist?) Um eine sofortige Konsistenz zu erzielen, sollten Sie sich Galera Cluster ansehen, das die synchrone Replikation erzwingt verursacht Skalierbarkeitsprobleme (wie werden Sie auf Ihren Disaster Recovery-Standort replizieren oder den Lastausgleich geografisch vornehmen, ohne dass aufgrund von Verzögerungen bei der Übertragung auf Netzwerkebene eine erhebliche Latenz auftritt?). Aber dies scheint das Schlimmste von beiden Welten zu sein.

In der Regel benötigen die meisten Benutzer jedoch keine vollständig synchrone Replikation - dies ist normalerweise nur für sehr spezielle (und exotische) Umgebungen mit hohem Schreibaufwand erforderlich, in denen Multi-Master mit Tabellen-Sharding erforderlich ist. Die meisten Apps können die Just-In-Time-Konsistenz mithilfe eines Datenbank-Proxys verarbeiten. Zum Beispiel überwacht ScaleArc den Replikationsstatus und verfolgt, wo gerade geschriebene Daten abgelegt wurden (um nachfolgende Leseanforderungen zu senden, bis die Replikation aufgeholt hat), um die Just-In-Time-Konsistenz und das Erscheinungsbild zu gewährleistender Datenbankkonsistenz. ScaleArc ist mit Postgres, MySQL, MariaDB, Oracle und MSSQL kompatibel und kann reguläre Ausdrücke verwenden, um Ihre Datenbanken für Anwendungen zu partitionieren, die keine Shard-Schlüssel verwenden können. Es verfügt auch über eine robuste REST-API, mit der Ihre Konfigurationsverwaltungssoftware interagieren kann - und das Support-Team ist hervorragend

Vielleicht möchten Sie auch eine kostenlose Alternative in Betracht ziehen, MaxScale, die vom MariaDB-Team für MariaDB entwickelt wurde. Es fehlen jedoch die GUI und einige der Caching-Funktionen von ScaleArc.

Schließlich sind MySQL Fabric (und das In-RAM-Only-MySQL-Cluster - wenn Sie sich so viel RAM leisten können) andere Potenziale - insbesondere mit MySQLs neuem Proxy. Dies kann die Skalierbarkeits- und Redundanzkomponente für Ihre Umgebung bereitstellen.

Postgres und Oracle sollten über die Replikations- und Sharding-Funktionen verfügen, die Sie benötigen. ScaleArc ist jedoch gut geeignet, wenn Sie einen Proxy benötigen.

Letztendlich bilden alle diese Komponenten eine hochflexible Umgebung, die für eine kontinuierliche Bereitstellung und Entwicklung geeignet ist, wenn Sie eine cloudbasierte Umgebung nicht einfach verwenden können und Ihr Cloud-Anbieter die oben genannten Probleme für Sie lösen kann.

Wir verwenden Flyway bei der Arbeit, um Postgres-Schemata in der App zu verwalten, und Pillar, um Cassandra-Schemata zu verwalten. Wir haben es am besten gefunden, wenn die App ein eigenes Schema verwaltet.

Wir hatten eine schreckliche Erfahrung mit ansible verwalten Schemata , bevor die Anwendungen ihre eigenen Schemata verwaltet.

Ich würde behaupten, ein Tool allein würde nicht wirklich helfen, wenn Sie die Schema-Verantwortung nicht auf das Anwendungsteam verlagern.

Bei der Arbeit verwenden wir Liquibase oder Flyway , wobei das Anwendungsteam für die Erstellung der Änderungssätze verantwortlich ist.

Damit vermeiden Sie einen rein additiven Weg.
Jede Anwendung muss mit ihrer Vorgängerversion kompatibel sein. Wenn eine Änderung des Schemas vorgenommen werden muss, integriert die Anwendung eine neue Spalte in das Schema, schreibt darauf und liest und schreibt weiterhin von / in die vorherige Spalte (unter Berücksichtigung der folgenden Bedingungen) vorherige Version, um die gleichen Daten zu haben).
Die nächste Version der Anwendung kann die Aktualisierung der alten Spalte beenden, und nur die dritte Version kann die jetzt nicht verwendete Spalte entfernen.

Natürlich sind regelmäßige Backups erforderlich, falls etwas schief geht.
Eine angemessene Datenmenge, die bei Integrationstests Probleme verursachen kann, um sie in der Produktion zu vermeiden, ist ebenfalls eine gute Idee. Im Idealfall erhalten Sie eine anonyme Teilmenge der Produktionsdaten.

Wir verwenden bei unserer Arbeit Liquibase und ich werde mich dafür stark machen. Es wird auch von unserem QA-Tool QASymphony verwendet .

Wir verwenden es intern für MSSQL- und Oracle-Datenbanken, und QASymphony verwendet es für beide postgres + mysql-Instanzen.

Um diese Frage im Kontext einer Mainframe-Umgebung und speziell für DB2-Datenbanken zu beantworten, stehen normalerweise zwei häufig verwendete (nicht kostengünstige ...) Alternativen zur Auswahl:

• Objektverwaltung für DB2 von BMC. Hier einige Details dazu (Zitat von der verlinkten Seite):

  Das Vornehmen von Änderungen an Objekten in Ihrer Datenbank - oder sogar das Ausführen von Routineaufgaben in der Verwaltung - kann schwierig und riskant sein. Sie müssen Dutzende von Aufgaben nachverfolgen, und ein einziger Fehltritt kann sich katastrophal auf die Verfügbarkeit und die Datenintegrität auswirken. Mit BMC Object Administration für DB2 11, einer Sammlung von Tools, die Ihnen dabei helfen, Aufwand und Risiko zu reduzieren, können Sie:

  • Reduzieren Sie den Zeitaufwand für die Verwaltung komplexer und unterschiedlicher DB2-Umgebungen.
  • Automatisieren Sie Routineaufgaben während des gesamten Anwendungslebenszyklus, um die Integrität zu verbessern.
  • Verbessern Sie die Produktivität mit vereinfachter DB2-Katalognavigation und Änderungsverwaltung.
  • Verbessern Sie die Anwendungsverfügbarkeit, indem Sie Änderungen und Wartungsarbeiten mit minimalen Ausfällen durchführen.

• DB2 Administration Tool für z / OS von IBM.

  Es vereinfacht die komplexen Aufgaben, die mit der sicheren Verwaltung von DB2-Objekten und -Schemata während des gesamten Anwendungslebenszyklus verbunden sind, bei geringstmöglichen Auswirkungen auf die Verfügbarkeit.

  • Ermöglicht Benutzern das schnelle und einfache Navigieren im DB2-Katalog
  • Erstellt dynamische SQL-Anweisungen und führt sie aus, ohne die genaue SQL-Syntax zu kennen
  • Verwaltet und verfolgt Änderungen an DB2-Objektdefinitionen, um potenzielle Konflikte vor der Ausführung zu lösen
  • Hilft beim Erstellen von DB2-Befehlen zur Ausführung für Datenbanken und Tabellen
  • Ermöglicht Benutzern das Erstellen, Ändern, Migrieren, Löschen und Reverse Engineering von DB2-Objekten
  • Erstellt und führt Dienstprogrammaufträge aus, sodass Benutzer die Vorteile von LISTDEFs und TEMPLATEs nutzen können, um die Produktivität zu steigern

Integration mit SCM-Tools

Vor einiger Zeit wurde ich von einem Kunden aufgefordert, die BMC-Alternative tatsächlich in seinen SCM-Lebenszyklus zu "integrieren" (verwaltet von SERENA ChangeMan ZMF ). Die Idee hinter einer solchen Integration ist: " Betrachten Sie unser DB2-DBA-Team (das Arbeiten mit DDLs) als einen Sonderfall eines Entwicklungsteams, das versehentlich einen exotischen Editor (das BMC-Tool) verwendet, um den zu migrierenden Code (DDL) zu erstellen. "

Die einzige (aber echte !) Herausforderung bei dieser Integration bestand darin, die "Neustartfähigkeit" zu verbessern, was einer der Hauptvorteile eines solchen DBA-Tools ist:

• Neustartfähigkeit bedeutet, dass, wenn dieses DBA-Tool seine Arbeit erledigt (über manchmal lange laufende Jobs, je nach Art der zu erledigenden Arbeit), unerwartete Dinge passieren können (Deadlocks, Zeitüberschreitung usw.).

• Wenn eines dieser Probleme auftritt und Sie nicht von Ihrem Backup aus neu starten möchten (bevor Sie begonnen haben), erwartet das DBA-Tool, dass Sie von dem (Prüf-) Punkt an neu starten, an dem Probleme aufgetreten sind (und von wo aus Sie möchten, dass alles erneut ausgeführt wird).

• Besser noch (oder sollte ich "noch schlechter" sagen?), Wenn ein Neuling im DBA-Tool nicht wirklich weiß, wie er von einem solchen Prüfpunkt aus neu gestartet werden soll, und es einfach erneut versucht (von Anfang an), dann schlägt das DBA-Tool einfach fehl mit irgendeiner Art von Benutzerfehler. Und dies mit einem Hinweis wie " Bis Sie mir sagen, wie ich nach meinem letzten Scheitern vorgehen soll, lehne ich alles ab (um die Dinge nicht noch schlimmer zu machen) ".

• Letztendlich musste das SCM-Tool auch optimiert werden, um diese Neustartfähigkeit in dem verwendeten SCM-Tool zu implementieren. Eigentlich, um zu ermöglichen, dass es für den Neustart von fehlgeschlagenen SCM-Prozeduren verwendet wird (in der Regel im Zusammenhang mit Lieferungen an Ziel-Test- / Produktumgebungen), anstatt die fehlgeschlagenen SCM-Prozeduren erneut zu senden (wie in der Regel werden diese SCM-Tools in solchen Situationen wiederhergestellt) ).

Bonus: Nach Abschluss der SCM-Integration der BMC-Alternative entschied sich der Kunde, sein DBA-Tool auf die IBM-Alternative umzustellen. Und obwohl beide Alternativen nicht wirklich gleich aussehen, war die Auswirkung auf die SCM-Integration eher gering: Einige Aufrufe an die BMC-Alternative mussten lediglich durch entsprechende Aufrufe an die IBM ersetzt werden (bei einigen wiederverwendbaren SCM-Anpassungen) Alternative ... die (unter Verwendung der DevOps-Terminologie) durch Feature-Flags / Feature-Toggles implementiert wurde .