ER Enhancements XML ATS/RIS files
in IDS 11.50xC4
New Event Alarms
Background Sync / Check
Parallel Sync /Check
Checks with in-flight data
We are getting fairly close to releasing IDS11.50xC5, and it containssome fairly significant replication enhancements. However,before I get into the new items in 11.50xC5, I want to spend a bit oftime discussing the things which were added in 11.50xC4. Wecould think of this as sort of a 'prelude' to the new stuff which willbe in 11.50xC5. In this posting, I'm only going to give abrief description of each of the enhancements. Later postingswill go into more detailed usage of each of the enhancements.
This enhancement is activated by a new option on the cdr define serverand cdr modify servercommands.
-X --atsrisformat=[text|xml|both] ATS and RIS file format
deletewins'. Other than the fact that deletewins does not convert anupdate into an insert, it behaves as timestamp conflict resolution.
cdr checkand cdr sync commandscan now be executed as a background task using the server admincomponent. Up till now the checn check and cdr sync commandswere done as a foreground task which tied up the invoker's session. To request that the check and/or sync be done as a backgroundtask, the user simply includes the --background(-B) option on the cdr check and cdr sync command. This options is available for both replicate and replsetcommands. If doing a background sync/check, it is wise toalso use the check and/or sync as a namedtask ( see below).
By making the sync/check a named task, we make it possible to view theprogress of the sync or check command when it is performed as abackground task. To name the sync or check command, use the--name=<task_name> option on the sync or check task. To monitor the progress of the task, use the cdr stats check or cdr stats synccommand. (see below).
cdr stats checkand cdr stats synccommands allow the user to monitor the progress of the running checkand/or sync named task. As part of the cdr stats command, wealso display an estimated completion time based on the rate that we areprocessing data and the amount of data to be processed. Sincethere is a repeat option as part of the command, we can also see arunning progress indication as the work is being done.
--process= ### (-p)option in the cdr sync replset or cdr check replset command. Theparameter to the --process option is the number of processes which willbe spawned to perform the check or sync. As a rule of thumb,the number of processes should not exceed the number of processorsavailable,.
cdrcheck is that it does not consider in-flight operations. It needs to be understood that on an active system, data willalways be in a state of flux and that data on various nodes are alwayssomewhat 'out of sync'. The degree of this is more or lessdetermined by the latency between each of the nodes. Up donow, cdr check did not consider in-flight operations and would reportthings as being out of sync when in fact the only problem was that theupdate operation had simply not yet been received on one of the nodes.
We have added a 'recheck' for rows which we think are out-of-sync. By default, we only recheck once and then only after onesecond has passed. This recheck can be adjusted by using the --inprogress=### (-i)where ### represents the number of seconds that we will attempt toretry the check before we consider the row to be truly out-of-sync. Using this option should reduce, if not eliminate the falsefailures that would otherwise be reported from a cdr check operation
cdrcheck repl/replset --repair), we nowperform verification of any out-of-sync rows which wererepaired. This is subject to the --inprogress option (seeabove). If we are not able to verify any of the repair workwhich was done, then we will display the rows which could not berepaired and successfully verified.