Hibernate: hbm2ddl.auto = update in der Produktion?

https://stackoverflow.com/questions/221379

03-07-2019
|

Frage

Ist es in Ordnung mit hbm2ddl.auto=update konfigurierten Hibernate-Anwendungen ausführen, um das Datenbankschema in einer Produktionsumgebung zu aktualisieren?

Lösung

Nein, es ist nicht sicher.

Trotz der besten Bemühungen des Hibernate-Team, können Sie einfach nicht auf automatische Updates verlassen in der Produktion . Schreiben Sie Ihre eigene Patches, überprüfen sie mit DBA, testen sie, dann gelten sie manuell.

Theoretisch, wenn hbm2ddl Update in der Entwicklung gearbeitet, sollte es auch in der Produktion arbeiten. Aber in Wirklichkeit ist es nicht immer der Fall.

Auch wenn es OK funktioniert, kann es suboptimal sein. DBAs bezahlt werden, dass viel für einen Grund.

Andere Tipps

Wir tun es in der Produktion, wenn auch mit einer Anwendung, die nicht unternehmenskritischen und ohne hoch bezahlte DBAs auf Personal ist. Es ist nur ein kleiner manueller Prozess, menschliches Versagen unterworfen ist - die Anwendung des Unterschied erkennen kann und das Richtige zu tun, und Sie haben vermutlich es in verschiedenen Entwicklungs- und Testumgebungen getestet.

Eine Einschränkung - in einer Cluster-Umgebung Sie können es zu vermeiden, da mehrere Anwendungen zur gleichen Zeit können kommen und versuchen, das Schema zu ändern, die schlecht sein könnte. Oder in einem Mechanismus gebracht, wo nur eine Instanz erlaubt ist, das Schema zu aktualisieren.

Hibernate Schöpfer discourage dabei in einer Produktionsumgebung in ihrem Buch "Java Persistence mit Hibernate ":

ACHTUNG: Wir haben Hibernate Benutzer gesehen versucht SchemaUpdate zu verwenden, um das Schema einer Produktionsdatenbank automatisch zu aktualisieren. Dies kann schnell in einer Katastrophe enden und wird nicht von Ihrem DBA erlaubt werden.

Überprüfen Sie heraus Liquibase XML für ein Changelog von Updates zu halten. Ich hatte es nie benutzt, bis dieses Jahr, aber ich fand, dass es sehr einfach zu erlernen und DB Revisionskontrolle / Migration / Change Management sehr narrensicher zu machen. Ich arbeite an einem Groovy / Grails-Projekt, und Grails nutzt Hibernate unter für alle seine ORM (genannt „GORM“). Wir verwenden Liquibase alle SQL-Schemaänderungen zu verwalten, die wir ziemlich oft tun, wie unsere App mit neuen Funktionen entwickelt.

Grundsätzlich halten Sie eine XML-Datei von Changesets, die Sie hinzufügen möchten, wie Ihr Anwendung entwickelt. Diese Datei wird in git gehalten (oder was auch immer Sie verwenden) mit dem Rest des Projektes. Wenn Ihre Anwendung bereitgestellt wird, überprüft es Liquibase Changelog Tabelle ist in der DB verbinden Sie so wird es wissen, was bereits angewendet wurde, dann gilt es intelligent nur, was Changesets wurden noch aus der Datei nicht angewendet. Es funktioniert absolut großartig in der Praxis, und wenn Sie es für alle Schemaänderungen verwenden, dann können Sie 100% sicher sein, dass Code, den Sie immer zu einem vollständig kompatibelen Datenbankschema verbinden kann Kasse und bereitstellen.

Die ehrfürchtige Sache ist, dass ich eine völlig unbeschriebene Blatt MySQL-Datenbank auf meinem Laptop nehmen, die App anwerfen, und sofort wird das Schema für mich einrichten. Es macht es auch einfach Schemaänderungen zu testen, indem diese auf einem lokalen Entwickler der Anwendung oder db Staging zuerst.

Der einfachste Weg, damit zu beginnen wäre wahrscheinlich nehmen Sie Ihre bestehende DB und dann verwendet Liquibase zu erzeugen, eine anfängliche baseline.xml Datei. Dann in der Zukunft können Sie nur daran anhängen und lassen Änderungen Schema liquibase Verwaltung übernehmen.

http://www.liquibase.org/

Hibernate hat die rechtlichen Hinweise setzen über keine automatische Updates in prod mit sich zu bedecken, wenn die Leute, die nicht wissen, was sie verwenden es in Situationen tun, wenn sie nicht verwendet werden sollte.

die Situationen Zugegeben, wo es sollte nicht stark outnumber diejenigen verwendet werden, wo es in Ordnung ist.

Ich habe es seit Jahren auf vielen verschiedenen Projekten eingesetzt und hatte noch nie ein einziges Problem. Das ist nicht eine lahme Antwort, und es ist nicht Cowboy-Codierung. Es ist eine historische Tatsache.

Eine Person, die sagt, dass „es nie tun in der Produktion“ eine Reihe von spezifischen Produktionsimplementierungen denkt, nämlich die, die er mit (seiner Firma, seine Industrie, etc.) vertraut ist.

Das Universum von „Produktionsimplementierungen“ ist groß und vielfältig.

Ein erfahrener Hibernate Entwickler weiß genau, was DDL aus einer gegebenen Mapping-Konfiguration führen wird. Solange Sie testen und validieren, was Sie erwarten in der DDL endet (in dev, qa, Inszenierung, etc.), Sie sind in Ordnung.

Wenn Sie viele Funktionen hinzufügen, automatische Schema-Updates kann eine echte Zeitersparnis.

Die Liste der Sachen Auto-Updates werden nicht handhaben ist endlos, aber einige Beispiele sind die Datenmigration, das Hinzufügen Nicht-Nullable-Spalten, Spaltenname ändert, etc, etc.

Darüber hinaus müssen Sie in Cluster-Umgebungen nehmen.

Aber dann wieder, wenn Sie all diese Dinge wissen, würden Sie nicht diese Frage sein. Hmm. . . OK, wenn Sie diese Frage stellen, sollten Sie warten, bis Sie viel Erfahrung mit Hibernate und Auto-Schema-Updates haben, bevor Sie es in prod mit denken.

Ich würde stimmen nicht. Hibernate scheint nicht zu verstehen, wenn Datentypen für Spalten geändert haben. Beispiele (MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Es gibt wahrscheinlich auch andere Beispiele ebenso wie die Länge einer String-Säule bis über 255 schieben und zu sehen, um es zu Text konvertieren, MEDIUMTEXT-, etc etc.

Zugegeben, ich glaube nicht, dass es wirklich eine Möglichkeit, mit zu „Datentypen zu umwandeln“ ist eine neue Spalte, ohne die Erstellung, das Kopieren der Daten und bläst die alte Säule entfernt. Aber in dem Moment Ihrer Datenbank hat Spalten, die Sie sehr gefährlich ist nicht die aktuelle Hibernate Mapping reflektieren ...

Flyway ist eine gute Option, um dieses Problem zu umgehen:

http://flywaydb.org

Wie ich in diesem Artikel erklärt, ist es nicht eine gute Idee, verwenden hbm2ddl.auto in der Produktion.

Die einzige Möglichkeit, das Datenbankschema zu verwalten, ist schrittweise Migration Skripte zu verwenden, weil:

die Skripte in VCS entlang Ihrer Code-Basis befinden wird. Wenn Sie einen Zweig Kasse, erstellen Sie das gesamte Schema von Grund auf neu.
können die inkrementellen Skripte auf einem QA-Server getestet werden, bevor in der Produktion angewendet werden
gibt es keine Notwendigkeit für einen manuellen Eingriff, da die Skripte von Flyway ausgeführt werden kann, damit es reduziert die Möglichkeit menschlicher Fehler im Zusammenhang mit Skripts manuell ausgeführt werden.

Auch die Benutzerhandbuch Hibernate beraten Sie für Produktionsumgebungen mit dem hbm2ddl Werkzeug zu vermeiden.

Ich würde es nicht riskieren, weil man den Verlust von Daten könnte am Ende, die erhalten werden sollen. hbm2ddl.auto = update ist rein eine einfache Möglichkeit, Ihre Entwickler-Datenbank immer auf dem neuesten Stand.

Wir tun es in einem Projekt in Produktion seit Monaten läuft nun und hatte nie ein Problem so weit. Beachten Sie die 2 Zutaten für dieses Rezept benötigt:

mit einem Abwärtskompatibilität Ansatz Ihr Objektmodell-Design, das ist deprecate Objekte und Attribute, anstatt zu entfernen / verändern sie. Dies bedeutet, dass wenn Sie den Namen eines Objekt oder ein Attribut ändern müssen, die alten verlassen, wie ist, die neuen hinzufügen und eine Art von Migration Skript schreiben. Wenn Sie eine Zuordnung zwischen Objekten ändern müssen, wenn Sie bereits in Produktion sind, bedeutet dies, dass Ihr Design in erster Linie nicht in Ordnung war, so versuchen, eine neue Art und Weise zu denken, die neue Beziehung ausdrücken, ohne alte Daten zu beeinflussen.
Immer Sicherung die Datenbank vor der Bereitstellung.

Mein Gefühl ist - nach dem Lesen dieser Post -, dass 90% der Menschen, die an dieser Diskussion nehmen entsetzt nur mit dem Gedanken an Automatisierungen wie dies in einer Produktionsumgebung einsetzen. Einige werfen den Ball im DBA. Nehmen Sie einen Moment allerdings zu berücksichtigen, dass nicht alle Produktionsumgebungen einen DBA bieten und nicht viele Entwickler-Teams sind in der Lage ein (zumindest für mittelgroße Projekte) zu leisten. Wenn wir also über die Teams zu sprechen sind, wo jeder alles zu tun hat, ist der Ball auf sich.

In diesem Fall, warum nicht nur versuchen, das Beste aus beiden Welten zu haben? Tools wie diese sind hier, um eine helfende Hand zu geben, die - mit einer sorgfältigen Planung und Plan - in vielen Situationen helfen können. Und glauben Sie mir, Administratoren anfangs nur schwer zu überzeugen, aber wenn sie wissen, dass der Ball nicht auf ihren Händen, sie werden es lieben.

Ich persönlich würde nie wieder auf dem Schreiben von Skripts von Hand gehe jede Art von Schema für die Erweiterung, aber das ist nur meine Meinung. Und nach dem Start NoSQL-Schema-weniger-Datenbanken vor kurzem zu verabschieden, das kann ich mehr sehen, als bald alle diese schema-basierte Operationen der Vergangenheit angehören wird, so dass Sie besser beginnen würde Ihre Perspektive zu ändern und nach vorne schauen.

In meinem Fall (Hibernate 3.5.2, PostgreSQL, Ubuntu), das Setzen von hibernate.hbm2ddl.auto=update nur neue Tabellen erstellt und neue Spalten in bereits vorhandenen Tabellen.
Es hat weder Tropfen Tabellen, Spalten noch fallen, noch Spalten ändern. Es kann eine sichere Option aufgerufen werden, aber so etwas wie hibernate.hbm2ddl.auto=create_tables add_columns wäre klar.

Es ist nicht sicher, nicht zu empfehlen, aber es ist möglich.

Ich habe Erfahrung in einer Anwendung mit der Auto-Update-Option in der Produktion.

Nun, die wichtigsten Probleme und Risiken in dieser Lösung gefunden werden:

Deploy in der falschen Datenbank . Wenn Sie den Fehler ausführen, um den Anwendungsserver mit einer alten Version der Anwendung (EAR / WAR / etc) in der falschen Datenbank-Commit ... Sie werden eine Menge neuer Spalten, Tabellen, Fremdschlüssel und Fehler. Das gleiche Problem kann mit einem einfachen Fehler in der Datenquelldatei, auftritt (copy / paste-Datei und vergessen hat, um die Datenbank zu ändern). Im Lebenslauf kann die Situation eine Katastrophe in der Datenbank sein.
Anwendungsserver dauert zu lange, zu starten. Diese treten auf, weil die Hibernate versuchen, alle erstellten Tabellen / Spalten finden / etc jedes Mal, wenn Sie die Anwendung starten. Er muss wissen, was (Tabelle, Spalte, etc.) erstellt werden muss. Dieses Problem wird nur noch schlimmer, da die Datenbanktabellen aufzuwachsen.
Datenbank-Tools es fast unmöglich ist, zu verwenden. Um Datenbank-Skripte ausführt mit einer neuen Version zu erstellen, müssen Sie daran denken, was wird von dem Auto-Update erstellt werden, nachdem Sie den Anwendungsserver starten. Wenn Sie eine neue Spalte mit einigen Daten pro Beispiel füllen müssen, müssen Sie den Anwendungsserver starten, warten Kreta die neue Spalte Hibernate und den SQL-Skript erst danach ausgeführt werden. Wie Sie sehen können, Datenbank-Migrations-Tools (wie Flyway, Liquibase, etc) ist es fast unmöglich ist, aktiviert mit Auto-Update zu verwenden.
Datenbankänderungen nicht zentralisiert . Mit der Möglichkeit der Hibernate die Tabellen und alles andere erstellen, ist es schwer, die Änderungen auf Datenbank in jeder Version der Anwendung zu sehen, weil die meisten von ihnen automatisch sind.
legt den Müll auf Datenbank . Wegen der Leichtigkeit der automatischen Aktualisierung, gibt es eine Chance, Ihr Team alte Säulen und alte Tabellen fallen zu vernachlässigen.
Drohende Katastrophe . Die unmittelbare Gefahr einer gewissen Katastrophe in der Produktion auftritt (wie einige Leute in anderen Antworten erwähnt). Selbst bei einer Anwendung ausgeführt und aktualisierbar seit Jahren, ich glaube nicht, es ist sicher. Ich fühlte mich nie sicher mit dieser Option auf.

Also, ich werde nicht Auto-Update zu verwenden, in der Produktion empfehlen.

Wenn Sie wirklich in der Produktion verwenden Auto-Update wollen, empfehle ich:

Getrennt Netzwerke . Ihre Testumgebung kann nicht auf die Homolog Umgebung. Dies hilft, eine Stationierung zu verhindern, die angeblich in der Testumgebung, um die Homologation Datenbank ändern.
Verwalten Skripte bestellen . Sie müssen Ihre Skripte organisieren, bevor Sie Ihren deploy laufen (Strukturtabelle ändern, drop table / Spalten) und Skript nach dem deploy (Informationen für die neuen Spalten / Tabellen füllen).

Und andere der anderen Beiträge, ich glaube nicht, das Auto-Update aktiviert werden, damit mit „sehr gut bezahlt“ DBAs in engen Zusammenhang steht (wie in anderen Beiträgen erwähnt) ... DBAs wichtigere Dinge haben SQL zu tun, als schreiben Aussagen erstellen / ändern / Tabellen und Spalten löschen. Diese einfachen alltäglichen Aufgaben können von den Entwicklern durchgeführt und automatisiert werden und nur für DBA-Team übergeben zu überprüfen, nicht um Hibernate und DBAs „sehr gut bezahlt“, sie zu schreiben.

Nein, nicht immer tun. Hibernate keine Datenmigration handhaben. Ja, es wird Ihr Schema richtig aussehen lassen, aber es nicht sicher, dass wertvolle Produktionsdaten nicht in dem Prozess verloren.

Normalerweise Enterprise-Anwendungen in großen Organisationen laufen mit eingeschränkten Rechten.
Datenbank-Benutzername dürfen nicht DDL Privileg haben Spalt für das Hinzufügen welcher hbm2ddl.auto=update erfordert.

Ich bin mit Vladimir. Die Administratoren in meiner Firma würde es auf jeden Fall nicht zu schätzen wissen, wenn ich selbst einen solchen Kurs vorgeschlagen.

Das Weiteren einen SQL-Skript anstatt blind zu vertrauen Hibernate zu schaffen gibt Ihnen die Möglichkeit, Felder zu entfernen, die nicht mehr in Gebrauch ist. Hibernate macht das nicht.

Und ich das Produktionsschema mit dem neuen Schema finde Vergleich gibt Ihnen noch besseren Einblick wat Sie im Datenmodell geändert. Sie wissen natürlich, weil Sie es gemacht, aber jetzt sehen Sie alle Änderungen in einem Rutsch. Selbst diejenigen, die Sie gehen wie „Was zum Teufel?“ Zu machen.

Es gibt Tools, die ein Schema Delta für Sie machen können, so ist es nicht einmal harte Arbeit. Und Sie dann genau wissen, was passieren wird.

Applications' Schema in der Zeit weiterentwickeln kann; wenn Sie mehrere Installationen, die an verschiedenen Versionen sein kann, sollen Sie eine Möglichkeit haben, um sicherzustellen, dass Ihre Anwendung, eine Art von Werkzeug oder ein Skript von Migration Schema und die Daten von einer Version schrittweise zu jedem folgenden in der Lage ist.

in Hibernate Mappings alle Ihre Ausdauer (oder Anmerkungen) ist eine sehr gute Möglichkeit, Schemaevolution unter Kontrolle zu halten.

Sie sollten bedenken, dass Schemaevolution hat mehrere Aspekte berücksichtigt werden:

Entwicklung des Datenbankschemas in mehr Spalten und Tabellen Hinzufügen
Abwurf von alten Spalten, Tabellen und Beziehungen
Füllen neue Spalten mit Standardwerten

Hibernate Tools wichtig sind, insbesondere im Fall (wie in meiner Erfahrung) haben Sie verschiedene Versionen der gleichen Anwendung auf vielen verschiedenen Arten von Datenbanken.

Punkt 3 ist sehr empfindlich, wenn Sie den Ruhezustand verwenden, wie im Fall eine neue boolean Wert Eigenschaft oder numerisch eine einführen, wenn Hibernate jeden Nullwert in solchen Spalten finden wird, wenn eine Ausnahme machen.

Also, was ich tun würde, ist: Verwenden Sie in der Tat die Hibernate Tools Kapazität von Schema-Update, aber Sie müssen neben ihr einige Daten und Schema Wartung Rückruf, wie zum Füllen Standardwerte, fallen nicht mehr verwendet Spalten und ähnliche hinzuzufügen. Auf diese Weise erhalten Sie die Vorteile (Datenbank unabhängige Schema Update-Skripte und dupliziert Codierung des Updates zu vermeiden, in peristence und in Skripten), sondern auch alle Aspekte des Betriebes abdecken.

So zum Beispiel, wenn ein Versions-Update einfach besteht in Hinzufügen einer varchar bewertet Eigenschaft (also Spalte), die auf null in Verzug gerät, mit Auto-Update Sie getan werde. Wo mehr Komplexität notwendig ist, wird mehr Arbeit notwendig ist.

Dies wird unter der Annahme, dass die Anwendung, wenn der Lage ist, aktualisiert das Schema der Aktualisierung (es getan werden kann), was auch bedeutet, dass es die Benutzerrechte so auf das Schema zu tun haben muss. Wenn die Richtlinie des Kunden dieses (wahrscheinlich Lizard Gehirn Fall) verhindert, werden Sie die Datenbank zur Verfügung stellen müssen -. Spezifische Skripte

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow