MySQL -> PostgreSQL -- Tabelle zu groß = Speicher voll...

C

CrimsonKing

Guest
Ich würde gern meine Uralt-TT-RSS-Instanz (mehrere Benutzer) von MySQL/MariaDB auf PostgreSQL migrieren, weil das der einzige vom Entwickler unterstützte Datenbank ist und das vermutlich Gründe haben wird.

Leider brechen sämtliche Migrationsskripte in der Tabelle ttrss_entries ab - sind einfach zu viele und der RAM läuft voll. Gibt es da einen anderen Trick als "fang noch mal ganz von vorne an"?
 

bsd4me

Well-Known Member
Hallo, hast Du einen anderen Rechner/Server mit mehr RAM, um danach die DB zurück-zu-"kopieren"? Oder Evtl. liegt es daran, dass das ganze als 1 Transaktion läuft. Wenn man jeden Eintrag als rogenständige Transaktion (oder ohne) laufen lassen könnte... nur eine Idee.
VG Norbert
 
C

CrimsonKing

Guest
Das ist ein uralter VServer, den kann ich nur mit Neubestellen aufrüsten, fürchte ich.

Die Datenbank auf einem anderen Rechner zu konvertieren würde Export mit sich ziehen, und da ich gerade nur ein Windows da habe, könnte das spannend werden...
Das mit der Transaktion ist aber ein guter Tipp.

Ich nutze dieses Script:
https://gist.github.com/brycied00d/339d8460e7b1955bd9e15542bbbee21b

Ich müsste transaction.do zwischendurch unterbrechen, wenn ich das richtig verstanden habe?
 

mapet

Active OpenBSD User
Ausdumpen, verkleinern und das original in Posters eindumpen? Zumindest als csv sollte das doch funktionieren.
 

-Nuke-

Well-Known Member
Kann natürlich sein, dass das dafür verwendete ORM "sequel" hier eine Transaktion erzwingt, aber bei einer nicht-destruktiven Datenmigration ist die Benutzung von Transaktionen eigentlich total sinnlos. Somit müsste es reichen, wenn du einfach die 4 Zeilen von Transaction do / end raus nimmst. Dauert dann natürlich alles länger.
 
C

CrimsonKing

Guest
Keine Ahnung - in der Zeit, bevor das Script die Verbindung verliert, kann ich ssh nicht mehr benutzen, ich tippe also auch weiterhin auf: einfach keine Ressourcen mehr da.
 

-Nuke-

Well-Known Member
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server dann bleibt dir nur, dass du mal den PostgreSQL Server so einstellst, dass er nur 1/4 deines RAM nutzt und schalte autovacuum aus für den Vorgang. Vielleicht sind eine Settings da auch einfach unpassend. Du kannst ja auch einfach ein Skript auf dem Server laufen lassen, was jede Sekunde den Systemzustand in eine Datei schreibt. Dann muss man nicht raten was eigentlich das Problem ist
 
C

CrimsonKing

Guest
Das Problem ist, dass irgendwann der RAM vollläuft. :confused:

Welche der Einstellungen begrenzt denn den "Maximalspeicher"?
 

-Nuke-

Well-Known Member
Steht doch eigentlich im verlinkten Tuning-Guide. Wenn du dir 100%ig sicher bist, dass der RAM voll läuft, dann eben die genannten Dinge mal mehr begrenzen (z.B. shared_buffers), Autovacuum abschalten usw.
Du erzählt ja halt recht wenig darüber was eigentlich alles passiert, aber ich hab hier Testdatenbanken mit mehreren Millionen Einträgen und zig GB großen Tabellen und da explodieren auch keine Ressoucen. Darum bin ich an der Stelle eher verwundert.

Vielleicht ist's ja auch was ganz anderes was das System blockiert. Darum die Frage nach einen ordentlichen System-Log. RAM-Verbrauch der einzelnen Prozesse, etc.

Oder hat dein V-Server nur 1GB RAM?
 
C

CrimsonKing

Guest
Nee - sind 2 GB. Das ist natürlich auch nicht bewonders viel, aber bislang hat es gereicht.

Im Leerlauf (also ohne irgendwelche Datenbankschubsereien) gibt top folgendes aus:

Mem: 560M Active, 841M Inact, 450M Wired, 201M Buf, 113M Free

Ich muss zu meiner Schande gestehen, dass mir die Speicherverwaltung bisher vollkommen wurst war. Also liegt es eigentlich nahe, dass das der RAM ist. Die Zahl neben "Free" nähert sich kurz vor dem Abbruch immer weiter 0 an.

Vielleicht sollte ich auch einfach mal irgendwann einen neuen Server mieten. :(
 

mapet

Active OpenBSD User
Du kannst auch mit Postgres Foreign Data Tables (oder so) Postgres die MySQL Tabelle einbinden lassen und sie dann Postgres intern umziehen.
 

KobRheTilla

used register
Ich würde gern meine Uralt-TT-RSS-Instanz (mehrere Benutzer) von MySQL/MariaDB auf PostgreSQL migrieren, weil das der einzige vom Entwickler unterstützte Datenbank ist
Das ist falsch:
Additionally, tt-rss requires:
* PHP version 5.4 or newer (detailed PHP requirements)
* PostgreSQL (9.1 or newer) or MySQL - InnoDB is required.

Aber selbst wenn es stimmen würde, würde ich mir diesen nutzlosen Aufwand nicht machen, solange die Applikation funktioniert.

Rob
 
C

CrimsonKing

Guest
Hmm, ich hatte es bisher so verstanden, dass MySQL eher nebenbei mitgepflegt wird. Ich finde gerade den Link natürlich nicht... dann habe ich mir ganz umsonst graue Haare wachsen lassen? Verdammt.

Was "nutzlosen Aufwand" betrifft: Der MariaDB-Server hat aktuell tatsächlich nur Tiny Tiny RSS und ein phpBB zu verwalten, und da mein nächstes größeres Webprojekt eigentlich auf PostgreSQL setzen soll, dachte ich, so eine Migration wäre vielleicht zukunftsträchtig - dann könnte ich MariaDB direkt entsorgen und hätte sogar mal wieder Ressourcen frei. :o
Mir soll es ja letztendlich auch recht sein - dann muss ich mir aber in anderer Hinsicht noch was überlegen...
 

KobRheTilla

used register
Dann würde ich vor der Migration des TT-RSS mal nachsehen, ob die Tabellen überhaupt alle Nutzdaten enthalten oder z.B. Sessions drin gespeichert sind. Diese und eventuell auch Feeds aus dem letzten Jahrhundert könnte man ja auch entfernen.

Vielleicht kannst du so die Datenbasis verkleinern (wie es manche im Thread schon andeuteten).

Rob
 

ath0

Well-Known Member
Wenn du die selbe MariaDB Version bekommen kannst, würde ich die DB abschalten und die data files auf deinen Rechner ziehen, dort das rdbms installieren und ihm die data files zu fressen geben. Falls dein Rechner dann noch ein postgre vertragen kann ist die Migration sicher viel einfacher, der RAM in dem VServer ist echt mager. Meine Postgre Installation benötigt gerade ca 150MB, Abfragen knallen da etliche in der sekunde drauf aber die DBs darin sind nicht gerade riesen, die meisten Abfragen laufen gegen meine Mail DB wo im Wesentlichen user und einige Einstellungen für die Zustellung drin sind. Bei deinem Fall scheinen es mehr Daten zu werden, wobei ich da nur deine Aussage nehme, mit Zahlen hast du die ja nicht geschmückt.
 
C

CrimsonKing

Guest
Ah, die Zahlen lassen das Problem ersichtlich werden:

Code:
SELECT table_schema,
  sum( data_length + index_length ) / (1024 * 1024) "Datenbank in MB"
FROM information_schema.TABLES
WHERE table_schema='ttrss';

-->

Code:
+--------------+-----------------+
| table_schema | Datenbank in MB |
+--------------+-----------------+
| ttrss        | 2074.7656       |
+--------------+-----------------+

Da der TT-RSS-Daemon regelmäßig gelesene Artikel wegwirft (und ich neulich erst inaktive Benutzer entfernt habe), habe ich so die Befürchtung, dass ich zumindest zahlenmäßig nicht mehr viel daran drehen kann. Hmpf.
 

mapet

Active OpenBSD User
Wenn du die selbe MariaDB Version bekommen kannst, würde ich die DB abschalten und die data files auf deinen Rechner ziehen, dort das rdbms installieren und ihm die data files zu fressen geben.

Falls sich die Version geändert hat, könntest du auch mit dumps arbeiten. Das entfernt ggf. auch als gelöscht markierte Zeilen ;).
 
Oben