We have a running replication with ~30 remotes, all currently under 6.0.x.
Since are now rolling out new hardware and also a additional software solution, based on sql anywhere 10, we would like to upgrade the remotes step by step to 10.0.x, but still (for the moment) running 6.0.x on the main site.
We did the following test:
Here what we have after the conversion/upgrade
Also putting the old transaction log did not help, since we still have a gap between 0023453469 and 0000338688.
What step did I miss when upgrading the remote db to v 10 ?
You have to make sure that the rebuilt V10 database uses the same log offset as before. Otherwise, a gap will occur, stopping the replication.
This can be done by using DBUNLOAD -ar (I'm not sue whether Sybase Central supports this) or by explicitly setting the log offset right after the reload with DBLOG -x .
The docs have a good article on this topic (here for SA 11.0.1 but AFAIK, also applying to any other current version).
If you're upgrading from a pre-V10 version (as in your case), you should additionally make sure that the remote installation includes the "Pre-10 physical store library" (i.e. dboftsp.dll) in order to be able to read the V6 logs.
dbunload -c "uid=dba;pwd=XXXXXX;dbf=ccPos123UG" -ar new10 SQL Anywhere-Dienstprogramm Entladen Version 10.0.1.4122 Verbindungsaufnahme und Initialisierung Benutzer- und Gruppendefinitionen werden entladen Tabellendefinitionen werden entladen Indexdefinitionen werden entladen Funktionen werden entladen Ansichtdefinitionen werden entladen Prozeduren werden entladen Trigger werden entladen SQL Remote-Definitionen werden entladen MobiLink-Definitionen werden entladen * SQL-Fehler: Primärschlüssel für Tabelle 'temp_option' ist nicht eindeutig
This happens when running dbunload under linux. Doing the very same under windows 7 with build 10.0.1.3750 completes correctly.
Any ideas how to work arround this unload problem ?
answered 20 Oct '10, 23:24