[英]Postgres 10.3 could not bind IPv6 address, database system was not properly shut down
I am running Postgres v10.3 through Docker (docker-compose, specifically). 我正在通过Docker(特别是docker-compose)运行Postgres v10.3。 It is not turning back on. 它没有重新打开。 I get the following error message when I try to turn it on: 我尝试将其打开时收到以下错误消息:
postgres | pg_ctl: another server might be running; trying to start server anyway
postgres | waiting for server to start....2018-05-15 12:37:07.552 UTC [22] LOG: listening on IPv4 address "127.0.0.1", port 5432
postgres | 2018-05-15 12:37:07.552 UTC [22] LOG: could not bind IPv6 address "::1": Address not available
postgres | 2018-05-15 12:37:07.552 UTC [22] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
postgres | 2018-05-15 12:37:07.558 UTC [22] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres | 2018-05-15 12:37:07.804 UTC [23] LOG: database system was interrupted while in recovery at 2018-05-15 12:35:58 UTC
postgres | 2018-05-15 12:37:07.804 UTC [23] HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
postgres | .........2018-05-15 12:37:17.735 UTC [23] LOG: database system was not properly shut down; automatic recovery in progress
postgres | .2018-05-15 12:37:17.935 UTC [23] LOG: redo starts at 1/5E964BA8
postgres | pg_ctl: server did not start in time
postgres | ................................................. stopped waiting
I may have shut down the database as I was writing to it, which is the only thing I can think of that would have caused this. 我可能在写数据库时已经关闭它,这是我唯一想到的可能导致此问题的原因。 I do not have a backup which is why I'd like to restore what I've already done (except for the table that I was writing to when I shut down). 我没有备份,这就是为什么我想要恢复已经完成的工作的原因(关闭时正在写入的表除外)。
Things I've tried: 我尝试过的事情:
Restarting the docker container and clearing out the cache ( docker system prune -f
) 重新启动Docker容器并清除缓存( docker system prune -f
)
Remove the postmaster.pid
file and restarting 删除postmaster.pid
文件并重新启动
could not open file "postmaster.pid": No such file or directory
error and generates a postmaster.pid
file which then allows me to get back to my original error 这给了我一个could not open file "postmaster.pid": No such file or directory
错误,并生成了一个postmaster.pid
文件,该文件随后使我回到了原来的错误状态 When running in single_user_mode
with more logging I get 当在single_user_mode
运行并记录更多日志时,我得到
/ $ postgres --single -D /var/lib/postgresql/data/pgdata -P -d 5
2018-05-15 15:16:09.978 UTC [12] DEBUG: invoking IpcMemoryCreate(size=148537344)
2018-05-15 15:16:09.978 UTC [12] DEBUG: mmap(148897792) with MAP_HUGETLB failed, huge pages disabled: Out of memory
2018-05-15 15:16:09.999 UTC [12] DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
2018-05-15 15:16:09.999 UTC [12] DEBUG: removing file "pg_notify/0000"
2018-05-15 15:16:10.005 UTC [12] DEBUG: dynamic shared memory system will support 288 segments
2018-05-15 15:16:10.005 UTC [12] DEBUG: created dynamic shared memory control segment 262836907 (6928 bytes)
2018-05-15 15:16:10.005 UTC [12] DEBUG: InitPostgres
2018-05-15 15:16:10.005 UTC [12] DEBUG: my backend ID is 1
2018-05-15 15:16:10.010 UTC [12] LOG: database system was shut down in recovery at 2018-05-15 15:16:04 UTC
2018-05-15 15:16:10.014 UTC [12] DEBUG: checkpoint record is at 1/64CA6F18
2018-05-15 15:16:10.025 UTC [12] DEBUG: redo record is at 1/5E964BA8; shutdown FALSE
2018-05-15 15:16:10.025 UTC [12] DEBUG: next transaction ID: 0:681710; next OID: 311511
2018-05-15 15:16:10.025 UTC [12] DEBUG: next MultiXactId: 155; next MultiXactOffset: 312
2018-05-15 15:16:10.025 UTC [12] DEBUG: oldest unfrozen transaction ID: 547, in database 1
2018-05-15 15:16:10.025 UTC [12] DEBUG: oldest MultiXactId: 1, in database 1
2018-05-15 15:16:10.025 UTC [12] DEBUG: commit timestamp Xid oldest/newest: 0/0
2018-05-15 15:16:10.025 UTC [12] DEBUG: transaction ID wrap limit is 2147484194, limited by database with OID 1
2018-05-15 15:16:10.025 UTC [12] DEBUG: MultiXactId wrap limit is 2147483648, limited by database with OID 1
2018-05-15 15:16:10.025 UTC [12] DEBUG: starting up replication slots
2018-05-15 15:16:10.028 UTC [12] DEBUG: starting up replication origin progress state
2018-05-15 15:16:10.031 UTC [12] LOG: database system was not properly shut down; automatic recovery in progress
2018-05-15 15:16:10.037 UTC [12] DEBUG: resetting unlogged relations: cleanup 1 init 0
2018-05-15 15:16:10.334 UTC [12] LOG: redo starts at 1/5E964BA8
My dockerfile extends this one: https://github.com/docker-library/postgres/blob/fe8c9a4a309a889dc057d53bf3769c25c1522c65/10/alpine/Dockerfile 我的dockerfile扩展了这一点: https : //github.com/docker-library/postgres/blob/fe8c9a4a309a889dc057d53bf3769c25c1522c65/10/alpine/Dockerfile
And the entrypoint is changed to be this: https://github.com/docker-library/postgres/blob/fe8c9a4a309a889dc057d53bf3769c25c1522c65/10/alpine/docker-entrypoint.sh 入口点更改为: https : //github.com/docker-library/postgres/blob/fe8c9a4a309a889dc057d53bf3769c25c1522c65/10/alpine/docker-entrypoint.sh
And here's the ifconfig
: 这是ifconfig
:
MacBook-Pro:backend zebrainatree$ docker-compose demo run postgres ifconfig -a
eth0 Link encap:Ethernet HWaddr 02:42:AC:12:00:03
inet addr:172.18.0.3 Bcast:172.18.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:90 (90.0 B) TX bytes:0 (0.0 B)
ip6tnl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
NOARP MTU:1452 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
tunl0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-10-8B-00-00-00-00-00-00-00-00
NOARP MTU:1480 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
We got it to work by entering the postgres docker container via bash
, then su postgres
, and finally postgres --single -D /var/lib/postgresql/data/pgdata -P -d 5
我们通过bash
输入postgres docker容器使其工作,然后使用su postgres
,最后是postgres --single -D /var/lib/postgresql/data/pgdata -P -d 5
It took about 15 minute from there, but it worked! 从那儿花了大约15分钟,但成功了!
I don't think there is anything to worry about: 我认为没有什么可担心的:
could not bind IPv6 address "::1": Address not available
That means that getaddrinfo
returned ::1
as an IP address for localhost
, but IPv6 is not working. 这意味着getaddrinfo
返回::1
作为localhost
的IP地址,但是IPv6无法正常工作。
Your DNS setup is misconfigured, but it is no big problem — you just cannot connect to the loopback interface with IPv6. 您的DNS设置配置错误,但这没什么大问题-您无法使用IPv6连接到环回接口。
waiting for server to start.....stopped waiting
Startup took longer than pg_ctl
cared to wait. 启动花费了比pg_ctl
更长的等待时间。 Annoying, but no problem per se. 烦人,但本身没有问题。 See the next point. 参见下一点。
You should always consult the PostgreSQL log in such a case. 在这种情况下,您应始终查阅PostgreSQL日志。
LOG: database system was interrupted while in recovery at 2018-05-15 12:35:58 UTC HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
This just means you have been impatient and interrupted a previous startup attempt, didn't you? 这只是意味着您已经不耐烦并且中断了先前的启动尝试,不是吗?
The hint is there, because if that happens without a panicky sysadmin interrupting the startup process , it probably means that recovery crashed, possibly because of bad data in database files. 那里有提示,因为如果在没有紧急的系统管理员中断启动过程的情况下发生这种情况,则可能意味着恢复失败,这可能是由于数据库文件中的错误数据所致。
15 minutes for crash recovery is not short. 15分钟的崩溃恢复时间并不短。
Perhaps there was a lot of activity since the last checkpoint (and max_wal_size
is set very high), perhaps you got really slow disks, perhaps your restrictive cgroups settings give you too few resources... 自上一个检查点以来,也许有很多活动(并且max_wal_size
设置得很高),也许您的磁盘速度很慢,也许您的限制性cgroups设置给您提供的资源太少了...
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.