Replication Validation

Each Topic in a replication Destination can configure a unique set of validation checks. By default, all of these checks are applied.

Described below are the available checks for replication validation. Expand each item for more details.

Note: "This instance" refers to the instance sending messages via replication, and the "downstream instance" refers to the instance receiving messages via replication.

txlog

Validates that the topic is contained in the transaction log of the downstream instance.

An error on this validation check indicates that this instance is replicating a topic that is not in the transaction log on the downstream instance. This means that the downstream instance is not persisting the messages in a way that can be used for replication, replay, or used as the basis for a queue.

replicate

Validates that the topic is replicated from the downstream instance back to this instance.

An error on this validation check indicates that this instance is replicating a topic to the downstream instance that is not being replicated back to this instance. This means that any publishes or updates to the topic on the downstream instance are not replicated back to this instance.

sow

Validates that if the topic is a SOW/Topic in this instance, it must also be a SOW/Topic in the downstream instance.

An error on this validation check indicates that this instance is replicating a topic to the downstream instance that is a SOW/Topic on this instance but is not a SOW/Topic on the downstream instance. This means that the topic has different behavior on the downstream instance, and does not maintain the current value of records in the topic in the SOW.

cascade

Validates that the downstream instance must enforce the same set of validation checks for this Topic as this instance does.

When relaxing validation rules for a topic that the downstream instance itself replicates, adding an exclusion for cascade is often necessary as well.

An error on this validation check indicates that this instance enforces a validation check for a topic that the downstream instance does not enforce when that instance replicates the topic.

To understand the impact of this validation check, consider the validation checks that the downstream instance enforces. If the downstream instance enforces the appropriate validation checks, this instance can exclude the cascade check.

It is sometimes necessary to exclude this check as part of a rolling upgrade, and then to leave this exclusion in place until all instances can be taken offline at the same time. If the cascade check is the only check being excluded on any instance, the topology can be considered to meet validation rules (and the cascade exclusion can be safely removed during a maintenance window when all of the instances can be updated simultaneously).

queue

Validates that if the topic is a queue in this instance, it must also be a queue in the downstream instance.

A distributed queue will not function correctly if one of the instances it is replicated to does not define the topic as a queue.

This is a mandatory validation check, and cannot be excluded.

keys

Validates that if the topic is a SOW/Topic in this instance, it must also be a SOW/Topic in the downstream instance and the SOW in the downstream instance must use the same Key definitions.

An error on this validation check indicates that this instance is replicating a topic to the downstream instance that is a SOW/Topic on both instances, but that the definition of message identity (the Key configuration for the topic) does not match on the two instances. This means that the contents of this topic may be different on these two instances for the same set of messages published.

replicate_filter

Validates that if this topic uses a replication filter, the downstream instance must use the same replication filter for replication back to this instance.

An error on this validation check indicates that this instance uses a replication filter for a topic that the downstream instance does not use when it replicates the topic. This means that, given the same set of publishes, the downstream instance may replicate a different set of messages than are replicated to that instance. This would produce inconsistent data across the set of replicated instances.

queue_passthrough

Validates that if the topic is a queue in this instance, the downstream instance must support passthrough from this group.

An error on this validation check indicates that this instance does not pass through messages for one or more groups that the queue is replicated from. This could lead to a situation where a queue message is undeliverable if a network connection is unavailable or if additional instances are added to the set of instances that contain the queue.

queue_underlying

Validates that if the topic is a queue in this instance, it must use the same underlying topic definition and filters in the downstream instance.

This is a mandatory validation check, and cannot be excluded.

The sample below shows how to exclude validation checks for a replication destination. In this sample, the Topic does not require the downstream destination to replicate back to this instance, and does not require that the downstream destination enforce the same configuration checks for any downstream replication of this topic.

<Destination>
    ...
    <Topic>
        <MessageType>json</MessageType>
        <Name>MyStuff-VIEW</Name>
        <ExcludeValidation>replicate,cascade</ExcludeValidation>
    </Topic>
    ...
</Destination>