db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Internal Statements in Derby
Date Fri, 23 Feb 2007 00:06:18 GMT
Was there a reason to ship "logical" log records - did that just fit 
with some code you had for other dbs?

I believe Derby trunk is a long  way there for someone to implement a
hot standby using the existing "physical" log records.  With the most 
recent online backup work, one could put the working db in "online 
backup mode".  What this does is it configures the system so that
all physical log files can be applied a point in time copy of the
db to bring it up the current state.  The missing code is to get the 
existing log records copied over to an online backup on another machine. 
  Work to do would
include:
o some code at the log level to ship data in log.dat files from machine
   to machine.  One would have to decide how often to do this.  Some 
options would be:
     o log switch time (ie. file at a time) - probably easily done 
inititiated by a callout to a externally implemented system procedure.
Read can happen from file on disk as data is guaranteed synced.
     o synced log block write (ie. block(s) at a time) - again system
       procedure callout, with data read directly from synced file and
       shipped in a way hidded from log system.  Note that nothing that
       hasn't been synced is really needed by the standby.
     o log block write (synced/unsynced) - a little harder as data now
       may not be in the file for external communication.  Call to
       system procedure could include it.
     o log record at time.

o On the hot standby side the code wants to look like a "ever-running" 
online backup with some magic code in the redo loop that waits for new
log records rather than exit when it gets to end.

o Finally some coordination code to turn the hot standby recovered 
online backup into the current db.

o I haven't thought how you move users from the old db to the new db.  I 
think could be some sort of smart jdbc url that hides the actual db
user is connecting to.  This is probably easy if it ok to fail a 
connection and then succeed on a retry.

Egil Sørensen wrote:
> Thank you for your reply.
> 
> I am shipping logical log records from node to node. However these  can 
> be converted into sql and in that way be redone by a normal jdbc- 
> statement. However, will it work to open an external jdbc-connection  to 
> the database from the inside of the same database? I would assume  there 
> would be a better internal solution, however I have yet to  discover one :)
> 
> Thanks,
> 
> Egil
> 
> 
> On Feb 15, 2007, at 4:09 PM, Bryan Pendleton wrote:
> 
>>>  the primary derby database creates logical log records and ships  
>>> these to the Hot-Standby database. However, I am having some  trouble 
>>> making the Hot-Standby derby to redo the statements when  they are 
>>> committed on the primary node.
>>
>>
>> I'm not quite sure I understand. Are you transferring log records
>> from node to node? Or are you transferring SQL statements?
>>
>> If you are transferring SQL statements, can't the recipient node
>> open a normal JDBC Statement and call Statement.executeUpdate()?
>>
>> thanks,
>>
>> bryan
>>
>>
>>
> 
> 
> 


Mime
View raw message