Kermit: zwei grosse mysql DB miteinander efektiv vergleichen

Hi,

wir haben aus Grund der Ausfallsicherheit 2 Server produktiv im Einsatz.
Dort laufen jeweils eine MySql Db.
Beide DB werden über ein Prozess mit neue Daten aktualisiert.

Weil bei der Aktualisierung der DB hin und wieder was schief läuft kam die Idee beide DB hin und wieder auf Gleichheit zu teste bevor irgendeinen Benutzer die Unterschiede merkt so das wir die Daten korrigieren können.

Weil die DB sehe groß sind (über 20 Mil. Einträge) würde ein Script sehr lange dauern alle Felder abzufragen. Dazu kommt der sehr großen Last hinzu was die produktiv Server belasten würde.

Ich würde daher eine andere Art der Überprüfung benötigen. Bitte um Vorschläge.
Angedacht wurde zB. das Filesize beiden DB überprüft wird (wenn Inhalt gleich muss auch Filesize gleich sein). Geht das überhaupt und wie speichert MySql die Daten physikalisch auf der Platte ab?

Wichtiges Kriterium für den Test: die MySql DB kein Last bekommt und immer zur Verfügung steht.

Vielen Dank
Kermit

  1. Hai Kermit,

    Weil bei der Aktualisierung der DB hin und wieder was schief läuft [..]

    Meiner Meinung nach solltet ihr bereits exakt an dieser Stelle anfangen.
    Warum laeuft was schief?
    Was genau laeuft schief?
    Was sagen die Logfiles?
    Etc..

    Weil die DB sehe groß sind (über 20 Mil. Einträge) würde ein Script sehr lange dauern alle Felder abzufragen. Dazu kommt der sehr großen Last hinzu was die produktiv Server belasten würde.

    Was spricht dagegen, sie lokal zu duplizieren und die Datenbanken auf einem Entiwcklungsserver zu vergleichen? Das Resultat des Prozesses sollten dann SQL-Statements sein, welche - nach ausgiebigem Testen - in dem Produktivsystem eingespielt werden koennen.

    MfG,
    Sympatisant

    --
    "Only half the World is Teflon and Asbestos, the Rest is burnable"
    1. Meiner Meinung nach solltet ihr bereits exakt an dieser Stelle anfangen.

      vollkommen richtig. Meine Frage bezieht sich nur auf ein Workaround solang die richtige Lösung da ist-

      Was spricht dagegen, sie lokal zu duplizieren und die Datenbanken auf einem Entiwcklungsserver zu vergleichen?

      Guten Vorschlag, den zweiten Vorschlag was die Replication

      Wo speichert MySql seine Daten ab bzw. welche Dateien müsste man duplizieren?

      Danke
      Kermit

      1. Moin!

        Was spricht dagegen, sie lokal zu duplizieren und die Datenbanken auf einem Entiwcklungsserver zu vergleichen?
        Guten Vorschlag, den zweiten Vorschlag was die Replication

        Dieser Satz ist nicht

        Wo speichert MySql seine Daten ab bzw. welche Dateien müsste man duplizieren?

        Hängt davon ab, welche Storage-Engine zum Einsatz kommt. Und simples Kopieren geht auch nicht unbedingt immer.

        - Sven Rautenberg

        1. Wo speichert MySql seine Daten ab bzw. welche Dateien müsste man duplizieren?

          Hängt davon ab, welche Storage-Engine zum Einsatz kommt. Und simples Kopieren geht auch nicht unbedingt immer.

          kannst du bitte etwas mehr Details dazu geben.

          1. Moin!

            Wo speichert MySql seine Daten ab bzw. welche Dateien müsste man duplizieren?

            Hängt davon ab, welche Storage-Engine zum Einsatz kommt. Und simples Kopieren geht auch nicht unbedingt immer.
            kannst du bitte etwas mehr Details dazu geben.

            MyISAM speichert in Unterverzeichnissen in Einzeldateien je Tabelle, InnoDB speichert in der einzigen, dafür angelegten Datei - siehe my.cnf, innodb_data_file_path.

            Wenn du Replikation willst, wende Replikation an. Du warst auf den Punkt noch nicht ausreichend eingegangen.

            - Sven Rautenberg

  2. Hi!

    Beide DB werden über ein Prozess mit neue Daten aktualisiert.
    Weil bei der Aktualisierung der DB hin und wieder was schief läuft kam die Idee beide DB hin und wieder auf Gleichheit zu teste bevor irgendeinen Benutzer die Unterschiede merkt so das wir die Daten korrigieren können.

    Das hört sich so an, als ob ihr das eingebaute Feature Replication nicht verwendet. Warum nicht?

    Lo!