Sto utilizzando C3P0 e il driver MS SQL JDBC 4 per il failover automatico su un nuovo mirror del database quando il database scompare. Se prima si connette al DB principale, il failover funziona e passa senza interruzioni al DB mirror. Tuttavia, se il DB principale è inattivo all'avvio dell'applicazione e il DB mirror è disponibile per la connessione (testato con MSSQL Studio), l'applicazione non si avvia e non riesce a connettersi al mirror di backup.Il driver JDBC MSSQL non si connetterà a mirror failoverPartner alla prima connessione
Ecco l'URL di connessione:
jdbc:sqlserver://PRINCIPALDB;databaseName=app_space;port=99999;failoverPartner=MIRRORDB
ho c3p0.testConnectionOnCheckout
e c3p0.preferredTestQuery
set, e c3p0.acquireRetryAttempts
non è impostato (utilizzando di default di 30).
Perché non si connette inizialmente al mirror DB quando il principal è inattivo? Ne abbiamo bisogno perché se l'alimentazione si interrompe o qualcosa e il DB principale non funziona, e il server delle app deve essere riciclato, il failover non sarà di aiuto.
Riferimento:
http://www.mchange.com/projects/c3p0/#configuring_recovery
Using Database Mirroring (JDBC) (! MSDN utilizza parentesi escape nei loro URL) http://msdn.microsoft.com/en-US/library/aa342332(v=sql.90)
Ecco alcuni ceppi dalla app.
E qui è un diverso tipo di errore che a volte fornisce, con un avviso di deadlock.
<14>[APP]: INFO 20 Jul 2012 18:05:43,049 [main] net.sf.hibernate.connection.C3P0ConnectionProvider "C3P0 using driver: com.microsoft.sqlserver.jdbc.SQLServerDriver at URL: jdbc:sqlserver://PRINCIPALDB:9999;databaseName=APP_space;failoverPartner=MIRRORDB:9999"
<14>[APP]: INFO 20 Jul 2012 18:05:43,049 [main] net.sf.hibernate.connection.C3P0ConnectionProvider "Connection properties: {user=USERNAME, password=PASSWORD}"
<14>[APP]: INFO 20 Jul 2012 18:05:43,190 [main] com.mchange.v2.log.MLog "MLog clients using log4j logging."
<14>[APP]: INFO 20 Jul 2012 18:05:43,518 [main] com.mchange.v2.c3p0.C3P0Registry "Initializing c3p0-0.9.1.2 [built 21-May-2007 15:04:56; debug? true; trace: 10]"
<14>[APP]: INFO 20 Jul 2012 18:05:43,612 [main] net.sf.hibernate.transaction.TransactionFactoryFactory "Transaction strategy: net.sf.hibernate.transaction.JDBCTransactionFactory"
<14>[APP]: INFO 20 Jul 2012 18:05:43,612 [main] net.sf.hibernate.transaction.TransactionManagerLookupFactory "No TransactionManagerLookup configured (in JTA environment, use of process level read-write cache is not recommended)"
<14>[APP]: INFO 20 Jul 2012 18:05:43,658 [main] com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource "Initializing c3p0 pool... [email protected] [ connectionPoolDataSource -> [email protected] [ acquireIncrement -> 5, acquireRetryAttempts -> 30, acquireRetryDelay -> 1000, autoCommitOnClose -> false, automaticTestTable -> null, breakAfterAcquireFailure -> false, checkoutTimeout -> 0, connectionCustomizerClassName -> null, connectionTesterClassName -> com.mchange.v2.c3p0.impl.DefaultConnectionTester, debugUnreturnedConnectionStackTraces -> false, factoryClassLocation -> null, forceIgnoreUnresolvedTransactions -> false, identityToken -> 1bqq23w8o1a6dec41cwe1cd|20e1bfee, idleConnectionTestPeriod -> 100, initialPoolSize -> 10, maxAdministrativeTaskTime -> 0, maxConnectionAge -> 0, maxI...
<14>...dleTime -> 3600, maxIdleTimeExcessConnections -> 0, maxPoolSize -> 150, maxStatements -> 1000, maxStatementsPerConnection -> 0, minPoolSize -> 10, nestedDataSource -> [email protected] [ description -> null, driverClass -> null, factoryClassLocation -> null, identityToken -> 1bqq23w8o1a6dec41cwe1cd|20360e46, jdbcUrl -> jdbc:sqlserver://PRINCIPALDB:9999;databaseName=APP_space;failoverPartner=MIRRORDB:9999, properties -> {user=******, password=******} ], preferredTestQuery -> select * from CLUSTERSAFETY, propertyCycle -> 0, testConnectionOnCheckin -> false, testConnectionOnCheckout -> false, unreturnedConnectionTimeout -> 0, usesTraditionalReflectiveProxies -> false; userOverrides: {} ], dataSourceName -> null, factoryClassLocation -> null, identityToken -> 1bqq23w8o1a6dec41cwe1cd|6f3e49a8, numHelperThreads -> 3 ]"
<12>[APP]: WARN 20 Jul 2012 18:06:03,644 [Timer-0] com.mchange.v2.async.ThreadPoolAsynchronousRunner "com[email protected]37f844f7 -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!"
<12>[APP]: WARN 20 Jul 2012 18:06:03,644 [Timer-0] com.mchange.v2.async.ThreadPoolAsynchronousRunner "com[email protected]37f844f7 -- APPARENT DEADLOCK!!! Complete Status:
Managed Threads: 3
Active Threads: 3
Active Tasks:
[email protected]59 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0)
[email protected]5b (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
[email protected]cc (com.mchange.v2.asyn...
<12>...c.ThreadPoolAsynchronousRunner$PoolThread-#2)
Pending Tasks:
ho fatto un programma di test dalla documentazione con questa connessione:
jdbc:sqlserver://PRINCIPALDB:9999;databaseName=APP_space;portNumber=9999;failoverPartner=MIRRORDB:9999
e gettare questa eccezione, come se stesse cercando una porta diversa rispetto ho specificato!
Connection to principal server failed, trying the mirror server.
com.microsoft.sqlserver.jdbc.SQLServerException: The TCP/IP connection to the host MIRRORDB:9999, port 1433 has failed. Error: "null. Verify the connection properties. Make sure that an instance of SQL Server is running on the host and accepting TCP/IP connections at the port. Make sure that TCP connections to the port are not blocked by a firewall.".
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:190)
Il punto importante è che si è cercato di connettersi alla porta 1433 anziché la porta che ho specificato, molti modi diversi.
Ok ci proverò. Sì, mirror era attivo, poiché mi collegavo ad esso e il DBA lo rendeva attivo manualmente e lo impostavo anche come automatico con un testimone. Proverà instanceName. Sembra che si connetta solo sulla porta 1433 per il failover, il che lo renderebbe abbastanza rotto per l'alta disponibilità. – Chloe
Purtroppo non posso testarlo. Il principal e il mirror utilizzano nomi di istanze differenti, \ SQLA e \ SQLB. Nella produzione usano lo stesso nome di istanza, ma non posso testare lì. – Chloe
Oh sì, non è possibile connettersi allo specchio se è comunque in modalità mirror. Dopo che è arrivato online e diventa principale, allora è possibile connettersi, ma il vecchio principale diventa "offline" e non è possibile connettersi. – Chloe