IMPORT INTO 和 TiDB Lightning 与日志备份和 TiCDC 的兼容性
本文档介绍 TiDB Lightning 和 IMPORT INTO 与日志备份、TiCDC 的兼容性，以及某些特殊的使用场景。
IMPORT INTO 和 TiDB Lightning 对比
IMPORT INTO 目前已经集成了 TiDB Lightning 的物理导入模式，但二者还存在一些差异。详情请参见 IMPORT INTO 和 TiDB Lightning 对比。
与日志备份和 TiCDC 的兼容性
TiDB Lightning 的逻辑导入模式与日志备份以及 TiCDC 兼容。
TiDB Lightning 的物理导入模式与日志备份以及 TiCDC 均不兼容。原因是 TiDB Lightning 物理导入模式是将源数据编码后的 KV Pairs 直接 Ingest 到 TiKV，该过程 TiKV 不会产生相应的 Change log，由于没有这部分的 Change log，相关数据无法通过日志备份的方式备份，也无法被 TiCDC 复制。
如果你需要在同一个集群上同时使用 TiDB Lightning 和 TiCDC，请参考 TiCDC 与 TiDB Lightning 的兼容性。
IMPORT INTO与日志备份以及 TiCDC 均不兼容。原因是IMPORT INTO的导入过程也是将源数据编码后的 KV Pairs 直接 Ingest 到 TiKV。
TiDB Lightning 逻辑导入模式的使用场景
如果 TiDB Lightning 逻辑导入的性能可以满足业务的性能要求，且业务要求 TiDB Lightning 导入的表进行数据备份，或者使用 TiCDC 同步到下游，建议使用 TiDB Lightning 逻辑导入模式。
TiDB Lightning 物理导入模式的使用场景
本节介绍 TiDB Lightning 物理导入模式与日志备份和 TiCDC 同时使用时的操作方法。
如果 TiDB Lightning 逻辑导入的性能无法满足业务的性能要求，且只能使用 TiDB Lightning 物理导入模式的场景，同时这些表还需要备份或者使用 TiCDC 同步到下游，则建议使用以下方案进行处理。
和日志备份同时使用
可根据如下不同的场景进行操作：
场景 1：物理导入模式的表不需要备份
该场景下，如果开启了 PITR，启动 TiDB Lightning 后兼容性检查会报错。如果你确定这些表不需要备份或者日志备份，你可以把 TiDB Lightning 配置文件中的
Lightning.check-requirements参数改成false，然后重新启动导入任务即可。场景 2：物理导入模式导入完成后，该表不会有新的 DML 操作
该场景由于不涉及增量数据写入，因此在 TiDB Lightning 物理导入模式完成数据导入后，对该表执行一次表级别快照备份即可，操作步骤请参考备份单张表的数据。
在数据恢复时，对该表的快照数据进行恢复，操作步骤请参考恢复单张表格。
场景 3：物理导入模式导入完成后，该表会执行新的 DML 操作（不支持）
该场景下，对该表的备份操作，只能在执行全量快照备份和日志备份之间二选一，无法备份并恢复该表的全量快照数据+日志备份数据。
和 TiCDC 同时使用
该场景短期内无法兼容，因为 TiCDC 很难追上 TiDB Lightning 物理导入的写入速度，可能造成集群同步延迟不断增加。
可根据如下不同的场景进行操作：
场景 1：该表不需要被 TiCDC 同步到下游。
在该场景下，如果开启了 TiCDC 同步任务，启动 TiDB Lightning 后兼容性检查会报错。如果你确定这些表不需要被 TiCDC 同步，你可以把 TiDB Lightning 配置文件中的
Lightning.check-requirements参数改成false，然后重新启动导入任务即可。场景 2：该表需要被 TiCDC 同步到下游。
在该场景下，由于上游 TiDB 集群开启了 TiCDC 同步任务，因此启动 TiDB Lightning 后兼容性检查会报错。你需要在上游 TiDB 集群把 TiDB Lightning 配置文件中的
Lightning.check-requirements参数改成false，然后重新启动导入任务即可。上游 TiDB 集群的导入任务完成后，再使用 TiDB Lightning 在下游 TiDB 集群也导入一份同样的数据。如果下游是 Redshift、Snowflake 等数据库，可直接让这些数据库从 Cloud Storage 读取 CSV、SQL、Parquet 等格式的文件并写入到数据库。
IMPORT INTO 的使用场景
本节介绍 IMPORT INTO 与日志备份和 TiCDC 同时使用时的操作方法。
和日志备份同时使用
可根据如下不同的场景进行操作：
场景 1：导入的表不需要备份
该场景下，如果开启了 PITR，提交
IMPORT INTOSQL 语句后兼容性检查会报错。如果你确定这些表不需要备份或者日志备份，你可以在该 SQL 的WithOptions里带上参数DISABLE_PRECHECK（从 v8.0.0 版本引入）重新提交即可，这样数据导入任务会忽略该兼容性检查，直接导入数据。场景 2：导入完成后，该表不会有新的 DML 操作
该场景由于不涉及增量数据写入，因此在完成数据导入后，对该表执行一次表级别快照备份即可，操作步骤请参考备份单张表的数据。
在数据恢复时，对该表的快照数据进行恢复，操作步骤请参考恢复单张表格。
场景 3：导入完成后，该表会执行新的 DML 操作（不支持）
该场景下，对该表的备份操作，只能在执行全量快照备份和日志备份之间二选一，无法备份并恢复该表的全量快照数据+日志备份数据。
和 TiCDC 同时使用
可根据如下不同的场景进行操作：
场景 1：该表不需要被 TiCDC 同步到下游。
在该场景下，如果开启了 TiCDC Changefeed，提交
IMPORT INTOSQL 语句后兼容性检查会报错。如果你确定这些表不需要被 TiCDC 同步，你可以在该 SQL 的WithOptions里带上参数DISABLE_PRECHECK（从 v8.0.0 版本引入）重新提交即可，这样数据导入任务会忽略该兼容性检查，直接导入数据。场景 2：该表需要被 TiCDC 同步到下游。
在该场景下，如果上游 TiDB 集群开启了 TiCDC 同步任务，提交
IMPORT INTOSQL 语句后兼容性检查会报错。你需要在该 SQL 的WithOptions里带上参数DISABLE_PRECHECK（从 v8.0.0 版本引入）重新提交即可。上游 TiDB 集群的导入任务完成后，再使用
IMPORT INTO在下游 TiDB 集群也导入一份同样的数据。如果下游是 Redshift、Snowflake 等数据库，可直接让这些数据库从 Cloud Storage 读取 CSV、SQL、Parquet 等格式的文件并写入到数据库。