OperationalError:1047(08S01)求助：Python远程取数遇WSREP未就绪报错

我之前处理过几乎一模一样的问题，给你分享下我的排查方向和实际解决的办法，应该能帮到你：

首先先拆解下这个错误：OperationalError: 1047 (08S01): WSREP has not yet prepared node for application use，WSREP是Galera集群（比如Percona XtraDB Cluster、MariaDB Galera Cluster）的同步组件，这个错误的核心意思是你连接的数据库节点还没完成集群数据同步，暂时无法处理应用层的请求。

那为什么DBeaver能正常运行，Python程序却报错？主要是两者的连接/查询逻辑有差异，下面分点说：

1. 连接池的“旧连接”坑 #

Python程序如果用了连接池（比如SQLAlchemy、pymysql的连接池），之前建立的连接可能在集群节点重启/同步中断后，没有被自动回收。这些旧连接依然指向未同步完成的节点，而DBeaver每次都是新建连接，会自动连接到集群中已就绪的节点。

解决办法：

• 临时方案：直接重启你的Python程序，让连接池重新建立新连接
• 长期方案：给连接池配置健康检查逻辑，比如每次获取连接前执行SELECT 1，如果执行失败就丢弃该连接并重新建立；或者设置连接池的最大空闲时间，定期回收旧连接。

2. 查询量级的差异触发了限制 #

你的Python程序是一次性获取5M+条数据，这种大查询会占用大量的节点资源，可能刚好触发了集群对未同步节点的请求拦截；而DBeaver默认是分页加载数据（比如只显示前1000条），资源占用低，没触发这个限制。

解决办法：
把Python的查询改成分页获取，比如每次查询1000-5000条数据，循环处理。示例代码大概是这样：

offset = 0
batch_size = 1000
while True:
    query = f"SELECT * FROM your_table LIMIT {batch_size} OFFSET {offset}"
    # 执行查询、处理数据
    result = cursor.execute(query).fetchall()
    if not result:
        break
    offset += batch_size

3. 连接的节点不一致 #

你的Python程序可能连接到了集群中未同步的从节点，而DBeaver连接的是已就绪的主节点。比如集群有负载均衡的话，可能负载均衡把Python的请求分发到了状态异常的节点。

解决办法：

• 先检查Python程序的数据库连接地址，是不是直接指向了某个特定节点？如果是，换成集群的主节点地址试试
• 如果用了负载均衡，查看负载均衡的配置，确保只把请求转发给wsrep_ready=ON的节点

4. 数据库驱动的版本/配置差异 #

Python用的MySQL驱动（比如mysql-connector-python、pymysql）和DBeaver用的驱动版本不同，对WSREP状态的处理逻辑有区别。旧版本驱动可能不会自动重试连接到正常节点，而DBeaver的驱动会自动处理。

解决办法：

• 升级Python的MySQL驱动到最新版本：pip install --upgrade mysql-connector-python（根据你用的驱动调整命令）
• 在连接参数里加上自动重连配置，比如connect_timeout=10、reconnect=True（不同驱动参数名可能有差异，查对应驱动的文档）

5. 集群节点的临时状态 #

当时你运行Python程序的时候，集群可能正处于节点重启、数据同步的过程中，等你用DBeaver查询的时候，节点刚好完成同步了。

验证方法：
登录数据库执行以下命令，查看节点状态：

SHOW STATUS LIKE 'wsrep%';

重点看这几个参数：

• wsrep_ready：值为ON才表示节点就绪
• wsrep_cluster_status：值为Primary表示集群正常
• wsrep_local_state_comment：值为Synced表示节点已完成同步

如果某个节点的wsrep_ready是OFF，那连接到这个节点的请求就会报错。

内容的提问来源于stack exchange，提问作者AB_luck