Syncope-Synch in a clustered environment

[Antony Pulicken]

Hi,

We have multiple instances of Syncope running , and all of them have jobs that synchronizes with AD, which is leading to data duplication errors and data inconsistency. One option available was to remove the ‘synch’ capability from the connectors of all Syncopes except one. But this doesn’t work as the MySQL databases corresponding to each syncope are also synchronized at system level. Following are some of the questions that we have:

• Has Syncope tested in this scenarios? If yes, how exactly we configure syncope to avoid the above issue ?
• If the solution is to have synch running only on one instance, how will we handle the fail over?
• If one instance fails while the synch is going on, will the second instance do any recovery or does it start from where the first one failed? Are there any recommendations for these?

Please let us know your thoughts.

Note: We are using an older version of Syncope (0.5.2) and will be migrating to the latest version soon. Please let us know in case the above issues are already handled in the current versions.

Regards,
Antony.

[Francesco Chicchiriccò]

On 09/11/2011 06:24, Antony Pulicken wrote:

Hi,

We have multiple instances of Syncope running , and all of them have jobs that synchronizes with AD, which is leading to data duplication errors and data inconsistency. One option available was to remove the �synch� capability from the connectors of all Syncopes except one. But this doesn�t work as the MySQL databases corresponding to each syncope are also synchronized at system level. Following are some of the questions that we have:

• Has Syncope tested in this scenarios? If yes, how exactly we configure syncope to avoid the above issue ?
• If the solution is to have synch running only on one instance, how will we handle the fail over?
• If one instance fails while the synch is going on, will the second instance do any recovery or does it start from where the first one failed? Are there any recommendations for these?

Please let us know your thoughts.

Note: We are using an older version of Syncope (0.5.2) and will be migrating to the latest version soon. Please let us know in case the above issues are already handled in the current versions.

Hi Antony,
the problems you report above will be fixed with issue 203 [1]: as you can read, the fix will be applied to the trunk (0.7-SNAPSHOT) only, and will be released with Ritornello (0.7), expected by the end of 2011.
I believe that such fix wouldn't be easy to backport to any older revision, so I guess that upgrading will be a nice option, for you needs.

You can star [1] if you want to be notified when the issue is fixed.

Regards.

[1] http://code.google.com/p/syncope/issues/detail?id=203

-- 
Francesco Chicchiricc�

"Computer Science is no more about computers than astronomy
is about telescopes." (E. W. Dijkstra)

[Francesco Chicchiriccò]

On 09/11/2011 08:27, Francesco Chicchiricc� wrote:

On 09/11/2011 06:24, Antony Pulicken wrote:

Hi,

We have multiple instances of Syncope running , and all of them have jobs that synchronizes with AD, which is leading to data duplication errors and data inconsistency. One option available was to remove the �synch� capability from the connectors of all Syncopes except one. But this doesn�t work as the MySQL databases corresponding to each syncope are also synchronized at system level. Following are some of the questions that we have:

• Has Syncope tested in this scenarios? If yes, how exactly we configure syncope to avoid the above issue ?
• If the solution is to have synch running only on one instance, how will we handle the fail over?
• If one instance fails while the synch is going on, will the second instance do any recovery or does it start from where the first one failed? Are there any recommendations for these?

Please let us know your thoughts.

Note: We are using an older version of Syncope (0.5.2) and will be migrating to the latest version soon. Please let us know in case the above issues are already handled in the current versions.

Hi Antony,
the problems you report above will be fixed with issue 203 [1]: as you can read, the fix will be applied to the trunk (0.7-SNAPSHOT) only, and will be released with Ritornello (0.7), expected by the end of 2011.
I believe that such fix wouldn't be easy to backport to any older revision, so I guess that upgrading will be a nice option, for you needs.

You can star [1] if you want to be notified when the issue is fixed.

Issue [1] has just been fixed on trunk.

[Antony Pulicken]

Thanks a lot for the fix Francesco. We are planning to upgrade soon to the latest version of syncope. Do you think it's a good idea to wait till Ritornello is released, rather than upgrading to the current version in the trunk? Please let us know your thoughts.

Thanks and Regards,
Antony.

2011/12/1 Francesco Chicchiriccò <chicch...@gmail.com>

On 09/11/2011 08:27, Francesco Chicchiriccò wrote:

On 09/11/2011 06:24, Antony Pulicken wrote:

Hi,

We have multiple instances of Syncope running , and all of them have jobs that synchronizes with AD, which is leading to data duplication errors and data inconsistency. One option available was to remove the ‘synch’ capability from the connectors of all Syncopes except one. But this doesn’t work as the MySQL databases corresponding to each syncope are also synchronized at system level. Following are some of the questions that we have:

• Has Syncope tested in this scenarios? If yes, how exactly we configure syncope to avoid the above issue ?
• If the solution is to have synch running only on one instance, how will we handle the fail over?
• If one instance fails while the synch is going on, will the second instance do any recovery or does it start from where the first one failed? Are there any recommendations for these?

Please let us know your thoughts.

Note: We are using an older version of Syncope (0.5.2) and will be migrating to the latest version soon. Please let us know in case the above issues are already handled in the current versions.

Hi Antony,
the problems you report above will be fixed with issue 203 [1]: as you can read, the fix will be applied to the trunk (0.7-SNAPSHOT) only, and will be released with Ritornello (0.7), expected by the end of 2011.
I believe that such fix wouldn't be easy to backport to any older revision, so I guess that upgrading will be a nice option, for you needs.

You can star [1] if you want to be notified when the issue is fixed.

Issue [1] has just been fixed on trunk.

Regards.

[1] http://code.google.com/p/syncope/issues/detail?id=203

-- 
Francesco Chicchiriccò

"Computer Science is no more about computers than astronomy
is about telescopes." (E. W. Dijkstra)