我正在kubernetes应用程序中为Apache Cassandra使用Datastax's c++ driver version 2.8.0。通过此Helm chart，将Cassandra部署为3节点群集。
该图表利用kubernetes的无头服务使Cassandra端点可用，因此kubernetes DNS中有一个针对这些端点的条目。
我有一个运行在与Cassandra交互的kubernetes容器中的c ++应用，该容器使用该DNS条目进行连接以解析端点。该应用程序具有遵循驱动程序使用指南的与Cassandra对象的单一连接。连接在程序的开始处初始化，如果初始化连接失败或稍后再执行查询，则实际上会使程序失败。
一切正常，但是由于某种原因，cassandra节点/豆荚可能最终崩溃。发生这种情况时，会重新生成它们，但会使用其他IP重新分配它们。看来c ++驱动程序能够从DNS获取新端点，而无需任何其他代码。但是，在这种情况下，客户端上的连接没有关闭，并且看起来以前的端点在某种程度上仍保留在连接池中。这将导致一系列类似于以下内容的日志事件：
1531920921.161 [WARN] (src/pool.cpp:420:virtual void cass::Pool::on_close(cass::Connection*)): Connection pool was unable to reconnect to host XXX.XXX.XXX.XX because of the following error: Connection timeout
和
1531920921.894 [WARN] (src/pool.cpp:420:virtual void cass::Pool::on_close(cass::Connection*)): Connection pool was unable to reconnect to host XXX.XXX.XXX.XX because of the following error: Connect error 'host is unreachable'
每个[重新连接超时]都会弹出一次。 IP重新分配的次数越多，日志消息就越多，您可以猜到，对于寿命长的应用程序，日志消息数量会很多。
驱动程序的API是否有某些功能可以处理？还是更普遍的处理该客户端的好方法？驱动程序外部的一个选项可能是在客户端代码内重置连接，但是（尽管我可能会漏掉），但我看不到“捕获”此类事件的方法：它们仅显示在日志中。 / p>