Avoiding insert and update errors in Instance Data Replication

  • Release version: Xanadu
  • Updated August 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Avoiding insert and update errors in Instance Data Replication

    This guidance explains how to prevent insert and update failures in Instance Data Replication (IDR) by properly configuring thesysclassnamefilter in producer replication sets. These recommendations specifically apply to producer replication sets created before the Utah release.

    Show full answer Show less

    Key Practices for Avoiding Errors

    • When replicating a parent table and its child tables: Add a sysclassname filter to the parent table’s outbound entry in the producer replication set. This avoids unique key violations caused by duplicate insert attempts into the parent table.
    • Insert failure scenario: Without the filter, replicating a child table record triggers two inserts with the same sysid into the parent table, causing failures.
    • Update failure scenario: If a new child record is created on the producer, IDR initially inserts it only into the parent table on the consumer. Subsequent updates to the child record fail because the child record does not yet exist on the consumer instance.
    • Filter configuration details: Identify the sysclassname value (e.g., "Task" for the Task [task] table) and add a filter like [Task Type] [is] [Task] to the parent table’s outbound entry to specify which child records to replicate along with the parent.
    • If replicating only the parent table: The filter is optional but recommended if child tables are not replicated.
    • If replicating only child tables: The filter on the parent is optional but necessary if the parent table is also replicated.
    • For existing replication sets: Edit the parent table outbound entry to include the sysclassname filter whenever child tables are involved.

    Why This Matters

    Proper use of the sysclassname filter ensures data integrity and prevents replication errors related to duplicate keys and missing child records during insert and update operations. This configuration is crucial for stable and accurate data synchronization between producer and consumer instances.

    Expected Outcomes

    • Elimination of insert and update failures in IDR related to parent-child table replication.
    • More reliable replication payload processing without unique key violations.
    • Improved consistency of replicated data across instances.

    You can avoid insert and update failures in Instance Data Replication (IDR) by specifying a class name filter in the producer replication set.

    Important:
    This topic only applies to producer replication sets created prior to the Utah release.

    When you replicate a parent table and one or more child tables, you must add a sys_class_name filter to the parent table in the outbound entry of your producer replication set. If the sys_class_name filter is missing, insert and update failures appear in Instance Data Replication > Replication Payload Error in the following scenarios:

    • A failed insert occurs when a record in the child table is replicated because the system attempts two inserts with the same sys_id to the parent table. Adding the sys_class_name filter to the parent prevents the unique key violation during the INSERT into the parent table.
    • A new record is added to a replicated child table on the producer instance. Instance Data Replication (IDR) initially creates the record in the parent table on the consumer, but not the child table. If the child record is changed on the producer instance, during replication a failed update occurs on the child table in the consumer instance because the record only exists in the parent table.

    If the table is a parent, decide if you want to replicate any of its child tables.

    • If you want to replicate one or more child tables, you must identify the sys_class_name value for the parent table, and then add a corresponding sys_class_name filter to the parent table.

      For example, Task Type is the label for sys_class_name on the Task [task] table. To start replicating the incidents in addition to tasks, you must add [Task Type] [is] [Task] to the outbound entry for the Task [task] table.

    • If you only want to replicate the parent table, the filter is optional.
    • If the parent table is already being replicated, you must edit the parent and add the sys_class_name filter.

    If the table is a child, decide if you want to replicate its parent.

    • If you want to replicate the parent table as well, you must identify the sys_class_name value for the parent table, and then add a corresponding sys_class_name filter to the parent table.

      For example, Task Type is the label for sys_class_name on the Task [task] table. To start replicating tasks in addition to incidents, you must add [Task Type] [is] [Task] to the outbound entry for the Task [task] table.

    • If you only want to replicate the child table, the filter is optional.
    • If one or more child tables are already being replicated, you must add the sys_class_name filter to the parent.