【问题标题】:pg_dump: "could not connect to server" in Rails "schema_format = :sql" migrationpg_dump:Rails“schema_format = :sql”迁移中的“无法连接到服务器”
【发布时间】:2012-11-01 03:07:34
【问题描述】:

到目前为止,在我的 rails 应用程序 (v 3.2.8) 中,我使用迁移没有问题。

我使用 PostgreSQL 9.2 作为数据库。我调整了我的 application.rb 以使用 sql 而不是模式转储程序(未注释 config.active_record.schema_format = :sql)。

之后,我开始在迁移时收到此错误:

    $ rake db:migrate

    [ALL MIGRATION STUFF IS PRINTED HERE]

    pg_dump: [archiver (db)] connection to database "my_dev_db" failed: could not connect to server: Connection refused
        Is the server running on host "localhost" (::1) and accepting
        TCP/IP connections on port 5432?
    could not connect to server: Connection refused
        Is the server running on host "localhost" (127.0.0.1) and accepting
        TCP/IP connections on port 5432?
    could not connect to server: Connection refused
        Is the server running on host "localhost" (fe80::1) and accepting
        TCP/IP connections on port 5432?
    rake aborted!
    Error dumping database

I tried manually on the command line(logged in as the same user on my Mac)

<!-- language: lang-sh -->

    $ pg_dump my_dev_db > /tmp/db.sql

No problems with that...happily dumps into `/tmp/db.sql`

Why is rails having trouble with `pg_dump`? (I am on Mac OSX Lion)

===========

Adding more diagnosis information

===========

    $tail -10 /usr/local/var/postgres9.2/pg_hba.conf 

    local   all             all                                     md5
    # IPv4 local connections:
    host    all             all             127.0.0.1/32            md5
    # IPv6 local connections:
    host    all             all             ::1/128                 md5
    # Allow replication connections from localhost, by a user with the
    # replication privilege.
    #local   replication     rogert                                trust
    #host    replication     rogert        127.0.0.1/32            trust
    #host    replication     rogert        ::1/128                 trust


    $ sudo lsof -p 62444 | awk '$5 == "unix" && $NF ~ /\// { print $NF }'
    /tmp/.s.PGSQL.5432

    $ ps auxw | grep post
    postgres        1403   0.0  0.0  2435492    640 s007  S+   21Oct12   0:00.05 bash
    root            1401   0.0  0.0  2498096    128 s007  S    21Oct12   0:00.02 su postgres
    rogert  62517   0.0  0.0  2426700    388 s001  R+    9:21PM   0:00.00 grep post
    rogert  62448   0.0  0.0  2481656    500   ??  Ss    8:46PM   0:00.03 postgres: wal writer process     
    rogert  62447   0.0  0.0  2481656    752   ??  Ss    8:46PM   0:00.07 postgres: writer process     
    rogert  62446   0.0  0.0  2481656   1040   ??  Ss    8:46PM   0:00.00 postgres: checkpointer process     
    rogert  62444   0.0  0.1  2481656   5368 s001  S     8:46PM   0:00.02 /usr/local/Cellar/postgresql/9.2.1/bin/postgres -D /usr/local/var/postgres9.2


    $ rake db:migrate --trace

    [ALL MIGRATION STUFF IS PRINTED HERE]

    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/activerecord-3.2.8/lib/active_record/railties/databases.rake:393:in `block (3 levels) in <top (required)>'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
    /Users/rogert/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/activerecord-3.2.8/lib/active_record/railties/databases.rake:162:in `block (2 levels) in <top (required)>'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `block in execute'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
    /Users/rogert/.rvm/gems/ruby-1.9.3-p194@rails_3.2.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `block in invoke_with_call_chain'
    /Users/rogert/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/1.9.1/monitor.rb:211:in `mon_synchronize'

$sudo vi /usr/local/var/postgres9.2/postgresql.conf

[search for listen address]

# - Connection Settings -

listen_addresses = 'localhost'          # what IP address(es) to listen on;
                                        # comma-separated list of addresses;
                                        # defaults to 'localhost'; use '*' for all
                                        # (change requires restart)
port = 5432                             # (change requires restart)
max_connections = 100                   # (change requires restart)

奇怪的是,如果我从我的 rails 应用程序中完全删除这两行,迁移就可以工作。因此,如果它是 TCP 连接和侦听的问题,迁移本身是如何工作的(但一旦我再次打开这两个就不会)

  1. application.rb - config.active_record.schema_format = :sql
  2. 在我的一个迁移文件中 - t.hstore :attributes

【问题讨论】:

  • 你测试的不是同一个东西;正如@Tom 所说,pg_dump 默认使用 unix 域套接字而不是 TCP/IP。尝试运行 pg_dump -h 127.0.0.1 -p 5432 my_dev_Db &gt; /tmp/db.sql 。运行正常吗?
  • 在 Mac OS X 上,使用 sudo lsof -i -P | grep -i "listen" 列出正在侦听的 TCP/IP 端口。在您的情况下,您对 sudo lsof -i -P | grep -i "listen" |grep postgressudo lsof -i -P | grep -i "listen" | grep 5432 感兴趣。

标签: ruby-on-rails postgresql rails-migrations


【解决方案1】:

您的 PostgreSQL 实例很可能配置为不侦听 TCP/IP,至少在 localhost 上。

postgresql.conf 中检查listen_addresses。见the documentation。很可能它设置为''(空字符串),因此服务器仅侦听 UNIX 域套接字。

psqlpg_dump 等如果 Pg 没有在 TCP/IP 上侦听,它们仍然可以工作,因为它们默认连接到本地 unix 域套接字。 Ruby pg gem 是 libpq 的包装器,psql 等使用相同的客户端库,并且它还默认使用 unix 域套接字,除非明确指定连接参数。

但是,Rails 似乎将明确的 IP 地址传递给 pg_dump - 导致它尝试通过 TCP/IP 进行连接,而 Pg 似乎没有在监听,从而导致观察到的“连接被拒绝”错误。

另外,您的 PostgreSQL 可能被编译为默认到 5432 以外的端口。相同的设置被编译为 libpq 中的默认设置,因此它会自动连接到新端口。但是,如果 Rails 在尝试运行它时指定一个显式端口到 pg_dump,它会优先使用该端口而不是内置默认值。检查postgresql.conf中的port指令;如果它没有被注释掉或设置为5432,这可能是你的问题。 port 指令记录在与上面链接的同一页面中。

顺便说一句,要在 Pg 运行时定位 postgresql.conf 运行 psql template1 -c "SHOW config_file;"

【讨论】:

  • $ psql template1 -c "SHOW config_file;" config_file -------------------------------------------- /usr/local/ var/postgres9.2/postgresql.conf (1 行)
  • 另外,运行 lsof 监听端口,显示 postgres 正在监听 5432。 [[postgres 62706 rogert 5u IPv6 0xffffff8013361800 0t0 TCP localhost:5432 (LISTEN) postgres 62706 rogert 6u IPv4 0xffffff801bd08880 00 5432 (LISTEN) postgres 62706 rogert 7u IPv6 0xffffff8013361bc0 0t0 TCP localhost:5432 (LISTEN)]]
  • @BVSat 好的...这是您需要查看的文件。我发布它不是因为需要信息,而是因为我认为可能;我经常看到人们不知道如何找到postgresql.conf 的问题。
  • @BVSat 很奇怪,它似乎正在监听 localhost:5432。这只是从有点奇怪变成了非常奇怪的土地。我仍然会检查postgresql.conf 中的portlisten_addresses 指令,但这很奇怪。也许您以某种方式在环回接口上激活了防火墙?有外挂安全软件、网络过滤软件等吗?
  • 谢谢。但看起来 postgres 正在侦听 5432,迁移与模式转储器一起使用,postgresql.conf 的 listen_address 为“localhost”,端口 5432 未注释....所以我还能做些什么去找出原因。跨度>
【解决方案2】:

事实证明,根本原因是第 3 方防火墙包认为过滤本地环回接口上的连接是个好主意。

the comments thread

【讨论】:

    【解决方案3】:

    pg_dump 从命令行将使用 UNIX 域套接字访问 PostgreSQL,而 rails 工具正在尝试创建到 localhost 的 TCP 连接。

    查看您的 pg_hba.conf(对我来说,这是在 /var/lib/pgsql/data/ 中)并检查是否有这样一行,其中 md5 表示将使用密码验证:

    host    all         all         127.0.0.1/32          md5
    

    (如果您要在生产环境中运行它,请确保您完全理解这一点!)

    您可以通过在运行 pg_dump 时在命令行上显式指定 -h localhost 来测试通过 TCP 的连接。如果您对 pg_hba.conf 进行任何更改,请记住重新启动 PostgreSQL。

    【讨论】:

    • 似乎没有用。奇怪的。首先,我不知道 rails 的连接方式和 pg_dump 的连接方式之间的区别。如果我使用带有 -h localhost 选项的 pg_dump,我会得到同样的错误。所以这完全排除了rails。但我的问题仍然存在。到目前为止,这就是我所看到的(请参阅我原来的帖子中的其他诊断)
    • 如果是 pg_hba.conf 问题,错误将是来自 Pg 服务器的报告,即用户/db/host 组合没有 pg_hba.conf 条目。这是connection refused,所以问题是服务器没有在监听。第一个和最后一个标准杆是正确的,但pg_hba.conf 的建议不适用于此处。
    • 添加了更多诊断信息 - 仍然是同样的错误。更改后我确实重新启动了服务器
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-12-19
    • 1970-01-01
    • 2021-09-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多