Mixed 6.0.x and 10.0.1.x replication

[Former Member]

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:

• Upgrade a remote via unload/reload in sybase central to 10.0.x
• Started dbremote v10, and it did receive messages and did apply them to the database
• But as soon as it did try to scan the log files for sending, it complained about missing logfiles (Log-Offset 0023451921 not found)

Here what we have after the conversion/upgrade

• dblog of the original remote database V6 Dateiversion ist 39 Log beginnt bei Offset 0000216650 Log endet am Offset 0023453469

• dblog of the converted remote database v10 Log beginnt bei Offset 0000338688 Log endet am Offset 0000398805

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 ?

André

[VolkerBarth · Accepted solution]

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.

[Breck_Carter · Accepted solution]

For V10 see http://dcx.sybase.com/index.html#html/dbugen10/ug-wrtluu.html - note that V10.0.1 documentation does exist in DCX, it's just not accessible via hyperlinks from the local compiled HTML Help until Version 11.

[Former Member · Accepted solution]

Thanks. Works fine once I got arround the temp_option unload problem.

[Former Member]

Hmmm...

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 ?

[Breck_Carter]

translate.google.com does a pretty good job, too bad I don't know what the answer is: "dbunload-c "uid = dba; pwd = XXXXXX; dbf = ccPos123UG"-ar new10 SQL Anywhere Unload utility version 10.0.1.4122 connection and initialization of user and group definitions unload table definitions are unloaded index definitions unload functions are discharged view definitions unload procedures unloading triggers are unloaded Remote SQL definitions are discharged MobiLink definitions are discharged * SQL error: primary key for table 'temp_option' is not unique"

[Breck_Carter]

Is temp_option one of your tables?

[VolkerBarth]

@André: This happens with exactly the same database? - FWIW, I had some issues with non-unique PKs during migrations when using char datatypes and when the blank padding behaviour was different between old and new database. Then tow formerly different PK values like 'A' and 'A ' may be treated as identical in the new database and as such, lead to PK conflicts.

[Former Member]

No,

it must be some kind of system table.

Translation seems to have worked good enough. It struggles over unloading table temp_option, where the primarykey seems to be NOT unique. But looking at the database I did not find anything with that name.

It's also strange, that it fails in unloading mobilink stuff, since in 6.x mobilink did not exist at all.

Next week we will upgrade a first productive remote, so we will see if this one also shows that "behaviour"

[Former Member]

@Volker: The strange thing is: Unloading on Linux 10.0.1.4122 (and also 10.0.1.403?) does throw this error, but doing the same (very same db file) under windows with 10.0.1.3750 just works.

I'm now hesitant to install the latest ebf on my windows system 😞

[Former Member]

Under Windows 10.0.1.4135 the unload/reload also works, seems to be some kind of linux related problem. Perhaps some locale settings ?