Hi Folks,

first of all, a Happy New year to all the ones I didn't say personnally in our beautiful community.

Back to business: here is my case

I am in charge of a migration from an old 11.50 Windows 32 bit instance which is a nightmare of performance and stability etc., to a linux Debian with 14.10 FC5 or similar.

The main tables are quite big ( like 300 million rows with BLOB) and the customer is really taking time to take the decision to switch to the new server.

Considering that I have 5 databases, where each one is the exact schema image of the other ones, and each database has only 20ish tables, I thought that using ER could bring many advantages to perform this migration.

I have read again a lot of material about ER, but I am not sure about the options I should take for my replicates, considering the following conditions:
- The windows server is global the source, the linux server is globally the target
- during the last 4 months, I have moved 'manually' the history of the main data table from windows to linux (starting in year 2000) to save time on D day (which is not defined yet), but also to alliviate the windows server from millions of rows. So I have a situation consisting in most of the history on the linux side (more than 300 million rows), and on the other side the windows system keeps being fed constantly by new data (making millions in a month though...)

My idea is to define a replicate being windows and linux, so that the new rows can be transported to linux, something like 'always add on the linux side, and never delete on linux if the row does not exist on windows', some sort of one way copy from windows to linux.

I had seen an option --extratargetrows=keep but it only works with cdr repair and not with cdr define.

I hope I am clear in my description, so what options should I use in my replicate definition?

Thanks, as always

Eric

Hi Folks,

first of all, a Happy New year to all the ones I didn't say personnally in our beautiful community.

Back to business: here is my case

I am in charge of a migration from an old 11.50 Windows 32 bit instance which is a nightmare of performance and stability etc., to a linux Debian with 14.10 FC5 or similar.

The main tables are quite big ( like 300 million rows with BLOB) and the customer is really taking time to take the decision to switch to the new server.

Considering that I have 5 databases, where each one is the exact schema image of the other ones, and each database has only 20ish tables, I thought that using ER could bring many advantages to perform this migration.

I have read again a lot of material about ER, but I am not sure about the options I should take for my replicates, considering the following conditions:
- The windows server is global the source, the linux server is globally the target
- during the last 4 months, I have moved 'manually' the history of the main data table from windows to linux (starting in year 2000) to save time on D day (which is not defined yet), but also to alliviate the windows server from millions of rows. So I have a situation consisting in most of the history on the linux side (more than 300 million rows), and on the other side the windows system keeps being fed constantly by new data (making millions in a month though...)

My idea is to define a replicate being windows and linux, so that the new rows can be transported to linux, something like 'always add on the linux side, and never delete on linux if the row does not exist on windows', some sort of one way copy from windows to linux.

I had seen an option --extratargetrows=keep but it only works with cdr repair and not with cdr define.

I hope I am clear in my description, so what options should I use in my replicate definition?

Thanks, as always

Eric