From b379266335973344bf3e026f9ea3b19580c70152 Mon Sep 17 00:00:00 2001 From: shichun-0415 Date: Fri, 2 Sep 2022 12:00:08 +0800 Subject: [PATCH 1/4] ticdc: update the warning for using redo log --- ticdc/manage-ticdc.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 5a3981f82d1b0..7a4a75519f35b 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -662,6 +662,10 @@ In the output of the above command, if the value of `sort-engine` is "unified", ## Eventually consistent replication in disaster scenarios +> **Warning:** +> +> In v5.3.0 and v5.4.0, due to [critical bug #6189](https://github.com/pingcap/tiflow/issues/6189), it is not recommended that you use eventually consistent replication in disaster scenarios. This bug has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. + Starting from v5.3.0, TiCDC supports backing up incremental data from an upstream TiDB cluster to S3 storage or an NFS file system of a downstream cluster. When the upstream cluster encounters a disaster and becomes unavailable, TiCDC can restore the downstream data to the recent eventually consistent state. This is the eventually consistent replication capability provided by TiCDC. With this capability, you can switch applications to the downstream cluster quickly, avoiding long-time downtime and improving service continuity. Currently, TiCDC can replicate incremental data from a TiDB cluster to another TiDB cluster or a MySQL-compatible database system (including Aurora, MySQL, and MariaDB). In case the upstream cluster crashes, TiCDC can restore data in the downstream cluster within 5 minutes, given the conditions that before the disaster the replication status of TiCDC is normal and the replication lag is small. It allows data loss of 10s at most, that is, RTO <= 5 min, and P95 RPO <= 10s. From 48e37dad171c2d1c436a41e61b21c754806a5baa Mon Sep 17 00:00:00 2001 From: shichun-0415 Date: Fri, 2 Sep 2022 19:33:51 +0800 Subject: [PATCH 2/4] Update manage-ticdc.md --- ticdc/manage-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 7a4a75519f35b..6d1c720a6447b 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -664,7 +664,7 @@ In the output of the above command, if the value of `sort-engine` is "unified", > **Warning:** > -> In v5.3.0 and v5.4.0, due to [critical bug #6189](https://github.com/pingcap/tiflow/issues/6189), it is not recommended that you use eventually consistent replication in disaster scenarios. This bug has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. +> In v5.3.0 and v5.4.0, it is not recommended that you use eventually consistent replication in disaster scenarios. For details, see [#6189](https://github.com/pingcap/tiflow/issues/6189), This issue has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. Starting from v5.3.0, TiCDC supports backing up incremental data from an upstream TiDB cluster to S3 storage or an NFS file system of a downstream cluster. When the upstream cluster encounters a disaster and becomes unavailable, TiCDC can restore the downstream data to the recent eventually consistent state. This is the eventually consistent replication capability provided by TiCDC. With this capability, you can switch applications to the downstream cluster quickly, avoiding long-time downtime and improving service continuity. From 4427fcf3e7e03138dc59451b6e40ab5d2e1f7e3f Mon Sep 17 00:00:00 2001 From: shichun-0415 Date: Mon, 5 Sep 2022 08:29:54 +0800 Subject: [PATCH 3/4] fix comma --- ticdc/manage-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 6d1c720a6447b..41fcbaf876dfe 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -664,7 +664,7 @@ In the output of the above command, if the value of `sort-engine` is "unified", > **Warning:** > -> In v5.3.0 and v5.4.0, it is not recommended that you use eventually consistent replication in disaster scenarios. For details, see [#6189](https://github.com/pingcap/tiflow/issues/6189), This issue has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. +> In v5.3.0 and v5.4.0, it is not recommended that you use eventually consistent replication in disaster scenarios. For details, see [#6189](https://github.com/pingcap/tiflow/issues/6189). This issue has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. Starting from v5.3.0, TiCDC supports backing up incremental data from an upstream TiDB cluster to S3 storage or an NFS file system of a downstream cluster. When the upstream cluster encounters a disaster and becomes unavailable, TiCDC can restore the downstream data to the recent eventually consistent state. This is the eventually consistent replication capability provided by TiCDC. With this capability, you can switch applications to the downstream cluster quickly, avoiding long-time downtime and improving service continuity. From 8a108f82abf722165d5d7d5c57987967bed8fca0 Mon Sep 17 00:00:00 2001 From: shichun-0415 <89768198+shichun-0415@users.noreply.github.com> Date: Mon, 5 Sep 2022 10:05:52 +0800 Subject: [PATCH 4/4] Update ticdc/manage-ticdc.md Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> --- ticdc/manage-ticdc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ticdc/manage-ticdc.md b/ticdc/manage-ticdc.md index 41fcbaf876dfe..a847b2617467e 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -664,7 +664,7 @@ In the output of the above command, if the value of `sort-engine` is "unified", > **Warning:** > -> In v5.3.0 and v5.4.0, it is not recommended that you use eventually consistent replication in disaster scenarios. For details, see [#6189](https://github.com/pingcap/tiflow/issues/6189). This issue has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or later versions. +> In v5.3.0 and v5.4.0, it is not recommended that you use eventually consistent replication in disaster scenarios. For details, see [#6189](https://github.com/pingcap/tiflow/issues/6189). This issue has been fixed in v6.1.1 and later. Therefore, it is recommended that you use v6.1.1 or a later version. Starting from v5.3.0, TiCDC supports backing up incremental data from an upstream TiDB cluster to S3 storage or an NFS file system of a downstream cluster. When the upstream cluster encounters a disaster and becomes unavailable, TiCDC can restore the downstream data to the recent eventually consistent state. This is the eventually consistent replication capability provided by TiCDC. With this capability, you can switch applications to the downstream cluster quickly, avoiding long-time downtime and improving service continuity.