Table of Contents

Search

  1. Preface
  2. Data Replication Overview
  3. Understanding Data Replication
  4. Sources - Preparation and Replication Considerations
  5. Targets - Preparation and Replication Considerations
  6. Starting the Server Manager
  7. Getting Started with the Data Replication Console
  8. Defining and Managing Server Manager Main Servers and Subservers
  9. Creating and Managing User Accounts
  10. Creating and Managing Connections
  11. Creating Replication Configurations
  12. Materializing Targets with InitialSync
  13. Scheduling and Running Replication Tasks
  14. Implementing Advanced Replication Topologies
  15. Monitoring Data Replication
  16. Managing Replication Configurations
  17. Handling Replication Environment Changes and Failures
  18. Troubleshooting
  19. Data Replication Files and Subdirectories
  20. Data Replication Runtime Parameters
  21. Command Line Parameters for Data Replication Components
  22. Updating Configurations in the Replication Configuration CLI
  23. DDL Statements for Manually Creating Recovery Tables
  24. Sample Scripts for Enabling or Disabling SQL Server Change Data Capture
  25. Glossary

Handling Applier Failures

The Applier might end abnormally after different types of failures, including database, network, and system shutdowns or failures.
After an Applier task ends with an error or in response to the
Abort Task
option, do not edit any of the options that affect the distribution of transactions across threads and do not edit the recovery table on the target. Also, do not change the table mappings if transaction records were committed to the target. If you comply with these requirements, the Applier can resume apply processing transparently, without data loss, after you restart it.
During the recovery cycle, each Applier thread must be able to process the transaction records that were not successfully processed during the failed apply cycle. If the distribution of transaction records across the threads changes, the target database might have data integrity issues related to duplicate or skipped records.
Do not edit the following options that can affect the distribution of Applier threads:
  • The
    Applier threads
    field on the
    Runtime Settings
    tab >
    General
    view.
  • The following Applier thread distribution parameters on the
    Runtime Settings
    tab >
    Advanced Settings
    view:
    • apply.subtasks_enabled
    • apply.distribute_by_obj_size_threshold
    • apply.distribute_by_obj_size
    • apply.global_transaction_support
    • apply.max_subtasks
  • The
    Distribute by tables / rows
    option on the
    Map Columns
    tab or in the
    Customize Settings for the Selected Tables
    window
If you must change one of these options after a failure, ensure that the Applier completes the recovery cycle and then use the
Stop Schedule
option to stop replication tasks. The Applier task completes normal processing and then stops in a controlled manner. In this case, the recovery table, IDR_RECOVERY, contains records for each thread.
Also, do not change table mappings after the Applier ends abnormally if at least one Applier thread performed a commit on the target. The recovery table IDR_RECOVERY on the target database records the commits that the threads applied. If the table is empty, none of the threads committed records and you can change table mappings.

0 COMMENTS

We’d like to hear from you!