导入集群数据

TiDB Lightning 包含两个组件：tidb-lightning 和 tikv-importer。在 Kubernetes 上，tikv-importer 位于单独的 Helm chart 内，被部署为一个副本数为 1 () 的 StatefulSet；tidb-lightning 位于单独的 Helm chart 内，被部署为一个 Job。

目前，TiDB Lightning 支持三种后端：Importer-backend、Local-backend 、TiDB-backend。关于这三种后端的区别和选择，请参阅 TiDB Lightning 文档。

对于 Importer-backend 后端，需要分别部署 tikv-importer 与 tidb-lightning。

注意

Importer-backend 后端在 TiDB 5.3 及之后的版本被废弃。如果必须使用 Importer-backend 后端，请参考 v1.2 及以前的部署 tikv-importer。
对于 Local-backend 后端，只需要部署 tidb-lightning。
对于 TiDB-backend 后盾，只需要部署 tidb-lightning。推荐使用基于 TiDB Operator 新版（v1.1 及以上）的 CustomResourceDefinition (CRD) 实现。具体信息可参考使用 TiDB Lightning 恢复 GCS 上的备份数据或。

使用如下命令将 TiDB Lightning 的默认配置保存到 tidb-lightning-values.yaml 文件：

根据 TiDB Lightning 所使用的后端类型，将配置文件中的 backend 字段设置为 local、tidb 中的一个。

# The delivery backend used to import data (valid options include `local` and `tidb`).
# If set to `local`, then the following `sortedKV` should be set.
backend: local

如果使用 local 后端，则还需要在配置文件中设置 sortedKV 字段来创建相应的 PVC 以用于本地 KV 排序。

# For `local` backend, an extra PV is needed for local KV sorting.
sortedKV:
  storageClassName: local-storage
  storage: 100Gi

断点续传配置

自 v1.1.10 版本起，tidb-lightning Helm chart 默认会将 TiDB Lightning 的 checkpoint 信息存储在源数据所在目录内。这样在运行新的 lightning job 时，可以根据 checkpoint 信息进行断点续传。

对于 v1.1.10 之前的版本，可参考，在 values.yaml 中的 config 配置下，设置将 checkpoint 信息保存到目标 TiDB 集群、其他 MySQL 协议兼容的数据库或共享存储目录中。

TLS 配置

如果目标 TiDB 集群组件间开启了 TLS (spec.tlsCluster.enabled: true)，则可以参考为 TiDB Lightning 组件生成 Server 端证书，并在 values.yaml 中通过配置 tlsCluster.enabled: true 开启集群内部的 TLS 支持。

如果目标 TiDB 集群为 MySQL 客户端开启了 TLS (spec.tidb.tlsClient.enabled: true) 并配置了相应的 Client 端证书（对应的 Kubernetes Secret 对象为 ${cluster_name}-tidb-client-secret），则可以通过在 values.yaml 中配置 tlsClient.enabled: true 以使 TiDB Lightning 通过 TLS 方式连接 TiDB Server。

如果需要 TiDB Lightning 使用不同的 Client 证书来连接 TiDB Server，则可以参考为 TiDB 集群颁发两套证书为 TiDB Lightning 组件生成 Client 端证书，并在 values.yaml 中通过 tlsCluster.tlsClientSecretName 指定对应的 Kubernetes Sceret 对象。

注意

如果通过 tlsCluster.enabled: true 开启了集群内部的 TLS 支持，但未通过 tlsClient.enabled: true 开启 TiDB Lightning 到 TiDB Server 的 TLS 支持，则需要在 values.yaml 中的 config 内通过如下配置显式地禁用 TiDB Lightning 到 TiDB Server 的 TLS 连接支持。

[tidb]
tls="false"

tidb-lightning Helm chart 支持从本地或远程获取备份数据。对应三种模式：本地模式、远程模式和 Ad hoc 模式。三种模式不能混用，只允许配置其中一种模式。

本地模式

本地模式从某个 Kubernetes 节点的目录读取备份数据。示例如下：

dataSource:
  local:
    nodeName: kind-worker3
    hostPath: /data/export-20190820

远程模式

与本地模式不同，远程模式使用工具，将包含备份数据的 tarball 文件或目录从网络存储中下载到 PV 中。远程模式能在 rclone 支持的任何云存储下工作，目前已经有以下存储进行了相关测试：Google Cloud Storage (GCS)、和 Ceph Object Storage。

使用远程模式恢复备份数据的步骤如下：

存储访问授权

使用 Amazon S3 作为后端存储时，参考。在使用不同的权限授予方式时，需要使用不用的配置。

使用 Ceph 作为存储后端时，参考通过 AccessKey 和 SecretKey 授权。

使用 GCS 作为存储后端时，参考。
- 通过 AccessKey 和 SecretKey 授权
  1. 新建一个包含 rclone 配置的 Secret 配置文件 secret.yaml。rclone 配置示例如下。一般只需要配置一种云存储。
  2. ```
  kubectl apply -f secret.yaml -n ${namespace}
```
配置 dataSource 字段。示例如下：
```
dataSource:
  remote:
    rcloneImage: rclone/rclone:1.55.1
    storageClassName: local-storage
    storage: 100Gi
    secretName: cloud-storage-secret
    path: s3:bench-data-us/sysbench/sbtest_16_1e7.tar.gz
    # directory: s3:bench-data-us
```
相关字段含义如下：
- dataSource.remote.storageClassName：创建 PV 使用的 StorageClass 名称。
- dataSource.remote.secretName：上一步所创建的 Secret 的名称。
- dataSource.remote.path：如果备份数据打包为 tarball 文件，使用该字段表明 tarball 文件的路径。
- dataSource.remote.directory：如果备份数据包含在目录下，使用该字段表明目录的路径。

Ad hoc 模式

当使用远程模式进行恢复时，如果在恢复过程中由于异常而造成中断、但又不希望重复从网络存储中下载备份数据，则可以使用 Ad hoc 模式直接恢复已通过远程模式下载并解压到 PV 中的数据。

示例如下：