Hi Denis,
I am experiencing problems with recovering backend after database failure.
Version of Sequoia: 3.0 beta 2
Database: MS SQL Server 2005 Express Edition
Which JDBC driver are you using ?
OS: Windows XP SP2
JVM version: 1.6
As I can see from mail-archive similar issue was in version 2.8.2:
http://www.arcknowledge.com/gmane.comp.db.sequoia.general/2006-06/msg00153.html
<http://www.arcknowledge.com/gmane.comp.db.sequoia.general/2006-06/msg00153.html>
Scenario:
1. execute controller.bat
2. create a dump.
So I guess that you have a single controller and that you have an
autoload of your configuration file since you don't mention any config
file loading.
What kind of replication are you using? SingleDB, RAIDb0, 1 or 2,
ParallelDB?
What recovery log configuration do you use?
4. stop MS SQL Server service
5. use console.bat to execute SQL-statements
Do you have multiple databases? Are you trying to produce an error or
just check that other databases will transparently continue to serve
requests?
6. start MS SQL Server service
8. start the sequoia admin console
9. restore the dump
Did you manually check that the dump file that was generated was correct?
10. enable backend (doesn't works, admin console hangs).
Executing SQL statements from console:
2007-01-24 13:54:24,312 ERROR sequoia.controller.recoverylog Failed to
log create table Table_1 (ID bigint,NAME varchar(50), EMAIL
varchar(50),TEXT1 varchar(50),TEXT2 varchar(50),TEXT3
varchar(50),TEXT4 varchar(50),TEXT5 varchar(50))
java.sql.SQLException: I/O Error: Connection reset by peer: socket
write error
at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1049)
at net.sourceforge.jtds.jdbc.TdsCore.microsoftPrepare(TdsCore.java :1175)
at
net.sourceforge.jtds.jdbc.ConnectionJDBC2.prepareSQL(ConnectionJDBC2.java:646)
at
net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeUpdate(JtdsPreparedStatement.java:420)
.........
This might explain why you have these problems. Given that the recovery
log fails, you are probably trying to store the controller recovery log
on the very same database that you just stopped. This is certainly a
very bad idea since the controller cannot enable a backend without a
working recovery log.
If you are using Sequoia 3.0 you can just use the new
EmbeddedRecoveryLog to prevent that kind of issue, else you have to make
sure that you point your recovery log to a database that is not stopped
during controller operation.
Enabling backend:
2007-01-24 13:56:12,937 ERROR backend.DatabaseBackend.mainPCDB Unable
to get a connection to gather database schema.
2007-01-24 13:56:12,937 WARN backend.DatabaseBackend.mainPCDB Unable
to gather schema from database meta data: java.sql.SQLException:
Failed to get information about database schema:
java.sql.SQLException: Unable to get a connection to gather database
schema.
For some reason, new JDBC connections to the database cannot be
established. It is not clear from this small context to say exactly why.
Let us know if the recovery log configuration mentioned above could be
the root cause of your problem.
Thanks for your feedback,
Emmanuel
--
Emmanuel Cecchet
Chief Scientific Officer, Continuent
Blog: http://emanux.blogspot.com/
Open source: http://www.continuent.org
Corporate: http://www.continuent.com
Skype: emmanuel_cecchet
Cell: +33 687 342 685
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
