You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Duncan Groenewald <du...@xtra.co.nz> on 2006/11/14 02:34:21 UTC

Does Derby support Transaction Logging ?

Does derby support transaction logging ? and if so how to dump/access 
them ?  If not any plan to do so ??

Re: Does Derby support Transaction Logging ?

Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Duncan Groenewald wrote:
> Thanks, I just read the material on the transaction logs.  However I
> still don't see how I would be able to achieved what I want which is:
> 
>   1. Set up a new derby database server on another server (server_2)
>   2. Restore the database from a database backup from server_1
>   3. Copy server_1 logs every 15 minutes and load them into server_2

The database files that make up a derby database are platform
independent, so you can set up a new database based on an existing one
very easily: just shut down that database on the first server and copy
all the files in the database directory over to the second server.

However, Derby doesn't support synchronizing multiple databases. Sequoia
might support what you want (and more):

http://sequoia.continuent.org/HomePage

Also, in the "Products by Type" category on
http://wiki.apache.org/db-derby/UsesOfDerby, there's a list of
synchronization/replication products.

I hope this helps,

 -jean



Re: Does Derby support Transaction Logging ?

Posted by Mike Matrigali <mi...@sbcglobal.net>.
Yes, derby is not there yet -- but with the online backup work done in
10.2 it is very close.  The problem is that there is no support for
coordination of taking and applying the logs in step 3.  Also what
do you want to be doing on server_2 during/after this process.

I think this is a smallish project to create a readonly standby backup
server (on the order of month's) for someone
who already knows how to work with derby.  The missing pieces now
are:
o enhance the online backup code to allow for copying the log files
   in some coordinated fashion.  Currently it just keeps the existing
   logs where they are forever.  An easy first step would be to just
   enable a callout everytime there is a log switch.

o Allow for a standby server to sit around, allow only readonly
   access to data.  Apply log files as they are fed in.  Maybe get locks
   on log record application (existing code for this exists as part of
   XA redo).

Now allowing write access on the standby while taking log files is
way more difficult.

Duncan Groenewald wrote:
> Thanks, I just read the material on the transaction logs.  However I 
> still don't see how I would be able to achieved what I want which is:
> 
>   1. Set up a new derby database server on another server (server_2)
>   2. Restore the database from a database backup from server_1
>   3. Copy server_1 logs every 15 minutes and load them into server_2
> 
> 
> Duncan Groenewald wrote:
> 
>> Yes, I want to load the transaction logs into a copy of the database 
>> in a simple form of replication.  Is there an alternative way of doing 
>> this ?
>>
>> Dan Scott wrote:
>>
>>> On 15/11/06, Stanley Bradbury <St...@gmail.com> wrote:
>>>
>>>> Duncan Groenewald wrote:
>>>> > Does derby support transaction logging ? and if so how to dump/access
>>>> > them ?  If not any plan to do so ??
>>>> >
>>>> I don't understand what you are asking about but can tell you that 
>>>> Derby
>>>> maintains a transaction log for rollback and recovery purposes.  It is
>>>> not intended to be accessed directly by and application.  There is some
>>>> access to these records via Triggers.  The architecture information on
>>>> the website contain good descriptions of the transactional capabilities
>>>> of Derby.
>>>>
>>>
>>> A completely wild guess would be, from a MySQL perspective, that
>>> somebody wants to try to implement a form of replication by
>>> periodically capturing the transaction logs from a master instance of
>>> an Apache Derby database and then applying those logs to a replicated
>>> instance of an Apache Derby database.
>>>
>>> Dan
>>>
>>
>>
> 
> 
> 


Re: Does Derby support Transaction Logging ?

Posted by Duncan Groenewald <du...@xtra.co.nz>.
Thanks, I just read the material on the transaction logs.  However I 
still don't see how I would be able to achieved what I want which is:

   1. Set up a new derby database server on another server (server_2)
   2. Restore the database from a database backup from server_1
   3. Copy server_1 logs every 15 minutes and load them into server_2


Duncan Groenewald wrote:
> Yes, I want to load the transaction logs into a copy of the database 
> in a simple form of replication.  Is there an alternative way of doing 
> this ?
>
> Dan Scott wrote:
>> On 15/11/06, Stanley Bradbury <St...@gmail.com> wrote:
>>> Duncan Groenewald wrote:
>>> > Does derby support transaction logging ? and if so how to dump/access
>>> > them ?  If not any plan to do so ??
>>> >
>>> I don't understand what you are asking about but can tell you that 
>>> Derby
>>> maintains a transaction log for rollback and recovery purposes.  It is
>>> not intended to be accessed directly by and application.  There is some
>>> access to these records via Triggers.  The architecture information on
>>> the website contain good descriptions of the transactional capabilities
>>> of Derby.
>>>
>>
>> A completely wild guess would be, from a MySQL perspective, that
>> somebody wants to try to implement a form of replication by
>> periodically capturing the transaction logs from a master instance of
>> an Apache Derby database and then applying those logs to a replicated
>> instance of an Apache Derby database.
>>
>> Dan
>>
>
>


Re: Does Derby support Transaction Logging ?

Posted by Duncan Groenewald <du...@xtra.co.nz>.
Yes, I want to load the transaction logs into a copy of the database in 
a simple form of replication.  Is there an alternative way of doing this ?

Dan Scott wrote:
> On 15/11/06, Stanley Bradbury <St...@gmail.com> wrote:
>> Duncan Groenewald wrote:
>> > Does derby support transaction logging ? and if so how to dump/access
>> > them ?  If not any plan to do so ??
>> >
>> I don't understand what you are asking about but can tell you that Derby
>> maintains a transaction log for rollback and recovery purposes.  It is
>> not intended to be accessed directly by and application.  There is some
>> access to these records via Triggers.  The architecture information on
>> the website contain good descriptions of the transactional capabilities
>> of Derby.
>>
>
> A completely wild guess would be, from a MySQL perspective, that
> somebody wants to try to implement a form of replication by
> periodically capturing the transaction logs from a master instance of
> an Apache Derby database and then applying those logs to a replicated
> instance of an Apache Derby database.
>
> Dan
>


Re: Does Derby support Transaction Logging ?

Posted by Dan Scott <de...@gmail.com>.
On 15/11/06, Stanley Bradbury <St...@gmail.com> wrote:
> Duncan Groenewald wrote:
> > Does derby support transaction logging ? and if so how to dump/access
> > them ?  If not any plan to do so ??
> >
> I don't understand what you are asking about but can tell you that Derby
> maintains a transaction log for rollback and recovery purposes.  It is
> not intended to be accessed directly by and application.  There is some
> access to these records via Triggers.  The architecture information on
> the website contain good descriptions of the transactional capabilities
> of Derby.
>

A completely wild guess would be, from a MySQL perspective, that
somebody wants to try to implement a form of replication by
periodically capturing the transaction logs from a master instance of
an Apache Derby database and then applying those logs to a replicated
instance of an Apache Derby database.

Dan

Re: Does Derby support Transaction Logging ?

Posted by Stanley Bradbury <St...@gmail.com>.
Duncan Groenewald wrote:
> Does derby support transaction logging ? and if so how to dump/access 
> them ?  If not any plan to do so ??
>
I don't understand what you are asking about but can tell you that Derby 
maintains a transaction log for rollback and recovery purposes.  It is 
not intended to be accessed directly by and application.  There is some 
access to these records via Triggers.  The architecture information on 
the website contain good descriptions of the transactional capabilities 
of Derby.