db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Derby replication seems to be mostly useless
Date Mon, 13 Jul 2009 10:42:23 GMT
Alan Burlison <Alan.Burlison@Sun.COM> writes:

> Dag H. Wanvik wrote:
>
>> I suspect that when you use the programmatic approach, the databases
>> are not shut down cleanly. If the servers are started from the command
>> line, I think the booted databases are shut down cleanly.
>>
>> Cf these lines in NotworkServerControlImpl.java:
>>         :
>> 	// if the server is started from the command line, it should shutdown the
>> 	// databases it has booted.
>> 	private boolean shutdownDatabasesOnShutdown = false;
>>
>> This means that when the server is started via the API, each database
>> needs to be shut down individually to get a clean shutdown (with
>> checkpoint).
>
> Unfortunately I don't think that's workable in practice.  Because
> Derby auto-starts databases on connection, there is no way of stopping
> clients opening the database again whilst the copy and child start is
> happening. There needs to be some way to ensure the database is locked
> and then to flush the log entries.  Would a
> SYSCS_UTIL.SYSCS_FREEZE_DATABASE followed by a
> SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE do the trick?

No, I'm afraid not. SYSCS_FREEZE_DATABASE already performs a
checkpoint. The problem is that the checkpoint is not allowed to remove
the log generated by transactions that are still active.

One solution could be to introduce a variant of freeze that fails if
there are active transactions which have generated log records. Then
you'd just have to retry until you can successfully freeze the database,
but that could go on forever if new transactions keep coming
in. Variants that block until the database is frozen (possibly also
preventing new transactions from starting) or that abort other active
transactions could perhaps also be used.

Could the following be a practical workaround?

1. Add a replication user that's only used to start/stop replication

2. Temporarily disable all other users by unsetting derby.user.XXX

3. Perform clean shutdown of master database

4. Copy database and start slave

5. Start master

6. Re-enable the non-replication users

This way I *think* you'd prevent others from booting the database while
you're setting up replication.

-- 
Knut Anders

Mime
View raw message