This is an automated email from the ASF dual-hosted git repository.
liuyu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/pulsar.git
The following commit(s) were added to refs/heads/master by this push:
new 8378e64 feat(docs): add more limitations for replicated subscriptions
(#13230)
8378e64 is described below
commit 8378e6411f0c5452defff2fe938cb17fe1fc967b
Author: Eric Shen <[email protected]>
AuthorDate: Wed Dec 15 09:06:39 2021 +0800
feat(docs): add more limitations for replicated subscriptions (#13230)
* feat(docs): add more limitations for replicated subscriptions
Signed-off-by: ericsyh <[email protected]>
* Update site2/docs/administration-geo.md
Co-authored-by: Matteo Merli <[email protected]>
* apply comments to all versions
Signed-off-by: ericsyh <[email protected]>
* Update site2/docs/administration-geo.md
i see, got it.
Co-authored-by: Anonymitaet <[email protected]>
* apply comments for all versions
Signed-off-by: ericsyh <[email protected]>
Co-authored-by: Matteo Merli <[email protected]>
Co-authored-by: Anonymitaet <[email protected]>
---
site2/docs/administration-geo.md | 3 ++-
site2/website-next/docs/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.4.0/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.4.1/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.4.2/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.5.0/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.5.1/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.5.2/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.6.0/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.6.1/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.6.2/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.6.3/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.6.4/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.7.0/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.7.1/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.7.2/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.7.3/administration-geo.md | 3 ++-
site2/website-next/versioned_docs/version-2.8.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.4.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.4.1/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.4.2/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.5.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.5.1/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.5.2/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.6.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.6.1/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.6.2/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.6.3/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.6.4/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.7.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.7.1/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.7.2/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.7.3/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.8.0/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.8.1/administration-geo.md | 3 ++-
site2/website/versioned_docs/version-2.8.2/administration-geo.md | 3 ++-
36 files changed, 72 insertions(+), 36 deletions(-)
diff --git a/site2/docs/administration-geo.md b/site2/docs/administration-geo.md
index 5f241d2..5e42508 100644
--- a/site2/docs/administration-geo.md
+++ b/site2/docs/administration-geo.md
@@ -214,4 +214,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website-next/docs/administration-geo.md
b/site2/website-next/docs/administration-geo.md
index 159172f..d956817 100644
--- a/site2/website-next/docs/administration-geo.md
+++ b/site2/website-next/docs/administration-geo.md
@@ -245,4 +245,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.4.0/administration-geo.md
b/site2/website-next/versioned_docs/version-2.4.0/administration-geo.md
index de57394..a920a9e 100644
--- a/site2/website-next/versioned_docs/version-2.4.0/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.4.0/administration-geo.md
@@ -166,4 +166,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.4.1/administration-geo.md
b/site2/website-next/versioned_docs/version-2.4.1/administration-geo.md
index 5b9cf98..a920a9e 100644
--- a/site2/website-next/versioned_docs/version-2.4.1/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.4.1/administration-geo.md
@@ -166,4 +166,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
\ No newline at end of file
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.4.2/administration-geo.md
b/site2/website-next/versioned_docs/version-2.4.2/administration-geo.md
index 7e5ddd4..037be9c 100644
--- a/site2/website-next/versioned_docs/version-2.4.2/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.4.2/administration-geo.md
@@ -165,4 +165,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
\ No newline at end of file
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
diff --git
a/site2/website-next/versioned_docs/version-2.5.0/administration-geo.md
b/site2/website-next/versioned_docs/version-2.5.0/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.5.0/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.5.0/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.5.1/administration-geo.md
b/site2/website-next/versioned_docs/version-2.5.1/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.5.1/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.5.1/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.5.2/administration-geo.md
b/site2/website-next/versioned_docs/version-2.5.2/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.5.2/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.5.2/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.6.0/administration-geo.md
b/site2/website-next/versioned_docs/version-2.6.0/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.6.0/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.6.0/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.6.1/administration-geo.md
b/site2/website-next/versioned_docs/version-2.6.1/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.6.1/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.6.1/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.6.2/administration-geo.md
b/site2/website-next/versioned_docs/version-2.6.2/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.6.2/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.6.2/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.6.3/administration-geo.md
b/site2/website-next/versioned_docs/version-2.6.3/administration-geo.md
index cb2ba73..42d3230 100644
--- a/site2/website-next/versioned_docs/version-2.6.3/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.6.3/administration-geo.md
@@ -210,4 +210,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.6.4/administration-geo.md
b/site2/website-next/versioned_docs/version-2.6.4/administration-geo.md
index 751094e..25605af 100644
--- a/site2/website-next/versioned_docs/version-2.6.4/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.6.4/administration-geo.md
@@ -166,4 +166,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.7.0/administration-geo.md
b/site2/website-next/versioned_docs/version-2.7.0/administration-geo.md
index 37b52e2..82db21d 100644
--- a/site2/website-next/versioned_docs/version-2.7.0/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.7.0/administration-geo.md
@@ -215,4 +215,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.7.1/administration-geo.md
b/site2/website-next/versioned_docs/version-2.7.1/administration-geo.md
index c8ac6ba..f0170ad 100644
--- a/site2/website-next/versioned_docs/version-2.7.1/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.7.1/administration-geo.md
@@ -211,4 +211,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.7.2/administration-geo.md
b/site2/website-next/versioned_docs/version-2.7.2/administration-geo.md
index c8ac6ba..f0170ad 100644
--- a/site2/website-next/versioned_docs/version-2.7.2/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.7.2/administration-geo.md
@@ -211,4 +211,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.7.3/administration-geo.md
b/site2/website-next/versioned_docs/version-2.7.3/administration-geo.md
index c8ac6ba..f0170ad 100644
--- a/site2/website-next/versioned_docs/version-2.7.3/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.7.3/administration-geo.md
@@ -211,4 +211,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git
a/site2/website-next/versioned_docs/version-2.8.0/administration-geo.md
b/site2/website-next/versioned_docs/version-2.8.0/administration-geo.md
index ad0a8a8..ec82bad 100644
--- a/site2/website-next/versioned_docs/version-2.8.0/administration-geo.md
+++ b/site2/website-next/versioned_docs/version-2.8.0/administration-geo.md
@@ -211,4 +211,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.4.0/administration-geo.md
b/site2/website/versioned_docs/version-2.4.0/administration-geo.md
index 8fd7d80..91829c9 100644
--- a/site2/website/versioned_docs/version-2.4.0/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.4.0/administration-geo.md
@@ -154,4 +154,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.4.1/administration-geo.md
b/site2/website/versioned_docs/version-2.4.1/administration-geo.md
index 2fe64b5..beca04a 100644
--- a/site2/website/versioned_docs/version-2.4.1/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.4.1/administration-geo.md
@@ -154,4 +154,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
\ No newline at end of file
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.4.2/administration-geo.md
b/site2/website/versioned_docs/version-2.4.2/administration-geo.md
index 237c4cc..c823335 100644
--- a/site2/website/versioned_docs/version-2.4.2/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.4.2/administration-geo.md
@@ -153,4 +153,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
\ No newline at end of file
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.5.0/administration-geo.md
b/site2/website/versioned_docs/version-2.5.0/administration-geo.md
index 8c62a45..4cb0577 100644
--- a/site2/website/versioned_docs/version-2.5.0/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.5.0/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.5.1/administration-geo.md
b/site2/website/versioned_docs/version-2.5.1/administration-geo.md
index 0d904d9..0368c19 100644
--- a/site2/website/versioned_docs/version-2.5.1/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.5.1/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.5.2/administration-geo.md
b/site2/website/versioned_docs/version-2.5.2/administration-geo.md
index 2282699..6d8985c 100644
--- a/site2/website/versioned_docs/version-2.5.2/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.5.2/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.6.0/administration-geo.md
b/site2/website/versioned_docs/version-2.6.0/administration-geo.md
index f13e8c7..88130e7 100644
--- a/site2/website/versioned_docs/version-2.6.0/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.6.0/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.6.1/administration-geo.md
b/site2/website/versioned_docs/version-2.6.1/administration-geo.md
index b42ae4d..f67d545 100644
--- a/site2/website/versioned_docs/version-2.6.1/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.6.1/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.6.2/administration-geo.md
b/site2/website/versioned_docs/version-2.6.2/administration-geo.md
index 0a7c7db..90257b1 100644
--- a/site2/website/versioned_docs/version-2.6.2/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.6.2/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.6.3/administration-geo.md
b/site2/website/versioned_docs/version-2.6.3/administration-geo.md
index a945b4f..7fb54be 100644
--- a/site2/website/versioned_docs/version-2.6.3/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.6.3/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.6.4/administration-geo.md
b/site2/website/versioned_docs/version-2.6.4/administration-geo.md
index a44759b..4f4e161 100644
--- a/site2/website/versioned_docs/version-2.6.4/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.6.4/administration-geo.md
@@ -154,4 +154,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.7.0/administration-geo.md
b/site2/website/versioned_docs/version-2.7.0/administration-geo.md
index 8e1d95b..a51ec16 100644
--- a/site2/website/versioned_docs/version-2.7.0/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.7.0/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.7.1/administration-geo.md
b/site2/website/versioned_docs/version-2.7.1/administration-geo.md
index 58cba4c..79b25bd 100644
--- a/site2/website/versioned_docs/version-2.7.1/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.7.1/administration-geo.md
@@ -192,4 +192,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.7.2/administration-geo.md
b/site2/website/versioned_docs/version-2.7.2/administration-geo.md
index a8f3758..10e2d77 100644
--- a/site2/website/versioned_docs/version-2.7.2/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.7.2/administration-geo.md
@@ -193,4 +193,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.7.3/administration-geo.md
b/site2/website/versioned_docs/version-2.7.3/administration-geo.md
index 8af2b7a..1969014 100644
--- a/site2/website/versioned_docs/version-2.7.3/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.7.3/administration-geo.md
@@ -193,4 +193,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.8.0/administration-geo.md
b/site2/website/versioned_docs/version-2.8.0/administration-geo.md
index 97ddaee..190d9cd 100644
--- a/site2/website/versioned_docs/version-2.8.0/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.8.0/administration-geo.md
@@ -193,4 +193,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
\ No newline at end of file
diff --git a/site2/website/versioned_docs/version-2.8.1/administration-geo.md
b/site2/website/versioned_docs/version-2.8.1/administration-geo.md
index 4b34007..b0a5b41 100644
--- a/site2/website/versioned_docs/version-2.8.1/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.8.1/administration-geo.md
@@ -193,4 +193,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
diff --git a/site2/website/versioned_docs/version-2.8.2/administration-geo.md
b/site2/website/versioned_docs/version-2.8.2/administration-geo.md
index e1855db..1eaec28 100644
--- a/site2/website/versioned_docs/version-2.8.2/administration-geo.md
+++ b/site2/website/versioned_docs/version-2.8.2/administration-geo.md
@@ -193,4 +193,5 @@ Consumer<String> consumer =
client.newConsumer(Schema.STRING)
### Limitations
-When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent
distributed snapshot to establish an association between message ids from
different clusters. The snapshots are taken periodically. The default value is
`1 second`. It means that a consumer failing over to a different cluster can
potentially receive 1 second of duplicates. You can also configure the
frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position is synced in replicated subscriptions
while the individual acknowledgments are not synced. This means the messages
acknowledged out-of-order could end up getting delivered again, in the case of
a cluster failover.
