From 624c8e46d24710a238833da7911bed616cad93d8 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 7523e715f383e..bcf6d4eb0a9ab 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -651,6 +651,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 f0c173661fc7ab559ed6665dcd43c87fc330366e 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 bcf6d4eb0a9ab..1b225bfe887e7 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -653,7 +653,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 1298d7c9c021983ddc4cb35271a104d01bade6c0 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 1b225bfe887e7..b09098072e279 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -653,7 +653,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 81a8d1bf6b474f63d7a599dfc6c211ae372401ff 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 b09098072e279..fe61d943e0fd6 100644 --- a/ticdc/manage-ticdc.md +++ b/ticdc/manage-ticdc.md @@ -653,7 +653,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.