Właśnie przeinstalowałem postgres przez brew install postgres
Pobiegłem, initdb /usr/local/var/postgres -E utf8
ale dostałem to:
The files belonging to this database system will be owned by user "atal421".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".
initdb: directory "/usr/local/var/postgres" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/usr/local/var/postgres" or run initdb
with an argument other than "/usr/local/var/postgres".
więc mam rm -rf
folder postgres i uruchomiłem go ponownie:
initdb /usr/local/var/postgres -E utf8
powiedziało, że wszystko jest w porządku:
Success. You can now start the database server using:
postgres -D /usr/local/var/postgres
więc uruchomiłem to polecenie i otrzymałem:
postgres -D /usr/local/var/postgres
FATAL: lock file "postmaster.pid" already exists
HINT: Is another postmaster (PID 13731) running in data directory "/usr/local/var/postgres"?
Teraz, gdy patrzę na monitor aktywności, widzę 6 wystąpień adresu pocztowego.
Jak to naprawić?
postgres
z postmasterem i pięcioma backendami narzędziowymi. PostgreSQL to architektura wieloprocesowa.Odpowiedzi:
Ogłoszenie o usługach publicznych: nigdy nie usuwaj
postmaster.pid
. Naprawdę. Świetny sposób na uszkodzenie danych.Masz już zainstalowany PostgreSQL i usunąłeś katalog danych bez zatrzymywania działającego serwera. Masz teraz niektóre osierocone procesy serwera PostgreSQL, które zarządzają usuniętymi plikami danych, więc nie są one już dostępne w systemie plików i zostaną całkowicie usunięte, gdy ostatni otwarty uchwyt pliku zostanie zamknięty. Nie można użyć
pg_ctl
do zamknięcia serwera w normalny sposób, ponieważ usunąłeś katalog danych klastra, więc musisz po prostu zabić procesy. Zabij postmastera ( nie używajkill -9
, wystarczy zwykłe zabójstwo), a reszta też się wyłączy.Będziesz wtedy mógł uruchomić nowy serwer w katalogu danych w oparciu o świeżo
initdb
zapisane dane.Jest wysoce prawdopodobne, że wystąpią konflikty na późniejszym etapie, chyba że odinstalujesz inną starszą wersję PostgreSQL.
W skrócie:
cat /usr/local/var/postgres/postmaster.pid
Zanotuj numer w pierwszym wierszu, który jest pid postmistrza.
Sprawdź
ps
, czy pid to postmaster postmaster.Zabij proces postmastera następującą komendą, zastępując „PID” numerem, który zanotowałeś. Ponownie, nie używaj
kill -9
lubkill -KILL
po prostu używaj zwykłegokill
, tj .SIGTERM
:kill PID
Jeśli pid nie jest postmasterem postmastera, ręcznie uruchom
kill
wszystkiepostgres
backendy, które mogą nadal działać, sprawdź , czy już nie działają, a dopiero potem usuńpostmaster.pid
. (Należy również sprawdzić, czypostmaster.pid
nie znajduje się on w pamięci współdzielonej, na której serwer mógłby działać na innej maszynie wirtualnej / hoście).źródło
kill PID
nie działał dla mnie. Musiałemkill -3 PID
. W moim przypadku wykonałem zamknięcie, które mogło zabić okna terminali bez odpowiedniego zatrzymania procesów.kill -3 PID
Zabity proces i jego dzieci skutecznie pozwolił mi znowu zacząć postgres.Inną możliwością jest to, że mocno się zamknąłeś i proces postgres zmarł bez czyszczenia pliku pid. Zdarza mi się to, gdy bateria mojego laptopa wyczerpuje się.
To rozwiązanie nie jest przeznaczone dla systemu produkcyjnego i powinieneś naprawdę upewnić się, że demon Postgres nie działa , ale używam mojego laptopa do kodowania i nie martwię się o konieczność zregenerowania moich baz danych.
Więc jeśli na tym porcie działa inny proces - lub wcale go nie ma - po prostu usuń plik pid, np
i postgres wkrótce zacznie działać dobrze.
Aby dowiedzieć się, czy na tym porcie działa inny proces, możesz to zrobić
Następnie uruchomić
aby sprawdzić, czy zadziałało. Powinieneś zobaczyć
(a przynajmniej tak właśnie zobaczyłem po wykonaniu powyższego :-))
(I naprawdę, czy Postgres nie powinien być wystarczająco inteligentny, aby zdać sobie sprawę, że PID 933 nie ma procesu i sam usunąć fałszywy plik pid?)
źródło
postmaster.pid
który wskazywał plik. Było to kilka dni po nieczystym zamknięciu (instalacja Postgres na laptopie na OSX przez homebrew).rm postmaster.pid
pracował dla mnie. Nie widzę żadnego uszkodzenia danych (ale w każdym razie jest to tylko maszyna programistyczna).~/Library/Application Support/Postgres/data/postmaster.pid
byłem znowu gotowy do pracy.Próbowałem tego wszystkiego bezskutecznie po aktualizacji do Yosemite złamał mój postgres (zainstalowany przez homebrew).
Potem natknąłem się na ten post na blogu: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres
Najpierw musiałem utworzyć brakujące katalogi, które najwyraźniej zostały usunięte podczas aktualizacji (dzięki Apple!).
Następnie ponownie uruchom postgres, używając normalnej sekwencji uruchamiania homebrew:
Dzięki Ruckus Notes za pomoc w rozwiązaniu mojego problemu. Mam nadzieję, że to również pomaga.
źródło
TWARDE INSTRUKCJE REBOOTU
Miałem ten sam problem po ciężkim ponownym uruchomieniu. Po sprawdzeniu
postmaster.pid
pid pliku zauważyłem, że nie mam uruchomionego procesu. Nie chciałem mocno usuwać pliku .pid, zamiast tego użyłempg-stop
aliasu, który utworzyłem w swoim.bash_profile
. ten alias po prostu działapg_ctl -D /usr/local/var/postgres stop -s -m fast
Na przykład
dane wyjściowe dziennika po
pg-stop
napar
Pomyślałem, że powinienem tutaj również wspomnieć, że jeśli zainstalowałeś postgres z homebrew, powinieneś rzucić
brew services
okiem. W ten sposób wolę uruchamiać / zatrzymywać moje bazy danych.źródło
Ten błąd wystąpił po, jak sądzę, awarii mojego komputera. PostgreSQL nie mógł nawet uruchomić z powodu tego błędu, więc zabicie procesu nie było rozwiązaniem. Po prostu utworzyłem kopię zapasową, a następnie usunąłem
postmaster.pid
plik, a następnie błąd ustał i PG mógł rozpocząć od nowa.źródło
Czasami pokorni
pg_ctl -w restart
mogą załatwić sprawę :-)źródło
/usr/pgsql/9.3/data/postmaster.pid
nie był obecny w ps aux.)Usuwanie postmaster.pid jest naprawdę całkiem przyzwoitą rzeczą do zrobienia przy każdym rozruchu, na ślepo. Tak właśnie działa mój system. Ponieważ właśnie się uruchomiłeś, wiesz, że nie ma uruchomionego procesu Postgres, a jeśli odzyskujesz po nieczystym zamknięciu, ten plik będzie tam uniemożliwiać odzyskiwanie.
Lepszym rozwiązaniem dla Postgresa byłoby umieszczenie pliku postmaster.pid w systemie plików / run, więc gwarantuje się, że zostanie usunięty przy każdym ponownym uruchomieniu. Wiele innych serwerów działa w ten sposób.
źródło