MySQL brauche dringend Hilfe!



  • also, ich hab ein db-server mit 500GB. dann hatte ich eine tabelle mit kanpp 250GB, was ja eig kein problem sein sollte. allerdings waren die abfragen extrem langsam. daher wollte ich die tabelle teilen. also hab ich angefangen zeilenweise in eine neue tabelle zu kopieren und gleichzeitig zu löschen.

    zeile abfragen, kopieren, löschen. dann zur nächsten zeile.

    was auch funktioniert hat, allerdings hat es sich dann nach 200GB aufgehängt, weil kein speicher verfügbar war 😞

    so, dann dach ich mir ich lösche so ein paar dateien was ca. 1-2GB gebracht hat.

    nachdem es nicht gereicht hat, hab ich bischen gesucht, und dachte mysql dieser messi hat nicht aufgeräumt. daher wollte ich das problem mit

    optimize table tbl_images
    

    beheben und jetzt geht seit stunden auf der tabelle einfach nichts mehr 😕

    | 8901026 | root | localhost       | pqXXX | Query   | 55991 | Repair by sorting | optimize table tbl_images |
    
    | pqXXX              | tbl_images                            | 47563.28 Mb  |
    

    wie komm ich aus der situation wieder raus? die zeilen haben idr. nicht mehr als ein halbes GB und ich hätte theoretisch noch einen zweiten db-server mich ebenfalls 500GB 😞



  • wie komm ich aus der situation wieder raus? die zeilen haben idr. nicht mehr als ein halbes MB

    so...



  • so, ich hab also erfolgreich meine datenbank abgeschossen...

    Table './pqXXX/tbl_images' is marked as crashed and last (automatic?) repair failed
    

    ist in nem halben jahrzehnt das erste mal, aber gut. vllt. kennt sich jmd. damit aus und kann mir helfen 😕



  • http://www.mysqlperformanceblog.com/

    Hast Du eine Sicherung der Datenbank und die Möglichkeit das Szenario
    auf einem Test-Server oder VM zu gleichen HW-Voraussetzungen zu testen ?

    Baust Du die neue Teil-DB schon mit Indexe auf oder erst später. Was für
    Tabellen, InnoDB oder MyISAM verwendest Du ?

    Besteht die Möglichkeit die Trennung der Daten auf 2 Servern ( Quell- und Ziel-Server) durchzuführen ?

    Hast Du deine langsamen Abfragen mit EXPLAIN untersucht ?

    Kannst Du Ergebnis von SHOW CREATE TABLE der zu trennenden Tabellen posten
    damit wir Einblick über die Struktur erhalten ?

    Wenn Du von Speichermangel berichtest, könnte das an sehr großen Indexe liegen.



  • Du solltest mal vielleicht darüber nachdenken was es bedeutet ein Datei mit 250GB zu haben.
    Das ist im normalen Dateisystem schon nicht besonders schlau.
    MySQL ist garnicht dafür gedacht worden.
    Deshalb kann man auch bei den besten die Datendateien teilen. z.B. MSSQL

    Mach dir Gedanken ob du die Tabellen normalisiert hast.
    Jemand der 250GB an Daten in einer Tabelle hat wird doch sicher nicht nur einen Server haben oder?



  • Unix-Tom schrieb:

    Du solltest mal vielleicht darüber nachdenken was es bedeutet ein Datei mit 250GB zu haben.
    Das ist im normalen Dateisystem schon nicht besonders schlau.

    Aber immerhin besser als viele kleine?

    Unix-Tom schrieb:

    Deshalb kann man auch bei den besten die Datendateien teilen. z.B. MSSQL

    Bei den Besten hab ich jetzt spontan an PostgreSQL oder Oracle gedacht?

    Unix-Tom schrieb:

    Jemand der 250GB an Daten in einer Tabelle hat wird doch sicher nicht nur einen Server haben oder?

    Nana, wir reden hier nicht von Metadaten. Da sind schon auch alle Bilddateien drin und dann ist das ganz schnell wieder ganz wenig 😞



  • Unix-Tom schrieb:

    Jemand der 250GB an Daten in einer Tabelle hat wird doch sicher nicht nur einen Server haben oder?

    Zzt. sind es zwei, aber nur weil ein Vertrag übermorgen ausläuft und die sich überschneiden. 😞



  • Ich denke schon, dass mysql auch 500GB Daten halten kann.

    Was mir aber einfällt ist, dass eine Aufteilung einer Tabelle aus Performancegründen eine ziemlich schlechte Idee ist. Das wird nichts bringen. Wenn Du nach einem bestimmten Datensatz suchst und diesen erst in der einen Tabelle und dann in der anderen suchst, ist das mit ziemlicher Sicherheit langsamer, als in einer großen Tabelle zu suchen. Du hast einfach nichts gewonnen. Aber der Zugriff wird erheblich schwieriger. Ein Index hilft da eher. Schau Dir den Zugriffsplan an und mache dir Gedanken, warum der Zugriff zu langsam ist.



  • ich bins schrieb:

    Ich denke schon, dass mysql auch 500GB Daten halten kann.

    Sehe ich auch so.

    RED-BARON schrieb:

    Kannst Du Ergebnis von SHOW CREATE TABLE der zu trennenden Tabellen posten
    damit wir Einblick über die Struktur erhalten ?

    CREATE TABLE `tbl_images` (
     `url` text COLLATE utf8_bin NOT NULL,
     `link_url` text COLLATE utf8_bin NOT NULL,
     `img_url` text COLLATE utf8_bin NOT NULL,
     `id_pornostars_links_images` int(11) NOT NULL DEFAULT '0',
     `link_url_data` longblob NOT NULL,
     `link_url_size` int(11) NOT NULL,
     `link_url_status` int(11) NOT NULL,
     `img_url_data` longblob NOT NULL,
     `img_url_size` int(11) NOT NULL,
     `img_url_status` int(11) NOT NULL,
     `state` int(11) NOT NULL,
     `state_change` int(10) unsigned NOT NULL,
     PRIMARY KEY (`id_pornostars_links_images`),
     KEY `state` (`state`,`id_pornostars_links_images`),
     KEY `state_2` (`state`,`link_url_status`)
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin
    
    CREATE TABLE `tbl_images_data` (
     `id_pornostars_links_images` int(11) NOT NULL,
     `link_url_data` longblob NOT NULL,
     `img_url_data` longblob NOT NULL,
     PRIMARY KEY (`id_pornostars_links_images`)
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin
    

    ich bins schrieb:

    Was mir aber einfällt ist, dass eine Aufteilung einer Tabelle aus Performancegründen eine ziemlich schlechte Idee ist. Das wird nichts bringen. Wenn Du nach einem bestimmten Datensatz suchst und diesen erst in der einen Tabelle und dann in der anderen suchst, ist das mit ziemlicher Sicherheit langsamer, als in einer großen Tabelle zu suchen.

    Es geht nicht um Performance. Ich hatte eine Liste mit URLs die Heruntergeladen werden sollten. Dann wollte ich schauen, welche Links einen Übertragungsfehler hatten und die wiederholt versuchen. Allerdings hatte ich mir das vorher nicht überlegt und keinen Index angelegt. Für einen Index auf eine 250 GB Tabelle war ich einfach zu ungeduldig. Also wollte ich die Daten in tbl_images_data auslagern, da vorher Strukturänderungen an der tbl_images in Minuten abgeschlossen waren. Leider ist jetzt der Speicher aus und ich hab ein korrupte tbl_images Tabelle 😞



  • RED-BARON schrieb:

    Hast Du eine Sicherung der Datenbank

    Von den Metadaten bzw. URLs schon. Von den Bilddaten nicht, aber die kann man sich wieder runterladen.

    RED-BARON schrieb:

    Baust Du die neue Teil-DB schon mit Indexe auf oder erst später.

    Mit.

    RED-BARON schrieb:

    Was für
    Tabellen, InnoDB oder MyISAM verwendest Du ?

    MyISAM

    RED-BARON schrieb:

    Besteht die Möglichkeit die Trennung der Daten auf 2 Servern ( Quell- und Ziel-Server) durchzuführen ?

    Evtl. 😕

    RED-BARON schrieb:

    Hast Du deine langsamen Abfragen mit EXPLAIN untersucht ?

    So komplex sind die Abfragen jetzt nicht, dass ich nicht wüsste, dass kein Index verwendet wird 😉

    RED-BARON schrieb:

    Wenn Du von Speichermangel berichtest, könnte das an sehr großen Indexe liegen.

    Es liegt daran, dass ich 500GB Speicher hab. tbl_images war 250 GB und jetzt ist tbl_images_data 200GB und tbl_images 50 GB und mein Festplattenspeicher ist voll 😉



  • Hab die tbl_images_data auf den anderen Server verschoben und fahr gerade ein

    myisamchk --safe-recover tbl_images_data.MYI
    

    und

    myisamchk --safe-recover tbl_images.MYI
    

    Aber es stimmt vorn und hinten nicht mehr 🙄

    z.B.

    myisamchk schrieb:

    error: Record-count is not ok; is 4640712 Should be: 4384259

    4640712 Zeilen waren aber schon richtig 😕



  • myisamchk --safe-recover wirkt wunder 😋



  • dann kannst Du jetzt wieder Bilder anguggen - schön ! 😃

    Das Aufteilen einer Tabelle in "statische" Daten und "dynamische" Daten
    bringt auch nur was beim Schreiben. Konnte nicht wissen das Du so viel
    Freude an ewig alten Pornos hast 🤡



  • RED-BARON schrieb:

    dann kannst Du jetzt wieder Bilder anguggen - schön ! 😃

    Wenn ich sie mir nur schon mal angeschaut hätte... sind aber mit sicherheit schöner als die Tube-Pornos...

    RED-BARON schrieb:

    Das Aufteilen einer Tabelle in "statische" Daten und "dynamische" Daten bringt auch nur was beim Schreiben.

    Wie die dann in einer App verwurstet werden steht eh auf einem anderen Blatt...

    RED-BARON schrieb:

    Konnte nicht wissen das Du so viel
    Freude an ewig alten Pornos hast 🤡

    Ach, jeder hat so seine Laster 😉


Log in to reply