ticdc: add explicit_defaults_for_timestamp compatibility troubleshoot (#6115)

ticdc/manage-ticdc.md

@@ -872,6 +872,6 @@ In the output of the above command, if the value of `sort-engine` is "unified",
 > **Note:**
 >
 > + If your servers use mechanical hard drives or other storage devices that have high latency or limited bandwidth, use the unified sorter with caution.
-> + The total free capacity of hard drives must be greater than or equal to 128G. If you need to replicate a large amount of historical data, make sure that the free capacity on each node is greater than or equal to the size of the incremental data that needs to be replicated.
+> + The total free capacity of hard drives must be greater than or equal to 500G. If you need to replicate a large amount of historical data, make sure that the free capacity on each node is greater than or equal to the size of the incremental data that needs to be replicated.
 > + Unified sorter is enabled by default. If your servers do not match the above requirements and you want to disable the unified sorter, you need to manually set `sort-engine` to `memory` for the changefeed.
 > + To enable Unified Sorter on an existing changefeed, see the methods provided in [How do I handle the OOM that occurs after TiCDC is restarted after a task interruption?](/ticdc/troubleshoot-ticdc.md#how-do-i-handle-the-oom-that-occurs-after-ticdc-is-restarted-after-a-task-interruption).

ticdc/troubleshoot-ticdc.md

@@ -397,3 +397,27 @@ If you want to skip this DDL statement that goes wrong, set the start-ts of the
 cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --start-ts 415241823337054210
 cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379
 ```
+
+## The default value of the time type field is inconsistent when replicating a DDL statement to the downstream MySQL 5.7. What can I do?
+
+Suppose that the `create table test (id int primary key, ts timestamp)` statement is executed in the upstream TiDB. When TiCDC replicates this statement to the downstream MySQL 5.7, MySQL uses the default configuration. The table schema after the replication is as follows. The default value of the `timestamp` field becomes `CURRENT_TIMESTAMP`:
+
+{{< copyable "sql" >}}
+
+```sql
+mysql root@127.0.0.1:test> show create table test;
++-------+----------------------------------------------------------------------------------+
+| Table | Create Table                                                                     |
++-------+----------------------------------------------------------------------------------+
+| test  | CREATE TABLE `test` (                                                            |
+|       |   `id` int(11) NOT NULL,                                                         |
+|       |   `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, |
+|       |   PRIMARY KEY (`id`)                                                             |
+|       | ) ENGINE=InnoDB DEFAULT CHARSET=latin1                                           |
++-------+----------------------------------------------------------------------------------+
+1 row in set
+```
+
+From the result, you can see that the table schema before and after the replication is inconsistent. This is because the default value of `explicit_defaults_for_timestamp` in TiDB is different from that in MySQL. See [MySQL Compatibility](/mysql-compatibility.md#default-differences) for details.
+
+Since v5.0.1 or v4.0.13, for each replication to MySQL, TiCDC automatically sets `explicit_defaults_for_timestamp = ON` to ensure that the time type is consistent between the upstream and downstream. For versions earlier than v5.0.1 or v4.0.13, pay attention to the compatibility issue caused by the inconsistent `explicit_defaults_for_timestamp` value when using TiCDC to replicate the time type data.