Postgresql serveris netiek startēts. PostgreSql pakalpojums netiek startēts

pg_ctl init [ -s ] [ -D datu direktorijs] [ -o initdb-opcijas ]

pg_ctl sākums [ -w ] [ -t sekundes] [ -s ] [ -D datu direktorijs] [ -l faila nosaukums] [ -o iespējas] [ -lpp ceļš] [-c]

pg_ctl stop [ -W ] [ -t sekundes] [ -s ] [ -D datu direktorijs] [ -m s | f | es ]

pg_ctl restart [ -w ] [ -t sekundes] [ -s ] [ -D datu direktorijs] [ -c ] [ -m s | f | i ] [ -o iespējas ]

pg_ctl pārlādēt [ -s ] [ -D datu direktorijs ]

pg_ctl statuss [ -D datu direktorijs ]

pg_ctl veicināt [ -s ] [ -D datu direktorijs ]

pg_ctl nogalināt signāla_nosaukums procesa_id

pg_ctl reģistrs [ -N pakalpojuma nosaukums] [ -U Lietotājvārds] [ -P parole] [ -D datu direktorijs] [ -S a | d ] [ -w ] [ -t sekundes] [ -s ] [ -o iespējas ]

pg_ctl atcelt reģistrāciju [ -N pakalpojuma nosaukums ]

Serveris tiek palaists sākuma režīmā. Process darbojas fonā, un standarta ievade ir saistīta ar /dev/null (vai nul operētājsistēmā Windows). Pēc noklusējuma Unix līdzīgās sistēmās servera izvade un kļūdas tiek ierakstītas standarta izvades (nevis kļūdu) ierīcē pg_ctl. Pg_ctl izvade ir jānovirza uz failu vai procesu, piemēram, žurnāla rotācijas lietojumprogrammu rotatelogs ; pretējā gadījumā postgres ierakstīs izvadi vadības terminālī (fonā) un paliks čaulas procesu grupā. Operētājsistēmā Windows servera izvade un kļūdas pēc noklusējuma tiek novirzītas uz termināli. Varat mainīt šo darbību un novirzīt servera izvadi uz failu, pievienojot slēdzi -l. Mēs iesakām izmantot slēdzi -l vai novirzīt izvadi.

Lai apturētu serveri, izmantojiet stop. Jūs varat apstāties trīs režīmos, kas norādīti ar karogu -m. Noklusējuma režīms ir "Viedais", kas gaida visu aktīvo klientu savienojumu un attālās dublēšanas procesu pabeigšanu. Ja serveris darbojas karstā gaidstāves režīmā, atkopšana un straumēšanas replikācija tiks pārtraukta, tiklīdz visas klienta sesijas tiks pabeigtas. "Ātrais" režīms negaida, līdz klienta sesijas beigsies, un pārtrauc attālās dublēšanas procesus. Visas aktīvās transakcijas tiek atceltas, un klienti ir spiesti atvienoties, pēc tam serveris apstājas. Režīms "Tūlītēja" nekavējoties pārtrauc visus procesus un aptur serveri, kas noved pie nepieciešamības atgūties pēc kļūmes nākamajā startā.

Lai apturētu un pēc tam palaistu serveri, tiek izmantota restartēšana. Šajā gadījumā ir pieejami postgres komandas karodziņi. restartēšana var nedarboties, ja, startējot serveri, komandrindā tika norādīts relatīvs ceļš uz datu glabāšanas direktoriju.

Lai atkārtoti izlasītu konfigurāciju (postgresql.conf, pg_hba.conf utt.), tiek izmantota atkārtota ielāde, un postgres process saņem SIGHUP sistēmas signālu. Tas ļauj piemērot izmaiņas, pilnībā nerestartējot serveri.

Lai pārbaudītu klastera statusu, tiek izmantots statuss. Ja klasteris darbojas, tiks parādīts procesa PID, kā arī komanda ar startēšanas laikā izmantotajiem argumentiem. Ja klasteris tiek apturēts, process atgriezīs izejas statusu 3. Ja datu krātuves direktorijs nav norādīts, process atgriezīs izejas statusu 4.

Lai pārslēgtu gaidstāves serveri primārajā režīmā, izmantojiet veicināšanas . Šajā gadījumā serveris pārstāj darboties atkopšanas režīmā un sāk strādāt lasīšanas-rakstīšanas režīmā.

Lai nosūtītu signālu procesam, tiek izmantota nogalināšana. Tas ir īpaši noderīgi Microsoft Windows vidē, kuras papildprogrammā nav komandas kill. Pieejamo signālu sarakstu skatiet sadaļā --help .

Lai reģistrētos kā sistēmas pakalpojums operētājsistēmā Microsoft Windows, tiek izmantota reģistrācija. Karodziņš -S iestata pakalpojuma startēšanas režīmu — “automātiski” (OS startējot) vai “pieprasījumu” (pēc pieprasījuma).

Lai noņemtu reģistrētu pakalpojumu sistēmā Microsoft Windows, tiek izmantota reģistrācijas atcelšana.

Iespējas

C
--core-fails

Platformās, kurās tas tiek atbalstīts, serveris mēģinās tvert atmiņas momentuzņēmumus avāriju gadījumā. Tas ļauj diagnosticēt un novērst iespējamās problēmas nākotnē. -D datu direktorijs
--pgdata datu direktorijs

Norāda klastera konfigurācijas failu atrašanās vietu. Ja nav norādīts, tiek izmantota vides mainīgā PGDATA vērtība. -l faila nosaukums
-- žurnāls faila nosaukums

Izvada žurnāla datus uz faila nosaukums. Fails tiek izveidots, ja tas vēl neeksistē. Šajā gadījumā umask ir iestatīts uz 077, kas neļauj citiem lietotājiem piekļūt šim failam. -m režīmā
-- režīms režīmā

Iestata klastera apturēšanas režīmu. režīmā pieņem vērtības smart , fast vai tūlītēja , vai katras pieejamās vērtības pirmo burtu, piemēram, s . Ja karodziņš ir izlaists, tad tiek izmantots smart. -o iespējas

Norāda karogus, kas tiks nodoti postgres.

Vērtībai jābūt ierāmētai ar vienu vai dubultpēdiņas lai nodrošinātu grupas integritāti. -o initdb-opcijas

Norāda karogus, kas tiks nodoti initdb.

Vērtībai ir jābūt vienpēdiņās vai dubultpēdiņās, lai nodrošinātu grupas integritāti. -lpp ceļš

Norāda postgres lietojumprogrammas atrašanās vietu. Pēc noklusējuma tiek izmantots tas pats ceļš, kur atrodas pg_ctl, vai, ja tas neizdodas, tiek izmantots instalēšanas ceļš. Visbiežāk šis parametrs nav jāizmanto, izņemot nestandarta situācijas.

init pieņem parametrus, kas ir līdzīgi initdb . -s
-- kluss

Rādīt tikai kļūdas, bez informatīviem ziņojumiem. -t
--pārtraukums

Maksimālais laiks (sekundēs), kas jāgaida, līdz serveris sāks vai apstāsies. Noklusējums ir 60 sekundes. -V
-- versija

Izdrukā pg_ctl versiju un pārtrauc izpildi. -w

Gaida palaišanas vai izslēgšanas pabeigšanu. Šis ir noklusējuma režīms, lai apturētu, bet ne sāktu darbības. Startēšanas fāzes laikā pg_ctl nepārtraukti mēģina izveidot savienojumu ar serveri. Apturēšanas fāzes laikā pg_ctl pārbauda, ​​vai nav PID faila. Šis parametrs ļauj iestatīt SSL kontroles vārda ievadi servera startēšanas laikā. pg_ctl atgriež izejas kodu, pamatojoties uz sākuma vai apturēšanas darbību rezultātu. -W

Ignorēt gaidīšanu, līdz serveris sāksies vai apstāsies. Šī darbība ir noklusējuma darbība palaišanas un restartēšanas režīmiem. -?
-- palīdzēt

Drukājiet pg_ctl komandas palīdzību un pārtrauciet izpildi.

Windows specifiskās opcijas

N pakalpojuma nosaukums

Reģistrējamā sistēmas pakalpojuma nosaukums. To izmanto kā sistēmas un displeja vērtību. -P parole

Lietotāja parole, kas uzsāk pakalpojumu. -S palaišanas veids

Sistēmas pakalpojuma palaišanas veids. Var izmantot vērtības: auto , vai pieprasījums , vai arī tās var attēlot ar katras norādītās vērtības nosaukuma pirmo burtu. Noklusējums ir automātisks. -U Lietotājvārds

Lietotājvārds, ar kuru pakalpojums tiks palaists. Domēna lietotājiem ir jāizmanto apzīmējums DOMAIN\lietotājvārds.

Es mēģinu palaist Postgres 9.2.4 kā pakalpojumu operētājsistēmā Windows 7. Pēc postgres instalēšanas pakalpojums darbojas labi. Tomēr pēc postgres kā citas programmas servera instalēšanas pakalpojums pārstāja darboties. Mēģinot sākt pakalpojumu tagad, es saņemu ziņojumu, ka:

"Pakalpojums postgresql-x64-9.2 — PostgreSQL Server 9.2 lokālajā datorā Dators startēja un pēc tam apstājās. Daži pakalpojumi tiek automātiski apturēti, ja tos neizmanto citi pakalpojumi vai programmas."

Mēģinot palaist programmu, kurai ir paredzēts izmantot datu bāzes serveri, tiek parādīta šāda kļūda:

"Radās problēma, mēģinot pieteikties vai izveidot ražošanas datu bāzi. Sīkāka informācija: nevarēja izveidot savienojumu ar serveri; iespējams, nevarēja izveidot savienojumu ar attālo savienotāju. Lietojumprogrammai tagad vajadzētu aizvērties."

Es arī saskāros ar šo kļūdu vienreiz, atverot to pašu programmu:

"Radās problēma, mēģinot pieteikties vai izveidot ražošanas datu bāzi. Sīkāka informācija: FATAL: neizdevās ielādēt pg_hba.conf. Lietojumprogrammai tagad vajadzētu aizvērt."

Es mēģināju palaist pakalpojumu, kas reģistrēts kā vietējā sistēma konts kā arī mans konts (postgres īpašumu īpašumos) bez rezultātiem. Es arī mēģināju restartēt datoru. Pēc daudzām problēmām internetā es uzzināju, ka ir labi pārbaudīt pg_log failu. Šeit ir pēdējā pg_log ieraksta saturs:

2013-05-29 14:59:45 MDT LOG: datu bāzes sistēma tika pārtraukta; pēdējo reizi zināms līdz 2013-05-29 14:58:01 MDT 2013-05-29 14:59:45 MDT LOG: datu bāzes sistēma netika pareizi aizvērta; automātiska atkopšana notiek 2013-05-29 14:59:45 MDT LOG: ieraksts ar nulles garumu pie 0/175BB98 2013-05-29 14:59:45 MDT LOG: pārtaisīšana nav nepieciešama 2013-05-29 14:59 :45 MDT LOG: datu bāzes sistēma ir gatava pieņemt savienojumus 2013-05-29 14:59:45 MDT LOG: autovakuuma palaišanas ierīce startēja 2013-05-29 15:07:00 MDT LOG: šī 2013. gada būve neatbalsta vietējos savienojumus -05-29 15:07:00 MDT KONTEKSTS: konfigurācijas faila "C:/PostgreSQL/data/pg_hba.conf" 1. rindiņa 2013-05-29 15:07:00 MDT FATAL: nevarēja ielādēt pg_hba.conf 2013- 05-29 15:07:00 MDT LOG: šis būvējums neatbalsta vietējos savienojumus 2013-05-29 15:07:00 MDT KONTEKSTS: konfigurācijas faila "C:/PostgreSQL/data/pg_hba.conf" 2013. gada 1. rindiņa -05-29 15:07:00 MDT FATAL: nevarēja ielādēt pg_hba.conf 2013-05-29 15:09:03 MDT LOG: saņemts ātras izslēgšanas pieprasījums 2013-05-29 15:09:03 MDT LOG: pārtraukt jebkuru aktīvi darījumi 2013-05-29 15:09:03 MDT LOG: autovakuuma palaišanas iekārtas izslēgšana 2013-05-29 15:09:03 MDT LOG: izslēgšana 2013-05-29 15:09:03 MDT LOG: datu bāzes sistēma ir izslēgt

Šķiet, ka ir problēmas ar failu pg_hba.conf, kas izskatās šādi:

Lokālais all all trust viesot visus visus 127.0.0.1 255.255.255.255 uzticamus viesot visus visus 0.0.0.0 0.0.0.0 uzticības

Saskaņā ar daudziem ieteikumiem internetā, es mēģināju mainīt augšējo rindu uz vairākām dažādām alternatīvām (visi resursdatori uzticas visiem/uztur visus 127.0.0.1/32 uzticību/host all 192.168.0.100/24 ​​Trust utt.). Man tas bija jēga, jo žurnālfailā bija teikts, ka postgres neatbalsta vietējos savienojumus, kā arī norādīja uz šo līniju. Tomēr nevienai no manām izmaiņām nebija nekādas ietekmes. Es mēģināju restartēt datoru pēc katrām izmaiņām, taču nekas nemainījās.

Kad es meklēju piemērus tam, kā parasti izskatās fails pg_hba.conf, piemēri izskatījās nedaudz atšķirīgi no mana faila. Es pamanīju, ka programmas PostgreSQL failā papildus pg_hba.conf bija arī fails 20130529-150444-old-pg_hba.conf, kas daudz vairāk izskatījās kā piemēri, kurus atradu tiešsaistē. Šim failam ir vairākas komentāru rindiņas pirms šīm pēdējām rindām:

# TIPA DATU BĀZES LIETOTĀJA ADRESES METODE # IPv4 lokālie savienojumi: viesojiet visus 127.0.0.1/32 md5 # IPv6 lokālie savienojumi: viesojiet visus::1/128 md5 # Atļaut replikācijas savienojumus no localhost lietotājam ar # replikācijas privilēģiju. #host replikācija postgres 127.0.0.1/32 md5 #host replikācija postgres::1/128 md5

Es cerēju, ka šis ir sākotnējais pg_hba.conf fails, un, ja es aizstātu jauno failu ar vecā satura saturu, postgres atsāks darboties. Nav tādas veiksmes. Es cerēju, ka pg_log failā tiks reģistrēti vairāk kļūdu failu, lai redzētu, vai iepriekš ziņotā kļūda ir pazudusi vai kaut kas ir mainījies, bet vairāk faili netika reģistrēti.

Es vairākas dienas meklēju tiešsaistes pakalpojumu, un nekas, ko atradu, nedarbojās. Atvainojiet par šo garš jautājums, bet es gribēju būt rūpīgs un iekļaut visu nepieciešamo informāciju. Būšu pateicīgs, ja kāds varētu sniegt skaidrību par šo jautājumu vai sniegt ieteikumus.

Šī ziņa ir paredzēta galvenokārt man personīgi un mūsu atbalsta komandai, jo... Problēma, kas līdzīga tālāk aprakstītajai, rodas ar apskaužamu biežumu, un jums ir jāatceras pamata darbības, lai to atrisinātu.

Tātad, stāsts sākas ar to, ka 30. decembrī pulksten 11-30 saņēmu zvanu ar ziņojumu, ka viens no mūsu klientiem nepalaida mūsu sistēmu, jo nevar izveidot savienojumu ar datu bāzi (kā DBVS izmantojam PostgreSql versiju 8.1. ) . Cilvēki to skaidro ar to, ka pirms stundas nodzisa gaismas un nepareizi izslēdzās dators un pēc ieslēgšanas viss pārstāja darboties :)

Labi mūsu sistēmas lietotāji zina, kur atrodas starta poga, un zina, ka sistēmā nav divu pulksteņu, "viens ar cipariem un otrs ar smiltīm." Tāpēc vienīgais, ko varēju darīt pa tālruni, bija mēģināt manuāli palaist DBMS pakalpojumu, taču rezultāts bija tāds, ka pakalpojums netika startēts. Man bija jāpārsūta internets uz šo datoru (datoros, kuros ir instalēta mūsu interneta sistēma, tam nevajadzētu būt), lai varētu izveidot savienojumu attālināti.

Pēc savienojuma izveides ar attālais dators Mēģināju palaist pakalpojumu un saņēmu šādu ziņojumu: “Pakalpojums PostgreSql Database Server 8.1” uz “Local Computer” tika palaists un pēc tam apturēts. Daži pakalpojumi automātiski apstājas, ja tiem nav ko darīt, piemēram, pakalpojums Veiktspējas žurnāli un brīdinājumi. Hmm...

Problēma ir tāda, ka tajā laikā šī bija vienīgā pieejamā informācija... PostgreSql žurnāli ir tukši, tajos nav ierakstu, un arī sistēmas žurnāli ir tukši.

Atkļūdošanas pakalpojumi nav vienkāršs process, tāpēc daudzi izstrādātāji nodrošina pakalpojumu lietojumprogrammas palaišanas mehānismus, piemēram, parastu konsoles lietojumprogrammu, izmantojot taustiņus. komandrinda. Un PostgreSql šajā ziņā nav izņēmums; lai palaistu, ir jāizmanto šāda komanda (Padoms: šo komandu var palaist tikai no sistēmas lietotāja, kurš nav administratīvs, taču, ja par to aizmirstat, PostgreSql ļoti ātri par to atgādinās):

postgres -D " "

Mēs to palaižam un skatāmies kļūdas ziņojumu. Manā gadījumā ziņojums izklausījās apmēram šādi:

FATAL — viltus dati bloķēšanas failā "postmaster.pid"

Protams, man paveicās, problēma izrādījās labojama. Kāda iemesla dēļ norādītais fails izrādījās tukšs, un man vajadzēja nokopēt tā saturu no DBVS darba gadījuma, kas nebija grūti.

Šī ziņojuma morāle ir tāda, ka, ja datubāze ir neizdevusies vai radušās citas problēmas ar sistēmu, tad pirms DBVS (vai visas sistēmas) atkārtotas instalēšanas un visu datu zaudēšanas jums vismaz jāmēģina noskaidrot, kas problēma ir tā, iespējams, visas iespējas, ka jūs varēsit atjaunot savu veiktspēju, nav vienādas radikālos veidos.

ZY Laimīgu Jauno gadu visiem un novēlu, lai jūsu sistēmas ir stabilas un uzticamas un nesabojā jūsu miegu, taču pat tad, ja radās problēmas, jums vienmēr bija iespējas, kā rīkoties šajā situācijā.

Šī ziņa ir paredzēta galvenokārt man personīgi un mūsu atbalsta komandai, jo... Problēma, kas līdzīga tālāk aprakstītajai, rodas ar apskaužamu biežumu, un jums ir jāatceras pamata darbības, lai to atrisinātu.

Tātad, stāsts sākas ar to, ka 30. decembrī pulksten 11-30 saņēmu zvanu ar ziņojumu, ka viens no mūsu klientiem nepalaida mūsu sistēmu, jo nevar izveidot savienojumu ar datu bāzi (kā DBVS izmantojam PostgreSql versiju 8.1. ) . Cilvēki to skaidro ar to, ka pirms stundas nodzisa gaismas un nepareizi izslēdzās dators un pēc ieslēgšanas viss pārstāja darboties :)

Labi mūsu sistēmas lietotāji zina, kur atrodas starta poga, un zina, ka sistēmā nav divu pulksteņu, "viens ar cipariem un otrs ar smiltīm." Tāpēc vienīgais, ko varēju darīt pa tālruni, bija mēģināt manuāli palaist DBMS pakalpojumu, taču rezultāts bija tāds, ka pakalpojums netika startēts. Man bija jāpārsūta internets uz šo datoru (datoros, kuros ir instalēta mūsu interneta sistēma, tam nevajadzētu būt), lai varētu izveidot savienojumu attālināti.

Pēc savienojuma izveides ar attālo datoru es mēģināju palaist pakalpojumu un saņēmu šādu ziņojumu: “The PostgreSql Database Server 8.1 Service” uz “Local Computer” tika palaists un pēc tam apturēts. Daži pakalpojumi automātiski apstājas, ja tiem nav ko darīt, piemēram, pakalpojums Veiktspējas žurnāli un brīdinājumi. Hmm...

Problēma ir tāda, ka tajā laikā šī bija vienīgā pieejamā informācija... PostgreSql žurnāli ir tukši, tajos nav ierakstu, un arī sistēmas žurnāli ir tukši.

Atkļūdošanas pakalpojumi nav vienkāršs process, tāpēc daudzi izstrādātāji nodrošina pakalpojumu lietojumprogrammas palaišanas mehānismus, piemēram, parastu konsoles lietojumprogrammu, izmantojot komandrindas slēdžus. Un PostgreSql šajā ziņā nav izņēmums; lai palaistu, ir jāizmanto šāda komanda (Padoms: šo komandu var palaist tikai no sistēmas lietotāja, kurš nav administratīvs, taču, ja par to aizmirstat, PostgreSql ļoti ātri par to atgādinās):

postgres -D " "

Mēs to palaižam un skatāmies kļūdas ziņojumu. Manā gadījumā ziņojums izklausījās apmēram šādi:

FATAL — viltus dati bloķēšanas failā "postmaster.pid"

Protams, man paveicās, problēma izrādījās labojama. Kādu iemeslu dēļ norādītais fails izrādījās tukšs, un man vajadzēja nokopēt tā saturu no DBVS darba gadījuma, kas nebija grūti.

Šī ziņojuma morāle ir tāda, ka, ja datubāze ir neizdevusies vai radušās citas problēmas ar sistēmu, tad pirms DBVS (vai visas sistēmas) atkārtotas instalēšanas un visu datu zaudēšanas jums vismaz jāmēģina noskaidrot, kas Problēma ir tāda, ka, iespējams, ir visas iespējas, lai jūs varētu atjaunot savu funkcionalitāti mazāk radikālā veidā.

ZY Laimīgu Jauno gadu visiem un novēlu, lai jūsu sistēmas ir stabilas un uzticamas un nesabojā jūsu miegu, taču pat tad, ja radās problēmas, jums vienmēr bija iespējas, kā rīkoties šajā situācijā.