mysql数据库更新报错，提示readonly，问题分析

项目背景：spring+mybatis,多数据源,T(T1,T2),P(P1,P2),R(R1,R2),其中1表示主库，2表示从库，使用Spring的AbstractRoutingDataSource在主从之间进行切换
最近在查看请求日志时，发现对数据库P1的一个update操作，提示数据库是只读的，错误提示： Error updating database. Cause: java.sql.SQLException: The MySQL server is running with the –read-only option so it cannot execute this statement.
遇到这类问题，首先会第一时间想到，是不是db出问题了，于是赶紧找到dba确认，结果dba反馈说P1库一切正常，那么会不会是主从路由的时候切换到从库上面去了呢，于是赶紧接着去查日志，发现路由日志显示是master，但为了保险起见，还是请求了dba查看数据库log，看看update的请求究竟是打到哪里了，结果一查，还真是打到从库上了，既然问题已经定位了，那只能接着撸代码了，业务关键代码如下：

@Resource(name = "t_transactionManager")private DataSourceTransactionManager transactionManager;TransactionDefinition def = new DefaultTransactionDefinition(TransactionDefinition.PROPAGATION_REQUIRES_NEW);TransactionStatus   transactionStatus = transactionManager.getTransaction(def);Pay pay = payService.queryPayInSlave(id);…………………………………逻辑处理…………………………payService.updatePay(pay);transactionManager.commit(transactionStatus);

我们来看下mybatis一次数据库操作是如何执行的，执行堆栈如下：

我们看到堆栈的最上层，程序开始获取Connection，这也是我们关注的重点，请求既然到从库P2了，那么获取到的连接肯定是从库P2的连接。获取Connection的源码如下：

public static Connection doGetConnection(DataSource dataSource) throws SQLException {        Assert.notNull(dataSource, "No DataSource specified");        ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource(dataSource);        if (conHolder != null && (conHolder.hasConnection() || conHolder.isSynchronizedWithTransaction())) {            conHolder.requested();            if (!conHolder.hasConnection()) {                logger.debug("Fetching resumed JDBC Connection from DataSource");                conHolder.setConnection(dataSource.getConnection());            }            return conHolder.getConnection();        }        // Else we either got no holder or an empty thread-bound holder here.        logger.debug("Fetching JDBC Connection from DataSource");        Connection con = dataSource.getConnection();        if (TransactionSynchronizationManager.isSynchronizationActive()) {            logger.debug("Registering transaction synchronization for JDBC Connection");            // Use same Connection for further JDBC actions within the transaction.            // Thread-bound object will get removed by synchronization at transaction completion.            ConnectionHolder holderToUse = conHolder;            if (holderToUse == null) {                holderToUse = new ConnectionHolder(con);            }            else {                holderToUse.setConnection(con);            }            holderToUse.requested();            TransactionSynchronizationManager.registerSynchronization(                    new ConnectionSynchronization(holderToUse, dataSource));            holderToUse.setSynchronizedWithTransaction(true);            if (holderToUse != conHolder) {                TransactionSynchronizationManager.bindResource(dataSource, holderToUse);            }        }        return con;    }

通过代码我们可以看到，获取Connection的逻辑主要分为3步：
1.从ThreadLocal中获取ConnectionHolder,假如holder有值，那么直接从holder中返回connection。
2.holder是空的，就会通过文章开头提到的AbstractRoutingDataSource在主从之间进行切换，生成相应的连接。
3.判断当前线程isSynchronizationActive，假如开启了同步，创建ConnectionHolder，并添加到ThreadLocal中。
ok，分析完代码，那么更新出错肯定发生在第一步或者第二步上面了，于是debug进去，发现update的时候还真是从holder中获取一个连接，而且是获取到了错误的连接，于是回归到刚开始的业务代码：

Pay pay = payService.queryPayInSlave(id);…………………………………逻辑处理…………………………payService.updatePay(pay);

发现更新之前还真有一次从库的查询，根据获取Connection的源码分析的第三步，那么是在queryPayInSlave()的时候，新生成了从库的连接，并创建了ConnectionHolder，接下来的updatePay()，直接拿到了ConnectionHolder，这样分析下来，逻辑是通了，而且debug调试的时候确实如此，但总觉得怪怪的，查询走从库，更新到主库，这是一个再正常不过的逻辑了，按道理事务控制不该是这个样子的。源码总不会骗人，那么我们还是看看事务控制的源码吧。

public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {        Object transaction = doGetTransaction();        // Cache debug flag to avoid repeated checks.        boolean debugEnabled = logger.isDebugEnabled();        if (definition == null) {            // Use defaults if no transaction definition given.            definition = new DefaultTransactionDefinition();        }        if (isExistingTransaction(transaction)) {            // Existing transaction found -> check propagation behavior to find out how to behave.            return handleExistingTransaction(definition, transaction, debugEnabled);        }        // Check definition settings for new transaction.        if (definition.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) {            throw new InvalidTimeoutException("Invalid transaction timeout", definition.getTimeout());        }        // No existing transaction found -> check propagation behavior to find out how to proceed.        if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) {            throw new IllegalTransactionStateException(                    "No existing transaction found for transaction marked with propagation 'mandatory'");        }        else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||                definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||            definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {            SuspendedResourcesHolder suspendedResources = suspend(null);            if (debugEnabled) {                logger.debug("Creating new transaction with name [" + definition.getName() + "]: " + definition);            }            try {                boolean newSynchronization = (getTransactionSynchronization() != SYNCHRONIZATION_NEVER);                DefaultTransactionStatus status = newTransactionStatus(                        definition, transaction, true, newSynchronization, debugEnabled, suspendedResources);                doBegin(transaction, definition);                prepareSynchronization(status, definition);                return status;            }            catch (RuntimeException ex) {                resume(null, suspendedResources);                throw ex;            }            catch (Error err) {                resume(null, suspendedResources);                throw err;            }        }        else {            // Create "empty" transaction: no actual transaction, but potentially synchronization.            boolean newSynchronization = (getTransactionSynchronization() == SYNCHRONIZATION_ALWAYS);            return prepareTransactionStatus(definition, null, true, newSynchronization, debugEnabled, null);        }    }@Override    protected void doBegin(Object transaction, TransactionDefinition definition) {        DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction;        Connection con = null;        try {            if (txObject.getConnectionHolder() == null ||                    txObject.getConnectionHolder().isSynchronizedWithTransaction()) {                Connection newCon = this.dataSource.getConnection();                if (logger.isDebugEnabled()) {                    logger.debug("Acquired Connection [" + newCon + "] for JDBC transaction");                }                txObject.setConnectionHolder(new ConnectionHolder(newCon), true);            }            txObject.getConnectionHolder().setSynchronizedWithTransaction(true);            con = txObject.getConnectionHolder().getConnection();            Integer previousIsolationLevel = DataSourceUtils.prepareConnectionForTransaction(con, definition);            txObject.setPreviousIsolationLevel(previousIsolationLevel);            // Switch to manual commit if necessary. This is very expensive in some JDBC drivers,            // so we don't want to do it unnecessarily (for example if we've explicitly            // configured the connection pool to set it already).            if (con.getAutoCommit()) {                txObject.setMustRestoreAutoCommit(true);                if (logger.isDebugEnabled()) {                    logger.debug("Switching JDBC Connection [" + con + "] to manual commit");                }                con.setAutoCommit(false);            }            txObject.getConnectionHolder().setTransactionActive(true);            int timeout = determineTimeout(definition);            if (timeout != TransactionDefinition.TIMEOUT_DEFAULT) {                txObject.getConnectionHolder().setTimeoutInSeconds(timeout);            }            // Bind the session holder to the thread.            if (txObject.isNewConnectionHolder()) {                TransactionSynchronizationManager.bindResource(getDataSource(), txObject.getConnectionHolder());            }        }        catch (Throwable ex) {            DataSourceUtils.releaseConnection(con, this.dataSource);            throw new CannotCreateTransactionException("Could not open JDBC Connection for transaction", ex);        }    }

可以看到getTransaction()方法会先生成一个transaction，然后经过一系列的判断，进入到了doBegin()，在doBegin中我们又看到了熟悉的ConnectionHolder，程序通过动态数据源dataSource，经过AbstractRoutingDataSource路由生成了一个新的Connection，由于我们没有指定连接是走主库，还是走从库，所以程序默认生成了一个主库的连接，然后创建ConnectionHolder，并且在doBegin的最后执行了 Bind the session holder to the thread，即把ConnectionHolder添加到ThreadLocal中，那么既然我们在开启事务的时候已经生成了ConnectionHolder，再结合获取Connection的源码，那么我们在执行queryPayInSlave()方法时，就不应该生成新的Connection，而是从transaction的ConnectionHolder中获取，即我们应该拿到一个主库的连接，好吧，之前的逻辑又推翻了。于是又开始了一遍一遍的debug。
最终问题终于定位了，原来我们在注入transactionManager的时候，注入的是一个t_transactionManager而不是数据源P的p_transactionManager，那么我们在开启事务的时候，创建的是主库（T1）的连接，所以放到ThreadLocal里面的也是T1的ConnectionHolder，并且将线程的同步状态激活，接下来执行queryPayInSlave()方法的时候，由于该方法是对P2库的操作，所以在获取connection的时候，从ThreadLocal中是获取不到ConnectionHolder的，所以queryPayInSlave()会新获取一个连接（从库P2的连接），而且由于线程的同步状态激活，所以会把该连接对应的ConnectionHolder放入到ThreadLocal，导致接下来的updatePay()从ConnectionHolder拿到了从库P2的连接。
总结：
1.spring的TransactionManager和dataSource绑定，所以要选择dataSource绑定的manager，针对多数据源操作的事务控制，要分开来处理，数据的一致性也可以通过逻辑来控制。
2.动态数据源（主从配置的）的TransactionManager在创建Connection的时候，一般都会选择默认的数据源（Master），事务控制内的数据库操作也都会以该Connection执行，所以对数据库查询强制性要求走从库的，就要把查询放到事务控制外面了。