JDBC驱动对时间戳的版本适配和中间件相关注意点

背景

业务在使用测试中,发现自己配置的MySQL表,某些时间字段的精度被截取了。因为使用了公司的中间层,怀疑是中间层导致的。同时经过对比,和业务正常使用的MySQL5.7是没有类似问题的。因此和业务进行了分析。

分析

首先,正如前面所描述,问题是MySQL表字段的时间精度在处理后降低了,某些小数秒的时间被截断了。经过分析得知是MySQL在5.6.4以后才支持了更高精度的时间表示。同样,在mysql-connector-java:5.1.23里,对这个进行了适配,如果获取的MySQL版本是5.6.4及以上的,则保持精度,否则截取精度。具体的实现是在com.mysql.jdbc.PreparedStatement#detectFractionalSecondsSupport,可以参考这个连接jdbc fractional seconds

    protected void detectFractionalSecondsSupport() throws SQLException {
        this.serverSupportsFracSecs = this.connection != null && this.connection.versionMeetsMinimum(5, 6, 4);
    }

所以,这里要支持小数秒,对应的MySQL服务版本要至少是5.6.4

解决

再回到业务提供的问题,经过排查,发现业务在进入我们的数据库中间件之后,获得的实际版本是5.5。而在我们的中间件执行select version(),获取到的是实际后端MySQL实例的版本号5.7.25-log。再观察后知道jdbc驱动中保存的版本是在建立连接,镜像账号握手阶段读取的,具体可以在抓包中查看到具体字段。实际的代码实现可以参考如下代码:

/**
     * Initialize communications with the MySQL server. Handles logging on, and
     * handling initial connection errors.
     *
     * @param user DOCUMENT ME!
     * @param password DOCUMENT ME!
     * @param database DOCUMENT ME!
     *
     * @throws SQLException DOCUMENT ME!
     * @throws CommunicationsException DOCUMENT ME!
     */
    void doHandshake(String user, String password, String database)
        throws SQLException {
        // Read the first packet
        this.checkPacketSequence = false;
        this.readPacketSequence = 0;

        Buffer buf = readPacket();

        // Get the protocol version
        this.protocolVersion = buf.readByte();

        if (this.protocolVersion == -1) {
            try {
                this.mysqlConnection.close();
            } catch (Exception e) {
                // ignore
            }

            int errno = 2000;

            errno = buf.readInt();

            String serverErrorMessage = buf.readString("ASCII", getExceptionInterceptor());

            StringBuffer errorBuf = new StringBuffer(Messages.getString(
                        "MysqlIO.10")); //$NON-NLS-1$
            errorBuf.append(serverErrorMessage);
            errorBuf.append("\""); //$NON-NLS-1$

            String xOpen = SQLError.mysqlToSqlState(errno,
                    this.connection.getUseSqlStateCodes());

            throw SQLError.createSQLException(SQLError.get(xOpen) + ", " //$NON-NLS-1$
                 +errorBuf.toString(), xOpen, errno, getExceptionInterceptor());
        }

        this.serverVersion = buf.readString("ASCII", getExceptionInterceptor());

        // Parse the server version into major/minor/subminor
        int point = this.serverVersion.indexOf('.'); //$NON-NLS-1$

        if (point != -1) {
            try {
                int n = Integer.parseInt(this.serverVersion.substring(0, point));
                this.serverMajorVersion = n;
            } catch (NumberFormatException NFE1) {
                // ignore
            }

            String remaining = this.serverVersion.substring(point + 1,
                    this.serverVersion.length());
            point = remaining.indexOf('.'); //$NON-NLS-1$

            if (point != -1) {
                try {
                    int n = Integer.parseInt(remaining.substring(0, point));
                    this.serverMinorVersion = n;
                } catch (NumberFormatException nfe) {
                    // ignore
                }
                
                //以下省略... 

这里的majorVersion 即 5代表MySQL 5, minorVersion即 MySQL 5.6 以上的6。再看看我们的数据库代理中间层,刚好有个server_version的配置,可以定制和客户jdbc交互的时候的MySQL版本比如设置为5.7.25-proxy,这样就可以满足业务小数秒的需求。如果读者相关业务有类似场景,也可以参考以上方式进行配置或者开发支持,改动也不大。

总结

以上就是本期文章的全部内容了,可以发现最近好几篇都和jdbc的驱动使用有关系。在使用中发现,有关jdbc驱动的资料相对来说比较少,很多的时候是通过踩坑积累的经验,后续看计划是否可以整理一个专门有关jdbc驱动原理和使用的手册,方便优化使用和开发理解。