使用 AWS Aurora 数据库集群
这个页面提供了有关使用 Amazon Aurora 集群作为 TeamCity 数据库服务器的详细信息。
在使用 AWS Aurora 集群并将 TeamCity 指向 集群端点作为数据库服务器时，理解 AWS Aurora 集群发生故障转移时会发生什么非常重要。
两个 AWS Aurora DB 实例都已重新启动（所以在短暂时间内，TeamCity 完全失去了与集群的连接）并且
原始 DB 实例以只读模式启动（新的读取器实例）；
前面的故障转移实例现在是新的写入器，群集端点 DNS 记录已更改为指向新的写入器实例。
默认情况下，TeamCity JVM 会缓存 DNS 名称查找，这基本上意味着 TeamCity 将一直保持与原始 DB 实例的连接，直到 DNS 缓存过期。 这反过来导致 TeamCity 端的数据库连接池填充了指向新读取器的连接。
需要一些时间让 TeamCity 中的 JVM 特定缓存过期，并从池中清除无效的连接。
一般建议
在使用故障转移集群时，建议在 TeamCity 上降低 JVM 特定的 DNS 缓存 通过将 TTL 设置为 60：
将
-Dsun.net.inetaddr.ttl=60JVM 选项添加到 环境变量 中。为了使更改生效，请重新启动 TeamCity。
强制 TeamCity 连接到新的写入器
您可以强制 TeamCity 手动或自动地连接到新的 writer。
要强制手动连接：
再次重启新的 DB 读取器实例：重启将需要多达 2 分钟的时间，这对于 DNS 缓存的过期以及从池中驱逐无效连接来说已经足够。
或者，手动重新启动 TeamCity，所有的连接都将被重新创建。
为了使 TeamCity 能够在新的主实例启动并运行后立即自动连接到该实例：
配置数据库连接池以使用特殊的验证查询，以便在使用前和/或使用后测试到 DB 实例的连接，如果检测到到只读数据库的连接，它们将从池中删除。为此，在以下线路中添加以下内容到 database.properties：对于 Aurora MySQL：
testOnBorrow=true testOnReturn=true testWhileIdle=true timeBetweenEvictionRunsMillis=60000 validationQuery=select case when @@read_only + @@innodb_read_only \= 0 then 1 else (select table_name from information_schema.tables) end as `1`对于 Aurora PostgreSQL：
testOnBorrow=true testOnReturn=true testWhileIdle=true timeBetweenEvictionRunsMillis=60000 validationQuery=select case when not pg_is_in_recovery() then 1 else random() / 0 end重启 TeamCity 服务器。 一旦您执行了这个操作，指定的验证查询将会在所有连接被借出或归还到池时，以及对空闲连接每1分钟（60000毫秒）执行一次，并且对只读数据库的每一个连接都会引发一个错误。
使用 SSL 连接到 Aurora MySQL 集群
自 Amazon Aurora MySQL 版本 2（与 MySQL 5.7 及更高版本兼容）起，您可以通过运行相应的查询确定 TeamCity 是否使用安全的 SSL 连接到您的 DB 集群。 如有必要，您可以在 Amazon 服务器端更改 连接模式。
如果您正在使用 Amazon Aurora MySQL 版本 1（与 MySQL 5.6 及更低版本兼容），您可以通过使用像 tcpdump.
这样的分组分析器检查 TeamCity 和 DB 集群之间的连接是否安全。要更改 SSL 连接的模式（例如，强制执行或禁用它），请将相应的 sslMode 参数传递给 MySQL Connector/J JDBC 驱动程序，方法是将其添加到 <TeamCity 数据目录>/config/database.properties 文件中。
或者添加一行独立的代码：
connectionProperties.sslMode=<value>或者
将
?sslMode=<值>参数添加到连接字符串中。 例如：connectionUrl=jdbc:mysql://<hostname>:3306/<dbname>?sslMode=<value>
请查看 Connector/J 配置属性 中支持的连接模式值列表。