Announcement

Collapse
No announcement yet.

Datenbank verkleinern für Upgrade

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Datenbank verkleinern für Upgrade

    Hallo zusammen,

    ich betreibe ein Board auf vb 4.23 Basis und möchte nun endlich auf Version 5 upgraden.

    Anleitung hierzu habe ich durch und es ist auch alles klar soweit. Allerdings ist mir beim Dump erstellen aufgefallen, dass die DB riesig ist (5GB) für 300k Beiträge (Bilder extern) und habe mir die DB mal angesehen. Der größte Datensatz findet sich unter tagsearch (1,6 Mio Einträge). Kann man hier was machen um die Datenbank zu verkleinern? Würde den Umzug enorm erleichtern weil ich keinen SSH Zugriff auf den Server habe.

    Danke!

  • #2
    tagsearch speichert die Suchanfragen von Stichworten. Angezeigt wird das ganze auf der Seite "Erweiterte Suche".
    Da solltest du eine Menge Einträge unten sehen, sofern die angezeigte Anzahl dort nicht limitiert ist, was ich niegeprüft habe.

    In den Einstellungen unter Texte: Stichwörter ist unten bei "Stichwortwolke für Suchbegriffe: Verlauf (in Tagen)" angegeben, wie lange die gesuchten Stichworte gespeichert werden. Bei dir steht dort vermutlich nichts oder eine 0. Ob das wirklich Sinn macht? Eher nicht. 90 sollte ausreichend sein.

    Wie auch immer kannst die aber die ganze Tabelle leeren, da die Daten mit der Zeit ja wieder aufgebaut werden.

    Allerdings glaube ich kaum, dass diese 1,6 Mio Einträge wirklich so viel Datenbankplatz verwenden.

    Der Suchindex könnte noch einiges beitragen. Den kannst du unter Wartung->Wartungsfunktionen leeren.

    Ansonsten schau mal genauer, welche Tabelle wie viel Platz belegt.
    this is my sig

    Comment


    • #3
      Hallo,

      danke für die rasche Antwort!

      ja da war eine Menge bei tagsearch, weil es auf 3660 Tage eingestellt war. Habe es jetzt auf 90 reduziert, ebenso die angezeigten Stichworte von 5000 auf 50 reduziert.

      Wie genau sehe ich wie viel Platz jede Tabelle belegt? Ich kann mir nur die Datensätze anzeigen lassen soweit ich das sehe. Siehe Screenshot.

      Danke!

      Comment


      • #4
        Normalerweise steht rechts von Kollation noch Größe und Überhang. Bei dir etwa nicht?

        Du sieht die Größe der Tabellen aber zum Beispiel auch in vBulletin unter Wartung->Tabellen reparieren/optimieren.

        Oder du nutzt den Phpmyadmin Ersatz Adminer (besteht aus nur einer einzigen Datei!).

        Oder du führst das folgende Query aus (DATENBANKNAME mit dem Namen deiner Datenbank ersetzen):
        Code:
        SELECT table_name, table_rows,
        round(((data_length + index_length) / 1024 / 1024),2) as size
        FROM information_schema.TABLES where table_schema = "DATENBANKNAME"
        ORDER BY size DESC;
        this is my sig

        Comment


        • #5
          Danke, in der Wartung hab ich mal gestöbert.

          Nach Leeren von tagsearch und Suchindex neu erstellen sind die größten Werte:
          post 230,58 MB
          postedithistory 125,76 MB
          searchcore_text 221,37 MB
          Das ist jeweils der Wert aus der Spalte "Daten-Größe". Bei Index-Größe steht bei searchcore_text 398 MB. Ist das normal?

          Kann man da noch was optimieren? Lt. MySQLDumper hat die Datenbank noch immer folgende Größe: (270 Tables, 2517505 Records, 1.47 GB)
          Last edited by BenPORG; Sun 14th Jan '18, 7:30am.

          Comment


          • #6
            Was genau meinst Du denn mit Umzug? Soll die Datenbank auch in eine neue Umgezogen werden oder möchtest Du "nur" ein Update auf vB5 machen. Ich kenne mich in vB4 zu wenig aus um zu Beurteilen was in der searchcore_text drin steht und die Tabelle gibt es in vB5 nicht mehr. Da der Suchindex und damit auch die Suchwörter (achtung bei utf-8 und Umlauten!) in vB5 neu erstellt werden könnten, kann ich mir vorstellen, dass diese Daten nicht unbedingt benötigt werden (kann ich aber nicht zu 100% beurteilen).
            Die Index-Größe wird von der Datenbank selbst gebildet indem die oft aufgerufenen Datensätze indexiert werden. Dadurch können diese schneller selektiert werden.

            postedithistory beinhaltet in vB5 die Daten der geänderten Beiträge. Sollten diese nicht mehr benötigt werden, können die ggf. sogar auch noch gelöscht werden.

            Solltest Du aber definitiv alles in einer Testinstallation vorab prüfen! Und bei Umzug einer Datenbank immer auf den Zeichensatz achten (utf-8/ latin1), sonst kommt es zu Umlautproblemen.
            vBulletin-forum.de | Das deutschsprachige vBulletin 5 Forum! | Widgets, Mods und Anleitungen auf deutsch.
            Team online, Latest Profile-Visitors, Disable-Postcount, Auto-close Threads, Latest Likes, Top-Posters PRO, New&Free: vB5 MemberMap

            Comment


            • #7
              Mein Plan ist es die DB zu verkleinern soweit es geht, sonst habe ich mit dem MySQLDumper andauernd Time-outs.

              Wenn das geschafft ist, wird eine Testinstallation gemacht und das Backup in eine frische DB eingespielt und geschaut ob alles hinhaut.

              Falls dem so ist wird das Upgrade für die Live-Version dann vollzogen.

              "Umzug" ist vielleicht etwas missverständlich, wir bleiben am selben Server. Es gilt dieses 9 Jahre alte Vehikel von 4.2.3 auf 5.3.4.(?) zu bringen ohne Schaden anzurichten.

              Comment


              • #8
                Ich habe im Plesk und auch bei einer anderen Hoster-Lösung die Möglichkeit eine Datenbank zu kopieren. Damit entfällt der Aufwand mit dem MySQLDumper komplett.
                Das Problem mit MySQLDumper ist mir bekannt, dieser wird aber auch nicht mehr weiter entwickelt (latest release 2011) und ist somit keine gute Wahl für die Arbeiten an der Datenbank.

                Du solltes die folgenden Tools mal anschauen/ ausprobieren:
                https://dev.mysql.com/downloads/workbench/
                https://www.heidisql.com/

                Spricht etwas gegen den Einsatz von PHPMyAdmin? Hier können auch Backups erstellt werden... diese können im Anschluss auch in einer neuen Datenbank eingelesen werden.
                vBulletin-forum.de | Das deutschsprachige vBulletin 5 Forum! | Widgets, Mods und Anleitungen auf deutsch.
                Team online, Latest Profile-Visitors, Disable-Postcount, Auto-close Threads, Latest Likes, Top-Posters PRO, New&Free: vB5 MemberMap

                Comment


                • #9
                  Ich habe mich für MSD entschieden, weil phpmyadmin keine Multipartbackups anbietet und bei der Größe kein Backup möglich war.

                  Danke für die Links, werde ich mir ansehen.

                  Comment


                  • #10
                    Wie gesagt, wenn du den Suchindex löschst, wird sich die Datenbank erheblich verkleinern.

                    Achte beim Erstellen der neuen Datenbank unbedingt darauf, dass sie denselben Zeichensatz und Kollation verwendet.
                    Oft ist es so, dass alte Datenbanken einen anderen Zeichensatz verwenden, als das jetzt der Standard für neue Datenbanken ist.


                    Wegen der Backups würde ich beim Hoster schauen und evtl. nachfragen, wie große Datenbanken problemlos zu sichern und wiedereinzuspielen sind.
                    Mysqdumper solltest du, falls nicht geschehen, von Github herunterladen, da die Version dann auch unter PHP 7 funktionieren (soll).
                    this is my sig

                    Comment


                    • #11
                      Suchindex wurde gelöscht und neu erstellt. Ich nehme an deshalb sind es jetzt nur noch 1,47GB statt 5GB.

                      Ok ich werde darauf achten. Die aktuelle DB ist Version 5.5 die neue 5.7 kann das ein Problem werden?

                      der Tipp mit Hoster und DB kopieren ist gut, danke!

                      Comment


                      • Pogo
                        Pogo commented
                        Editing a comment
                        Neu erstellen musst du den Suchindex nicht, bzw. nur nach dem Erstellen des Backups, wenn die aktuelle Version noch weiter genutzt werden soll, da der Suchindex für das Upgrade nicht relevant ist und danach eh neu erstellt wird.

                    Related Topics

                    Collapse

                    Working...
                    X