Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Arnulfo Martinez Ruiz asked how to migrate databases using Enterprise Replication from Informix 11.7 on AIX to 12.10 on Red Hat. Art Kagel advised targeting 14.10, setting up new servers, adding them to ER and replicating bidirectionally for fail-back. Paul Watson suggested the syscdr conversion script or rebuilding replication. Arnulfo agreed to recommend 14.10.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Arnulfo Martinez Ruiz — source: IBM Community (ConnectedCommunity.org) Informix forum
Hello, Happy New Year to all
I have a client who is going to migrate his system from AIX 5.3 to Linux Red Hat 7.8
In this process he is going to migrate his databases from Informix 11.7 to Informix 12.10
My question is about what is the process to migrate databases that use Enterprise Replication
Thank you for your comments
------------------------------
Arnulfo Martinez Ruiz
------------------------------
↪ replying to Arnulfo Martinez Ruiz
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Arnulfo:
First, note that your client should be migrating to v14.10 not v12.10. That is because v15.0 has been released and within the year IBM will likely announce end-of-support for v12.10 to take effect in 2026 or 2027.
On to your question. If the client is already using ER, then you just have to set up the new servers on Linux, then using the oncsm on the new server (not the v11.70 version) add the new servers and replicate the tables to the new server. The replication should be bidirectional so that if they discover any problems when they move their applications over they can easily fail back to using the original AIX cluster until they work out a resolution. Once the new servers have synced with the existing cluster, then the client can move their applications to point to the new servers.
Another good reason to migrate to v14.10 instead of to v12.10 is the migrate database option in v14.10 which will automatically create replicants for every table in a single command.
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
↪ replying to Art Kagel
Arnulfo Martinez Ruiz — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks Art
I agree with migrating to Informix version 14.10. It is now a financial matter for the client. Shouldn't the syscdr database be migrated?
------------------------------
Arnulfo Martinez Ruiz
------------------------------
↪ replying to Arnulfo Martinez Ruiz
Paul Watson — source: IBM Community (ConnectedCommunity.org) Informix forum
look in the $INFORMIXDIR/etc (??) for the syscdr conversion script.
Generally upgrade binary, start engine without CDR, run the conversion script. start CDR or just drop syscdr and rebuild the replication
Cheers
Paul
↪ replying to Arnulfo Martinez Ruiz
Art Kagel — source: IBM Community (ConnectedCommunity.org) Informix forum
Enabling ER on the Linux server(s) should create syscdr.
If they are upgrading from 11.70 which is already out-of-support to v12.10 then they will be paying for new licenses anyway. Why not pay for v14.10? or once v12.10 is paid for you can upgrade to v14.10 for free.
What am I missing?
Art
------------------------------
Art S. Kagel, President and Principal Consultant
ASK Database Management Corp.
www.askdbmgt.com
------------------------------
↪ replying to Art Kagel
Arnulfo Martinez Ruiz — source: IBM Community (ConnectedCommunity.org) Informix forum
Ok Art
I will make the recommendation to the client.
Thanks
------------------------------
Arnulfo Martinez Ruiz
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.