Using ER for Migration from 10.0 to 11.5

We are in the process of migrating from one server running IDS 10.00.UC5 32 bit Red Hat Linux 3 to another running IDS 11.50.FC3 64 bit Red Hat Linux 5. I would like to us ER to keep the new server in sync with the old server until we actually migrate. I have unloaded the data from the old server and loaded it into the new server. I have defined and started replication from the old server to the new server for all tables. What is the best way to syncronize the new server with the old server in order to capture the changes that have occurred since the start of the old server unload and the start of replication? I'm more interested in minimizing the impact to the old server (production) when syncronizing large tables than I am with the speed of the syncronization. Is the 'cdr check replicate' command with the repair option preferred or is the 'cdr sync replicate' option preferred in this scenario? Thanks, Andrew

> What is the best way to syncronize the new server with the old server in order to capture the changes that have occurred since the > start of the old server unload and the start of replication? > I'm more interested in minimizing the impact to the old server (production) when syncronizing large tables than I am with the speed > of the syncronization. > Is the 'cdr check replicate' command with the repair option preferred or is the 'cdr sync replicate' option preferred in this > scenario? Andrew, personally, I'd stay away from both "cdr check" and "cdr sync" for big tables (not officially supported on v10, only in v>=11, AFAIK). Crashed my production instances with both. Admittedly, few versions ago (now running IDS10.FC8W2) but haven't had courage (nor management approval :o)) to try it again. Since you're posting the question I will presume you don't have any discriminator column(s) in those tables to serve as a cut-off filter. Also, you're obviously time constrained for downtime. Since I know you're a HPL_through_pipes wizzard :) how about the next (the full plan, without ER running yet): 1. on new instance, create empty database, the tables, views, stored procs and triggers (they don't trigger by default on ER inserted rows), but no PK's, FK's, indexes and unique constraints (so, whatever creates underlying index) 2. define your HPL jobs to transfer all the data 3. take _very_ short downtime, define ER participants, replicates, ... (all scripted in advance, of course) 4. activate the replicates, BUT issue "cdr stop" on the target (v11) 5. bring the whole new environment back online

On Dec 19, 4:41 pm, "Andrew Ford" <af...@networkip.net> wrote: > We are in the process of migrating from one server running IDS 10.00.UC5 32 bit Red Hat Linux 3 to another running IDS 11.50.FC3 64 > bit Red Hat Linux 5. > > I would like to us ER to keep the new server in sync with the old server until we actually migrate. > > I have unloaded the data from the old server and loaded it into the new server. > > I have defined and started replication from the old server to the new server for all tables. > > What is the best way to syncronize the new server with the old server in order to capture the changes that have occurred since the > start of the old server unload and the start of replication? > > I'm more interested in minimizing the impact to the old server (production) when syncronizing large tables than I am with the speed > of the syncronization. > > Is the 'cdr check replicate' command with the repair option preferred or is the 'cdr sync replicate' option preferred in this > scenario? > > Thanks, > > Andrew Andrew, my suggested method would be: 1) Install IDS 10.00.UC5 on the new box 2) Create the same Chunk layout as on the old box 3) Create an ontape Level-0-Backup and pipe it via ssh to the new box where you start the Restore using "ontape -p" Example: ontape -s -L 0 -t STDIO | ssh <new_host> '. <ifx_environment_script> && ontape -p -t STDIO' 4) Establish HDR in asynchron. mode between the old and new box 5) This will automatically synchronize the delta and from then on keep the two instances in sync without much overhead and pain If you are then ready to switch to the new box, you just do a migration to IDS 11.5 which could be normally done in a few minutes. There is some small downtime, but from my point of view this method is more robust than trying to synchronize a complete IDS instance with ER. You can find instructions how to setup HDR between two nodes in the IDS Wiki: http://www.informix-zone.com/idswiki/doku.php/idsdev:ha:hdr HTH. -Eric

> Andrew, > > personally, I'd stay away from both "cdr check" and "cdr sync" for big > tables (not officially supported on v10, only in v>=11, AFAIK). > Crashed my production instances with both. Admittedly, few versions > ago (now running IDS10.FC8W2) but haven't had courage (nor management > approval :o)) to try it again. > > Since you're posting the question I will presume you don't have any > discriminator column(s) in those tables to serve as a cut-off filter. > Also, you're obviously time constrained for downtime. > > Since I know you're a HPL_through_pipes wizzard :) how about the next > (the full plan, without ER running yet): > > 1. on new instance, create empty database, the tables, views, stored > procs and triggers (they don't trigger by default on ER inserted > rows), but no PK's, FK's, indexes and unique constraints (so, whatever > creates underlying index) > 2. define your HPL jobs to transfer all the data > 3. take _very_ short downtime, define ER participants, replicates, ... > (all scripted in advance, of course) > 4. activate the replicates, BUT issue "cdr stop" on the target (v11) > 5. bring the whole new environment back online > >>From this moment on ER is trying replicate your data, but the queue > will build for the target since you've stopped the datasync threads > (or rather all ER threads). > > 6. Start your HPL jobs and wait until the data is transferred > 7. build your indexes on target > 8. Issue "cdr start" on the target. This is when the disaster > strikes :) > > Of course, you'll have as many failures and ATS/RIS files as the > transactions which include rows duplicated by both ER and HPL, but you > have a good friend there: "cdr repair ats/ris". It works only on > generated ATS/RIS files, not on full tables so it's as selective as it > gets. And it does _excellent_ job of fixing the for whatever reason > failed transactions. Saved me quite a few times, after learning about > it administering ER became sooo boring :o) > > This was pretty much our original plan in a similar situation. > Fortunately, we got enough downtime to rebuild the whole instance on > the new storage instead going through all this. Obviously, I'm looking > for someone downtime-constrained and desperate enough to test > this...:) > > HTH > > Davorin Thanks for the replies Nilesh, Davorin and Eric. Nilesh, Is it possible that cdr sync could be less intrusive to production than cdr check? Yes, cdr sync will send each row over to the target but cdr sync will bypass the logical logs and stick the all of the rows directly in the sendQ to be transmitted to the target. With cdr check we will still perform the same amount of read I/O on production as cdr sync(still have to look at every row on the source server, right?) plus the additional I/O to the logical logs for the update of inconnsistent rows so they may be sent to the target via ER and the additional CPU overhead for computing and comparing the checksums. I don't have much experience with either cdr check or cdr sync, so I could be totally wrong here. Davorin, HPL over named pipes is definintely how I got the data over there in the first place, so no problem there. But letting transactions spool on the source server while I transfer data and build indexes and constraints scares my boss. Mostly because we had problems with ER and a big backlog of spooled transactions so management is reluctant to let that happen again (even though this was a long time ago, 7.31 days. I'm sure things are a lot better now, they must be because we have not had similar problems for years). cdr check or cdr sync have yet to crash any of our engines so they're willing to let me use them. Thanks for the cdr repair ats/ris tip, I did not know this existed and sounds useful. Eric, I agree, using HDR would be the most robust (and simplest) solution but there are 2 major hurdles preventing me from migrating this way. Hurdle #1: The source server already has an HDR Secondary. If the old server was running v11 I could setup the new server as a RSS node and migrate this way if hurdle #2 didn't exist. Hurdle #2: The chunk/dbspace configuration for the new server is different. Andrew