POSTGRESQL: Database must vacuumed within XXXXXXX transactions
Puh... Da guggste erstmal etwas ungläubig aus der Wäsche, wenn dir Postgres folgende Meldung um die Ohren legt:
2007-07-31 19:27:33 CEST WARNING: database "userbase" must be vacuumed within 999831 transactions
2007-07-31 19:27:33 CEST HINT: To avoid a database shutdown, execute a full-database VACUUM in "userbase".
2007-07-31 19:27:33 CEST WARNING: database "userbase" must be vacuumed within 999830 transactions
...
2007-07-31 19:27:33 CEST WARNING: database "userbase" must be vacuumed within 999809 transactions
2007-07-31 19:27:33 CEST HINT: To avoid a database shutdown, execute a full-database VACUUM in "userbase".
2007-07-31 19:27:33 CEST ERROR: could not access status of transaction 539227074
2007-07-31 19:27:33 CEST DETAIL: could not open file "pg_clog/0202": No such file or directory
Das Schöne dabei ist, das dann gar nix mehr geht und Postgres sicherheitshalber keine Verbindungen mehr annimmt - auch nicht vom Administrator. Schon schick... Nun zurückzuführen war das Ganze auf einen Bug im Autovacuum-Daemon, der mit Version 8.1.7 behoben wurde. 8.1.5 war aber am Laufen.
Was hab ich also gemacht? Im Gegensatz zum Oracle Support, der Core-Dumps auch nach 3 Monaten nicht analysiert bekommt, ist die Postgres-Mailingliste eine echte Wohltat. Apropos Oracle Support: Mein Gott ist der inzwischen schlecht geworden... Nichts für ungut, aber ich mach mit Oracle jetzt seit über 8 Jahren rum und ich bin sowas von froh, wenn die letzte Oracle abgeschaltet wird. Aber das nur nebenbei... Nachdem ich schon eine Weile am Suchen war, hat ein kleiner Tipp eines Users der Mailingliste (Antwort hat ca. 15 Min. gedauert...) mich weitergebracht.
Im Endeffekt habe ich Folgendes gemacht: Es fehlte der DB angeblich ein Transactionlog names 0202. Das war aber eigentlich Blödsinn, denn soweit war er mit seinen Logs noch gar nicht. Zuerst hab ich ein Upgrade von 8.1.5 auf 8.1.9 gemacht, da dort der Bug behoben war. Ich hab dann im Verzeichnis pg_clog das Log FFE (das hat mir am Besten gefallen) nach 0202 kopiert (DB war dabei natürlich unten). BTW: Ein Backup der Daten wäre schon angebracht, bevor man das macht ;-) Dann hab ich ein Skript ausgeführt, das die Postgres im Standalone Mode startet (kann man in der Postgres Doku nachlesen):
postgres -d 2 -S 50000 -B 300000 -D /var/lib/postgres userbase << SQL
VACUUM FREEZE
SQL
Das hat dann jede Menge Transactionlogs weggeschmissen, aber immerhin lief das durch. Anschließend (zur Sicherheit):
postgres -d 2 -S 50000 -B 300000 -D /var/lib/postgres userbase << SQL
VACUUM FULL VERBOSE ANALYZE
SQL
Dann hab ich die DB wieder gestartet. Und tata: Lief wieder! Aber dadurch, das der Autovacuum nicht sauber lief aufgrund des Bugs, war jetzt natürlich max_fsm_pages zu klein geworden (das sieht man dann, wenn man ein "normales" VACUUM auf die DB macht zum Schluss). Ich mußte also noch ein VACUUM FULL auf alle Instanzen durchführen, damit alles wieder aufgeräumt wird. Das ist übel, aber unvermeidlich in diesem Fall.
In diesem Sinne: Volle Kanne!
Technorati Tags: postgresql
Posted at 12:30vorm. Aug. 02, 2007 by cetixx in Tipps | Kommentare [0]