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 Brian Spindler <bs...@netuitive.com> on 2009/04/07 21:49:33 UTC

master and slave are not in synch for replicated database

Guys/Gals,

 

I have taken the following procedure:

 

1.       Using ij logged into my database

2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();

3.       Exit ij

4.       Copy database to slave

5.       Start slave

6.       Start master.

 

Then I get this error: 

 

Caused by: ERROR XRE05: The log files on the master and slave are not in
synch for replicated database 'foo'. The master log instant is 1:104173,
whereas the slave log instant is 1:103957. This is FATAL for replication
- replication will be stopped.

                

 

I thought by freezing/copying etc... they would be in synch?

 


RE: master and slave are not in synch for replicated database

Posted by Brian Spindler <bs...@netuitive.com>.
Alan, 

Did you enter the issue for replication regarding the 10.6? I'd also
like to vote and add what I can to help define requirements. 

-Brian

-----Original Message-----
From: Alan Burlison [mailto:Alan.Burlison@sun.com] 
Sent: Wednesday, April 08, 2009 10:14 AM
To: Derby Discussion
Subject: Re: master and slave are not in synch for replicated database

Brian Spindler wrote:

> I agree.  This seems even more complicated when considering the db
from
> an embedded standpoint.  The slave app has to boot the db without
> performing any write operations until it has become master (which I
> don't know how it would know this?)

In our case we are running Derby embedded inside Tomcat.  We could 
switch, but it would be messy.

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by Alan Burlison <Al...@sun.com>.
Brian Spindler wrote:

> I agree.  This seems even more complicated when considering the db from
> an embedded standpoint.  The slave app has to boot the db without
> performing any write operations until it has become master (which I
> don't know how it would know this?)

In our case we are running Derby embedded inside Tomcat.  We could 
switch, but it would be messy.

-- 
Alan Burlison
--

RE: master and slave are not in synch for replicated database

Posted by Brian Spindler <bs...@netuitive.com>.
I agree.  This seems even more complicated when considering the db from
an embedded standpoint.  The slave app has to boot the db without
performing any write operations until it has become master (which I
don't know how it would know this?)

I presume from what I've seen there is very little documentation and
testing around the different replication use cases? 

-Brian

-----Original Message-----
From: Alan Burlison [mailto:Alan.Burlison@sun.com] 
Sent: Wednesday, April 08, 2009 9:26 AM
To: Derby Discussion
Subject: Re: master and slave are not in synch for replicated database

V Narayanan wrote:

> I am not sure if you wanted to ask two separate questions or a single 
> question, I will treat them as two separate questions

You guesses right - two questions :-)

>> How do you 'fail back' to the master?
> 
> fail back = auto failover?
> 
> You mean after you failover and your slave becomes your new master,
how 
> will you fail back to the old master?

Yes.

> You will have to restart replication on the slave (i.e.) you will have

> to do the freezing, copying data files again on the
> slave.

OK, thanks.  Although I guess you'd stop both and copy from the slave to

the master, as that is the 'live' DB once the original failover
happened.

>> If I shut the master and slave down once replication is running, do I

>> have to re-copy the data files from the master to the slave before 
>> restarting the slave?
> 
> If you shutdown both the master and the slave you are restarting 
> replication when the master comes up :),  Ideally speaking
> you should be re-copying data files, but I confess I have never tried 
> this, I think if you do it without a re-copy you will get a
> error similar to this,
> 
> Caused by: ERROR XRE05: The log files on the master and slave are not
in
> synch for replicated database 'foo'. The master log instant is
1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for
replication
> - replication will be stopped.

That is going to be virtually unworkable in a production environment.

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by Alan Burlison <Al...@sun.com>.
V Narayanan wrote:

> I am not sure if you wanted to ask two separate questions or a single 
> question, I will treat them as two separate questions

You guesses right - two questions :-)

>> How do you 'fail back' to the master?
> 
> fail back = auto failover?
> 
> You mean after you failover and your slave becomes your new master, how 
> will you fail back to the old master?

Yes.

> You will have to restart replication on the slave (i.e.) you will have 
> to do the freezing, copying data files again on the
> slave.

OK, thanks.  Although I guess you'd stop both and copy from the slave to 
the master, as that is the 'live' DB once the original failover happened.

>> If I shut the master and slave down once replication is running, do I 
>> have to re-copy the data files from the master to the slave before 
>> restarting the slave?
> 
> If you shutdown both the master and the slave you are restarting 
> replication when the master comes up :),  Ideally speaking
> you should be re-copying data files, but I confess I have never tried 
> this, I think if you do it without a re-copy you will get a
> error similar to this,
> 
> Caused by: ERROR XRE05: The log files on the master and slave are not in
> synch for replicated database 'foo'. The master log instant is 1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for replication
> - replication will be stopped.

That is going to be virtually unworkable in a production environment.

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by Rick Hillegas <Ri...@Sun.COM>.
Alan Burlison wrote:
> Rick Hillegas wrote:
>
>> Our 10.6 plans are largely driven by the issues which have received 
>> the most votes from our users: 
>> http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:popularissues-panel 
>> You can help tilt our plans in your direction by voting for 
>> replication-related issues.
>
> We are using Derby for the new membership system we are building for 
> opensolaris.org, and we are figuring out what we need to do for 
> 'production' use - replication is obviously one thing we are looking at.
>
> I can't see an issue for this in that list, do I need to create a new 
> one?
>
Yes, please. If you can describe what Derby needs to build to make 
replication production-ready for you, that would help.

Thanks,
-Rick

Re: master and slave are not in synch for replicated database

Posted by Alan Burlison <Al...@sun.com>.
Rick Hillegas wrote:

> Our 10.6 plans are largely driven by the issues which have received the 
> most votes from our users: 
> http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:popularissues-panel 
> You can help tilt our plans in your direction by voting for 
> replication-related issues.

We are using Derby for the new membership system we are building for 
opensolaris.org, and we are figuring out what we need to do for 
'production' use - replication is obviously one thing we are looking at.

I can't see an issue for this in that list, do I need to create a new one?

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by Rick Hillegas <Ri...@Sun.COM>.
Alan Burlison wrote:
> Knut Anders Hatlen wrote:
>
>> We discussed this problem a while ago, and there were some suggestions
>> of how to fail back to the master with as little downtime as
>> possible. See here for the details:
>>
>> http://www.nabble.com/Replication---switching-back-after-failover-td19950674.html 
>>
>
> That's exactly what I was looking for, thanks.  Seems that Derby 
> replication isn't really ready for production use yet, not without a 
> lot of wrapping around it.  Shame :-(
>
Hi Alan,

Our 10.6 plans are largely driven by the issues which have received the 
most votes from our users: 
http://issues.apache.org/jira/browse/DERBY?report=com.atlassian.jira.plugin.system.project:popularissues-panel 
You can help tilt our plans in your direction by voting for 
replication-related issues.

Thanks,
-Rick

Re: master and slave are not in synch for replicated database

Posted by Alan Burlison <Al...@sun.com>.
Knut Anders Hatlen wrote:

> We discussed this problem a while ago, and there were some suggestions
> of how to fail back to the master with as little downtime as
> possible. See here for the details:
> 
> http://www.nabble.com/Replication---switching-back-after-failover-td19950674.html

That's exactly what I was looking for, thanks.  Seems that Derby 
replication isn't really ready for production use yet, not without a lot 
of wrapping around it.  Shame :-(

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
V Narayanan <V....@Sun.COM> writes:

> On 04/08/09 16:30, Alan Burlison wrote:
>> V Narayanan wrote:
>>
>>> Have you already seen this
>>> http://wiki.apache.org/db-derby/ReplicationWriteup ?
>>>
>>> You will find step by step instructions to get replication started
>>> there!
>>
> I am not sure if you wanted to ask two separate questions or a single
> question, I will treat them as two separate questions
>> How do you 'fail back' to the master?
>
> fail back = auto failover?
>
> You mean after you failover and your slave becomes your new master,
> how will you fail back to the old master?
>
> You will have to restart replication on the slave (i.e.) you will have
> to do the freezing, copying data files again on the
> slave.

We discussed this problem a while ago, and there were some suggestions
of how to fail back to the master with as little downtime as
possible. See here for the details:

http://www.nabble.com/Replication---switching-back-after-failover-td19950674.html

-- 
Knut Anders

Re: master and slave are not in synch for replicated database

Posted by V Narayanan <V....@Sun.COM>.
On 04/08/09 16:30, Alan Burlison wrote:
> V Narayanan wrote:
>
>> Have you already seen this 
>> http://wiki.apache.org/db-derby/ReplicationWriteup ?
>>
>> You will find step by step instructions to get replication started 
>> there!
>
I am not sure if you wanted to ask two separate questions or a single 
question, I will treat them as two separate questions
> How do you 'fail back' to the master?

fail back = auto failover?

You mean after you failover and your slave becomes your new master, how 
will you fail back to the old master?

You will have to restart replication on the slave (i.e.) you will have 
to do the freezing, copying data files again on the
slave.

>
> If I shut the master and slave down once replication is running, do I 
> have to re-copy the data files from the master to the slave before 
> restarting the slave?
>


If you shutdown both the master and the slave you are restarting 
replication when the master comes up :),  Ideally speaking
you should be re-copying data files, but I confess I have never tried 
this, I think if you do it without a re-copy you will get a
error similar to this,

Caused by: ERROR XRE05: The log files on the master and slave are not in
synch for replicated database 'foo'. The master log instant is 1:104173,
whereas the slave log instant is 1:103957. This is FATAL for replication
- replication will be stopped.



Re: master and slave are not in synch for replicated database

Posted by Alan Burlison <Al...@sun.com>.
V Narayanan wrote:

> Have you already seen this 
> http://wiki.apache.org/db-derby/ReplicationWriteup ?
> 
> You will find step by step instructions to get replication started there!

How do you 'fail back' to the master?

If I shut the master and slave down once replication is running, do I 
have to re-copy the data files from the master to the slave before 
restarting the slave?

-- 
Alan Burlison
--

Re: master and slave are not in synch for replicated database

Posted by V Narayanan <V....@Sun.COM>.
Hi Brian,

Shutdown on a frozen database will hang,

Are you doing a shutdown, ctrl+c before copying the DB for replication?

Can you please avoid the shutdown, ctrl+c step?

Have you already seen this 
http://wiki.apache.org/db-derby/ReplicationWriteup ?

You will find step by step instructions to get replication started there!

Narayanan

On 04/08/09 07:53, Brian Spindler wrote:
> I've tried both:
>
> connect 'jdbc:derby:<db>;shutdown=true';
>
> and
>
> exit; 
>
> both seem to simply hang and I'm forced to do Ctrl+C to get back my command prompt.  Does that sound right? 
>
> regardless; both result in the same error.
>
>
> -----Original Message-----
> From: Dag H. Wanvik [mailto:Dag.Wanvik@Sun.COM]
> Sent: Tue 4/7/2009 4:57 PM
> To: Derby Discussion
> Subject: Re: master and slave are not in synch for replicated database
>  
> Brian Spindler <bs...@netuitive.com> writes:
>
>   
>> Guys/Gals,
>>
>>  
>>
>> I have taken the following procedure:
>>
>>  
>>
>> 1.       Using ij logged into my database
>>
>> 2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();
>>     
>
> I saw in another thread you use embedded. Did you do a shutdown at
> this point?
> E.g. connect 'jdbc:derby:<db>;shutdown=true'
>
>   
>> 3.       Exit ij
>>
>> 4.       Copy database to slave
>>
>> 5.       Start slave
>>
>> 6.       Start master.
>>
>>  
>>
>> Then I get this error: 
>>
>>  
>>
>> Caused by: ERROR XRE05: The log files on the master and slave are not in
>> synch for replicated database 'foo'. The master log instant is 1:104173,
>> whereas the slave log instant is 1:103957. This is FATAL for replication
>> - replication will be stopped.
>>
>>                 
>>
>>  
>>
>> I thought by freezing/copying etc... they would be in synch?
>>
>>  
>>
>>     
>
>   


Re: master and slave are not in synch for replicated database

Posted by Kristian Waagan <Kr...@Sun.COM>.
Philip Rossomando wrote:
> I have long been a silent member of this group but I now need help.
> The following code was written by me to insert a Blob into the DB.
>
> 	public void insertImage(BufferedImage image) {
> 		try {
> 			byte[] bytes = this.getBytes(image);
> 			System.out.println("Bytes given to archive: " +
> bytes.length);
> 			String sql = "UPDATE TEST SET IMAGE = ? WHERE ID =
> ?";
> 			PreparedStatement ps = conn_.prepareStatement(sql);
> 			// ps.setBinaryStream(1, new
> ByteArrayInputStream(bytes),
> 			//			bytes.length);
> 			ps.setBlob(1, new ByteArrayInputStream(bytes),
> bytes.length);
> 			ps.setInt(2, 1);
> 			System.out.println("Rows written: " +
> ps.executeUpdate());
> 			conn_.commit();
> 			ps.close();
> 			System.out.println("Image Stored!");
> 		} catch (SQLException e) {
> 			printSQLError(e);
> 		} catch (Exception exc) { // process error
> 			System.err.println("process error" + exc);
> 		}
> 		return;
> 	}
>
> I converted a buffered image into an array bytes and then use setBlob() to
> prepare
> To write the blob to the db. Doing a bytes.length I get 372076. When I do my
>
> executeUpdate() I get back 0 indicating nothing was written. Sure enough, in
> IJ I
> see nothing was written Why? I tried setBinaryStream() changing Blob to
> LONVARBINARY.
> That didn't work either? Again Why.
>   

Hello Philip,

My guess would be that there is no existing row with the specified id in 
the database. In that case, you have to use an INSERT statement instead 
of UPDATE.


Regards,
-- 
Kristian

> Please help me here. Thank you.
>
> Phil Rossomando
>
> -----Original Message-----
> From: Brian Spindler [mailto:bspindler@netuitive.com] 
> Sent: Tuesday, April 07, 2009 10:23 PM
> To: Derby Discussion
> Subject: RE: master and slave are not in synch for replicated database
>   
[ snip ]

RE: master and slave are not in synch for replicated database

Posted by Philip Rossomando <ro...@verizon.net>.
I have long been a silent member of this group but I now need help.
The following code was written by me to insert a Blob into the DB.

	public void insertImage(BufferedImage image) {
		try {
			byte[] bytes = this.getBytes(image);
			System.out.println("Bytes given to archive: " +
bytes.length);
			String sql = "UPDATE TEST SET IMAGE = ? WHERE ID =
?";
			PreparedStatement ps = conn_.prepareStatement(sql);
			// ps.setBinaryStream(1, new
ByteArrayInputStream(bytes),
			//			bytes.length);
			ps.setBlob(1, new ByteArrayInputStream(bytes),
bytes.length);
			ps.setInt(2, 1);
			System.out.println("Rows written: " +
ps.executeUpdate());
			conn_.commit();
			ps.close();
			System.out.println("Image Stored!");
		} catch (SQLException e) {
			printSQLError(e);
		} catch (Exception exc) { // process error
			System.err.println("process error" + exc);
		}
		return;
	}

I converted a buffered image into an array bytes and then use setBlob() to
prepare
To write the blob to the db. Doing a bytes.length I get 372076. When I do my

executeUpdate() I get back 0 indicating nothing was written. Sure enough, in
IJ I
see nothing was written Why? I tried setBinaryStream() changing Blob to
LONVARBINARY.
That didn't work either? Again Why.

Please help me here. Thank you.

Phil Rossomando

-----Original Message-----
From: Brian Spindler [mailto:bspindler@netuitive.com] 
Sent: Tuesday, April 07, 2009 10:23 PM
To: Derby Discussion
Subject: RE: master and slave are not in synch for replicated database

I've tried both:

connect 'jdbc:derby:<db>;shutdown=true';

and

exit; 

both seem to simply hang and I'm forced to do Ctrl+C to get back my command
prompt.  Does that sound right? 

regardless; both result in the same error.


-----Original Message-----
From: Dag H. Wanvik [mailto:Dag.Wanvik@Sun.COM]
Sent: Tue 4/7/2009 4:57 PM
To: Derby Discussion
Subject: Re: master and slave are not in synch for replicated database
 
Brian Spindler <bs...@netuitive.com> writes:

> Guys/Gals,
>
>  
>
> I have taken the following procedure:
>
>  
>
> 1.       Using ij logged into my database
>
> 2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();

I saw in another thread you use embedded. Did you do a shutdown at
this point?
E.g. connect 'jdbc:derby:<db>;shutdown=true'

>
> 3.       Exit ij
>
> 4.       Copy database to slave
>
> 5.       Start slave
>
> 6.       Start master.
>
>  
>
> Then I get this error: 
>
>  
>
> Caused by: ERROR XRE05: The log files on the master and slave are not in
> synch for replicated database 'foo'. The master log instant is 1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for replication
> - replication will be stopped.
>
>                 
>
>  
>
> I thought by freezing/copying etc... they would be in synch?
>
>  
>

-- 
Dag H. Wanvik, staff engineer
Sun Microsystems, Databases (JavaDB/Derby)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101






RE: master and slave are not in synch for replicated database

Posted by Brian Spindler <bs...@netuitive.com>.
I've tried both:

connect 'jdbc:derby:<db>;shutdown=true';

and

exit; 

both seem to simply hang and I'm forced to do Ctrl+C to get back my command prompt.  Does that sound right? 

regardless; both result in the same error.


-----Original Message-----
From: Dag H. Wanvik [mailto:Dag.Wanvik@Sun.COM]
Sent: Tue 4/7/2009 4:57 PM
To: Derby Discussion
Subject: Re: master and slave are not in synch for replicated database
 
Brian Spindler <bs...@netuitive.com> writes:

> Guys/Gals,
>
>  
>
> I have taken the following procedure:
>
>  
>
> 1.       Using ij logged into my database
>
> 2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();

I saw in another thread you use embedded. Did you do a shutdown at
this point?
E.g. connect 'jdbc:derby:<db>;shutdown=true'

>
> 3.       Exit ij
>
> 4.       Copy database to slave
>
> 5.       Start slave
>
> 6.       Start master.
>
>  
>
> Then I get this error: 
>
>  
>
> Caused by: ERROR XRE05: The log files on the master and slave are not in
> synch for replicated database 'foo'. The master log instant is 1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for replication
> - replication will be stopped.
>
>                 
>
>  
>
> I thought by freezing/copying etc... they would be in synch?
>
>  
>

-- 
Dag H. Wanvik, staff engineer
Sun Microsystems, Databases (JavaDB/Derby)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101




Re: master and slave are not in synch for replicated database

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Brian Spindler <bs...@netuitive.com> writes:

> Guys/Gals,
>
>  
>
> I have taken the following procedure:
>
>  
>
> 1.       Using ij logged into my database
>
> 2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();

I saw in another thread you use embedded. Did you do a shutdown at
this point?
E.g. connect 'jdbc:derby:<db>;shutdown=true'

>
> 3.       Exit ij
>
> 4.       Copy database to slave
>
> 5.       Start slave
>
> 6.       Start master.
>
>  
>
> Then I get this error: 
>
>  
>
> Caused by: ERROR XRE05: The log files on the master and slave are not in
> synch for replicated database 'foo'. The master log instant is 1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for replication
> - replication will be stopped.
>
>                 
>
>  
>
> I thought by freezing/copying etc... they would be in synch?
>
>  
>

-- 
Dag H. Wanvik, staff engineer
Sun Microsystems, Databases (JavaDB/Derby)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

Re: master and slave are not in synch for replicated database

Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Brian Spindler <bs...@netuitive.com> writes:

> Guys/Gals,
>
>  
>
> I have taken the following procedure:
>
>  
>
> 1.       Using ij logged into my database
>
> 2.       Run CALL SYSCS_UTIL.SYSCS_FREEZE_DATABASE();

Do you run embedded or client server?

Are there any other live connections at this point?
>
> 3.       Exit ij
>
> 4.       Copy database to slave
>
> 5.       Start slave
>
> 6.       Start master.
>
>  
>
> Then I get this error: 
>
>  
>
> Caused by: ERROR XRE05: The log files on the master and slave are not in
> synch for replicated database 'foo'. The master log instant is 1:104173,
> whereas the slave log instant is 1:103957. This is FATAL for replication
> - replication will be stopped.
>
>                 
>
>  
>
> I thought by freezing/copying etc... they would be in synch?
>