OSX El Capitan sqlalchemy无法连接到'127.0.0.1'(111)

问题描述:

上的MySQL服务器此应用程序中的python运行于Docker容器中。容器正在网络模式下运行:“主机”。OSX El Capitan sqlalchemy无法连接到'127.0.0.1'(111)

我无法通过python包sqlalchemy连接到MySQL数据库。我收到以下错误。

OperationalError: (OperationalError) (2003, "Can't connect to MySQL server on '127.0.0.1' (111)") None None

下面的终端命令工作正常

mysql -h 127.0.0.1 -u my_user --password='password' db -e "SHOW TABLES;" 
enter code here 

也许SQLAlchemy的是没有使用正确的配置你说什么?我已经打印出来调试行配置中的第一个连接到MySQL前右:

print config.get('repository', 'host') // 127.0.0.1 
    print config.get('repository', 'user') // my_user 
    print config.get('repository', 'passwd') // password 

也许这配置仍然没有使它成为SQLAlchemy的?让我们打印出引擎字符串

engine = getUnaffiliatedEngine() 
    print engine //Engine(mysql://my_user:***@127.0.0.1:3306) 
    with engine.connect() as connection: 
    for s in statements: 
     if s.strip(): 
     connection.execute(s) 

也许有超过1个版本的mysql正在运行?只有一个进程在运行:

ps -ef | grep mysql 

74 15459 1 0 10:14AM ?? 0:00.80 /usr/local/mysql/bin/mysqld --user=_mysql

也许该用户不具有对数据库的访问?

mysql> select User, Host from mysql.user; 

+------+--------------------------+ 
| User | Host      | 
+------+--------------------------+ 
|my_user 127.0.0.1    | 
| root | 127.0.0.1    | 
| root | ::1      | 
|  | localhost    | 
| root | localhost    | 
+------+--------------------------+ 

同样'show databases'显示数据库存在。我已经为每个数据库授予了该用户的所有权限。我也冲过了这些诡计。

也许某种防火墙规则正在停止连接?我使用了小小的snitch,并且整个防火墙已经被取下来测试这个。

我甚至不知道还有什么要调试的。下面是python脚本的抛出连接错误的简化版本:

DSN_FORMAT = "mysql://%(user)s:%(passwd)[email protected]%(host)s:%(port)s" 

def getDSN(): 
    return DSN_FORMAT % dict(config.items("repository")) 

def getUnaffiliatedEngine(): 
    return create_engine(getDSN()) 

def reset(offline=False): 
    config.loadConfig() 
    dbName = config.get('repository', 'db') 
    print config.get('repository', 'host') 
    print config.get('repository', 'user') 
    print config.get('repository', 'passwd') 

    resetDatabaseSQL = (
     "DROP DATABASE IF EXISTS %(database)s; " 
     "CREATE DATABASE %(database)s;" % {"database": dbName}) 
    statements = resetDatabaseSQL.split(";") 

    engine = getUnaffiliatedEngine() 
    print engine 
    with engine.connect() as connection: 
    for s in statements: 
     if s.strip(): 
     connection.execute(s) 

这里是输出tcpdump -i lo0 port 3306

11:44:41.224036 IP localhost.58797 > localhost.mysql: Flags [P.], seq 3915736486:3915736498, ack 2134634265, win 12519, options [nop,nop,TS val 980567261 ecr 980503692], length 12 
11:44:41.224105 IP localhost.mysql > localhost.58797: Flags [.], ack 12, win 12737, options [nop,nop,TS val 980567261 ecr 980567261], length 0 
11:44:41.224178 IP localhost.mysql > localhost.58797: Flags [P.], seq 1:19, ack 12, win 12737, options [nop,nop,TS val 980567261 ecr 980567261], length 18 
11:44:41.224218 IP localhost.58797 > localhost.mysql: Flags [.], ack 19, win 12519, options [nop,nop,TS val 980567261 ecr 980567261], length 0 
11:45:07.422776 IP localhost.58796 > localhost.mysql: Flags [P.], seq 2953728354:2953728366, ack 432872138, win 12483, options [nop,nop,TS val 980593366 ecr 980533534], length 12 
11:45:07.422807 IP localhost.mysql > localhost.58796: Flags [.], ack 12, win 12729, options [nop,nop,TS val 980593366 ecr 980593366], length 0 
11:45:07.422856 IP localhost.mysql > localhost.58796: Flags [P.], seq 1:19, ack 12, win 12729, options [nop,nop,TS val 980593366 ecr 980593366], length 18 
11:45:07.422877 IP localhost.58796 > localhost.mysql: Flags [.], ack 19, win 12482, options [nop,nop,TS val 980593366 ecr 980593366], length 0 

的MySQL 5.6 OSX埃尔卡皮坦10.11.6

+1

你能显示给出错误的实际代码吗?或者至少是一个简化版本。 –

+0

我同意@ gsi-frank--一个简单的SQLAlchemy引擎和[连接设置(如其文档中的连接设置)]的示例(http://docs.sqlalchemy.org/en/latest/core/connections.html# module-sqlalchemy.engine)在这里会很有帮助(既可以简化调试,又可以解决SO中的问题)。 –

+0

@ gsi-frank done –

这最后你写的评论非常重要,可能是问题的原因。

我很确定你的Docker容器有自己的loopback接口,其地址127.0.0.1与你的OSX环回接口不同,你在这里运行MySQL。

我建议你把你的MySQL监听放在容器内可见的地址上。您可以轻松地调试该配置,从容器内轻松制作telnet ip_address 3306

+0

如果有人绊倒这一点,使用--network ='主机'在OSX上的Docker不按预期工作,它不会被固定泊坞窗。 OSX上的Docker使用虚拟机,--network ='host'参数在这里完全被破坏。通过阅读Docker论坛上的评论,该问题被忽略,并且不会有任何努力来解决这个问题。 –