TS: Die Vorteile contra die Unbilden von InnoDB

Hallo CK,

Ich nehme an, dass es das wieder nur für InnoDB gibt und nicht für MyISAM?

MyISAM kann gar nichts und sollte auch nicht verwendet werden, wenn dir deine Daten lieb sind. Du nimmst also richtig an.

Mein Problem mit InnoDB hast Du ja vielleicht noch im Gedächtnis? Ich habe bisher noch nicht herausgefunden, wie man nachträglich eine geschlossene InnoDB-Datenbankdatei in einzelne Tabellendateien zerlegen kann, so dass man sie LowLevel transferieren kann auf einen anderen DBMS-Server.

Das muss dann aber sowohl auf dem Quellsystem, als auch auf dem Zielsystem funktionieren, ohne dass etwas kaputt geht. Ich habe es bisher nicht geschafft.

Grüße
TS

--
es wachse der Freifunk
http://freifunk-oberharz.de
  1. Hallo TS,

    Ich nehme an, dass es das wieder nur für InnoDB gibt und nicht für MyISAM?

    MyISAM kann gar nichts und sollte auch nicht verwendet werden, wenn dir deine Daten lieb sind. Du nimmst also richtig an.

    Mein Problem mit InnoDB hast Du ja vielleicht noch im Gedächtnis?

    Nein. War ich dort beteiligt?

    Ich habe bisher noch nicht herausgefunden, wie man nachträglich eine geschlossene InnoDB-Datenbankdatei in einzelne Tabellendateien zerlegen kann, so dass man sie LowLevel transferieren kann auf einen anderen DBMS-Server.

    Warum möchtest du das? Vor allem: warum möchtest du das „in einzelnen Dateien?“

    Ich würde sie lieber logisch übertragen wollen (dump & restore), alles andere verursacht doch Downtimes.

    LG,
    CK

    1. Hallo CK,

      Mein Problem mit InnoDB hast Du ja vielleicht noch im Gedächtnis?

      Nein. War ich dort beteiligt?

      Ich weiß nicht mehr, wer alles mitgelesen und geantwortet hat. Aber das Problem ist noch vorhanden.

      Ich habe bisher noch nicht herausgefunden, wie man nachträglich eine geschlossene InnoDB-Datenbankdatei in einzelne Tabellendateien zerlegen kann, so dass man sie LowLevel transferieren kann auf einen anderen DBMS-Server.

      Warum möchtest du das? Vor allem: warum möchtest du das „in einzelnen Dateien?“

      Es geht um shared Hosting, was man bei Datenbanken ja meistens hat - auch innerhalb eines Kunden-Accounts. Der DBMS-Nuter hat also mehrere Datenbanken auf demselben Server laufen. Normal ;-)

      Die DBMS-Admins wollen aber nun nicht die Hoheit über alle Datenbanken aus dem Haus geben, sondern nur über eine einzige, mit der/für die etwas programmiert werden soll.

      Ich will aber auch nicht für jeden "Kunden" einen eigenen DBMS-Server aufstetzen müssen. Also bin ich gezwungen, die irgendwie prallel auf dem DBMS-Server unterzubringen. Bei MyISAM war das alles kein Problem.

      Ich würde sie lieber logisch übertragen wollen (dump & restore), alles andere verursacht doch Downtimes.

      Das ist auch nicht immer ohne weiteres möglich, wenn Trigger, Stored Procedures, Relational Restrictions, Select-History usw. benutzt werden.

      Und da die Projekte, an die man unsere gtruppe ranlässt doch etwas kleiner als Facebook sind, sind die notwendigen Downtimes überschaubar kurz. Wie lange dauert das bei den Self-Servern, die Datenbank runter- und wieder raufzufahren?

      Grüße
      TS

      --
      es wachse der Freifunk
      http://freifunk-oberharz.de
      1. Hallo TS,

        Ich habe bisher noch nicht herausgefunden, wie man nachträglich eine geschlossene InnoDB-Datenbankdatei in einzelne Tabellendateien zerlegen kann, so dass man sie LowLevel transferieren kann auf einen anderen DBMS-Server.

        Warum möchtest du das? Vor allem: warum möchtest du das „in einzelnen Dateien?“

        Es geht um shared Hosting, was man bei Datenbanken ja meistens hat - auch innerhalb eines Kunden-Accounts.

        Meistens hat ist eine mutige Aussage ;-)

        Ich will aber auch nicht für jeden "Kunden" einen eigenen DBMS-Server aufstetzen müssen. Also bin ich gezwungen, die irgendwie prallel auf dem DBMS-Server unterzubringen. Bei MyISAM war das alles kein Problem.

        Warum sollte das ein Problem sein bei InnoDB? Ich habe dein Problem noch nicht verstanden.

        Ich würde sie lieber logisch übertragen wollen (dump & restore), alles andere verursacht doch Downtimes.

        Das ist auch nicht immer ohne weiteres möglich, wenn Trigger, Stored Procedures, Relational Restrictions, Select-History usw. benutzt werden.

        Dafür liefert MySQL fertige Tools mit: mysqldump. Das sollte mit allem umgehen können.

        Und da die Projekte, an die man unsere gtruppe ranlässt doch etwas kleiner als Facebook sind, sind die notwendigen Downtimes überschaubar kurz.

        Ist dir bewusst, dass du für ein physikalisches Backup - auch bei MyISAM! - während des kopierens das DBMS herunterfahren musst, weil sonst die Dateien in einem inkonsistenten Zustand sein können?

        Wie lange dauert das bei den Self-Servern, die Datenbank runter- und wieder raufzufahren?

        Der reine Restart? 10 Sekunden vielleicht. Mit Backup? Keine Ahnung, ein Dump dauert etwa 10 Minuten. Ich verwende allerdings PostgreSQL.

        LG,
        CK

        1. Hallo und guten Abend CK und All,

          Danke für die Extraktion des Themas in einen eigenen Thread. Mir ist das nämlich durchaus wichtig und ich kann mir auch vorstellen, dass es von allgemeiner Relevanz ist bei Leuten, die da schon mal tiefer eingestiegen sind. Das lassen mich zumindest meine Google-Recherchen (und die in einigen anderen Suchmaschinen) annehmen.

          Ich würde also gerne erstmal einen Griff an das Problem machen:

          • Status Quo
          • Aufgabenstellung
          • versuchte vermeintliche Lösungswege ...
          • usw.

          Vielleicht mag mir hierbei ja jemand helfen, ohne sofort gegenzuhalten...
          Das soll aber nicht heißen, dass ich beratungsresistent wäre für andere Lösungswege.
          Ich möchte nur bei "meinem" Problem erst einmal soweit kommen, dass es alle nachvollziehen können.

          Wie "Man es macht" kann ich in Hunderten von Sackgassen-Threads in diversen Foren nachlesen. Die landen später alle in "No more Answer" == "Es herrscht Stille". Leider ist die Aufgabe dann immer noch nicht gelöst.

          Ich würde es begrüßen, wenn CKs neue Möglichkeiten dazu führen würden, dass die Drift gering bleibt. Ich bin mir darüber im Klaren, dass der Thread ziemlich lange laufen könnte, bis das Patentrezept gefunden ist. Ich werde auf jeden Fall dabei bleiben.

          Grüße
          Thomas Schmieder

          --
          es wachse der Freifunk
          http://freifunk-oberharz.de
          1. Hallo TS,

            Vielleicht mag mir hierbei ja jemand helfen, ohne sofort gegenzuhalten...

            Warum hast du das Gefühl, ich halte dagegen? Ich habe hauptsächlich Fragen gestellt.

            LG,
            CK

            1. Hallo und guten Abend,

              Warum hast du das Gefühl, ich halte dagegen? Ich habe hauptsächlich Fragen gestellt.

              Nein, habe ich doch gar nicht. Ich fand das gut, dass der Subject-Wechsel in dem anderen Thread nun als eigener Thread erscheint. Oder hast Du gar nichts gemacht und es ist ein Wunder geschehen? Ich hatte ja noch eines gut laut meiner Sternenberaterin ;-)

              Grüße
              TS

              --
              es wachse der Freifunk
              http://freifunk-oberharz.de