Behavioral Changes in Streams Replication Manager

Learn about the change in certain functionality of Streams Replication Manager that has resulted in a change in behavior from the previously released version to this version of Cloudera Runtime.

Summary:: The internal topics used by SRM are now created with a replication factor of 3 by default.; Previous behavior:; The internal topics used by SRM were created with a replication factor of 1.; New behavior:; The internal topics used by SRM are created with a replication factor of 3.
Summary:: The default value of SRM Service Metrics Retention Period is increased to 72000 seconds (two hours).; Previous behavior:; The default of value of SRM Service Metrics Retention Period was 3600000 (one hour).; New behavior:; The default value of SRM Service Metrics Retention Period is 720000 seconds (two hours).
Summary:: The SRM Log Format property was moved to the service level from the SRM Service role level, and now applies to both SRM Service and SRM Driver. Changes made to the SRM Log Format property before upgrading to the new version are lost and must be applied again after the upgrade. The name of the log files of SRM Driver and SRM Service will contain the host name. Additionally, SRM Service now accepts all log configurations specified on the Cloudera Manager UI and does a size-based rotation of the log files instead of a time based rotation.; Previous behavior:; The SRM Log Format property only applied to the SRM Service.; New behavior:; The SRM Log Format property applies to both the SRM Driver and Service. The name of the log files of SRM Driver and SRM Service will contain the host name. Additionally, SRM Service now accepts all log configurations specified on the Cloudera manager UI and does a size-based rotation of the log files instead of a time based rotation.
Summary:: When using the default replication policy (DefaultReplicationPolicy), the separator configured with the replication.policy.separator property now applies to the mm2-offsets-syncs and checkpoints internal topics. This change is only significant if you want to export translated group offsets right after upgrading your cluster, but before replication is restarted.
If for example you have been using a custom separator in a previous version and upgrade the cluster, after the upgrade a new set of internal topics will be automatically created using the separator that is configured. These topics, however, will be empty and will only be repopulated with data after replication restarts. Replication will restart once the cluster is up and running and new data is written to a source topic that is included in SRM's allow list.
If you want to export translated consumer group offsets after the upgrade but before replication starts, you must export the translated consumer group offsets from the old topics as the data is not yet available in the new topics. This is done by specifically instructing the srm-control tool to use the default separator, which is the dot (.). For example:
srm-control offsets --config [***CONFIG FILE***] --source [***SOURCE CLUSTER***] --target [***TARGET CLUSTER***] --group [***GROUP***] --export > out.csv
Where the [***CONFIG FILE***] specified in --config contains the following configuration entry:
replication.policy.separator=.; Previous behavior:; The custom separator set with replication.policy.separator only applied to remote (replicated) topics.; New behavior:; The custom separator set with replication.policy.separator is now applied to both remote (replicated) topics as well as the mm2-offsets-sync and checkpoints internal topics.