title | summary | category |
---|---|---|
TiDB-Lightning FAQ |
Learn about the frequently asked questions (FAQs) and answers about TiDB-Lightning. |
tools |
The minimum version is 2.0.9.
Yes.
Lightning requires the following privileges:
- SELECT
- UPDATE
- ALTER
- CREATE
- DROP
If the target database is used to store checkpoints, it additionally requires these privileges:
- INSERT
- DELETE
Lightning encountered an error when importing one table. Will it affect other tables? Will the process be terminated?
If only one table has an error encountered, the rest will still be processed normally.
Lightning by default performs checksum on the local data source and the imported tables. If there is checksum mismatch, the process would be aborted. These checksum information can be read from the log.
You could also execute the ADMIN CHECKSUM TABLE
SQL command on the target table to recompute the checksum of the imported data.
mysql> ADMIN CHECKSUM TABLE `schema`.`table`;
+---------+------------+---------------------+-----------+-------------+
| Db_name | Table_name | Checksum_crc64_xor | Total_kvs | Total_bytes |
+---------+------------+---------------------+-----------+-------------+
| schema | table | 5505282386844578743 | 3 | 96 |
+---------+------------+---------------------+-----------+-------------+
1 row in set (0.01 sec)
In version 2.1.0, TiDB-Lightning only supports the SQL dump generated by mydumper stored in the local filesystem.
Yes. If you have already created the tables in the target database, you could set no-schema = true
in the [data-source]
section in tidb-lightning.toml
. This makes Lightning skip the
CREATE TABLE
invocations and fetch the metadata directly from the target database. Lightning will exit with error if a table is actually missing.
Yes. By default, the sql_mode
used by Lightning is "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
, which disallows invalid data such as the date 1970-00-00
. The mode can be changed by modifying the sql-mode
setting in the [tidb]
section in tidb-lightning.toml
.
...
[tidb]
sql-mode = ""
...
Yes, as long as every tidb-lightning
instance operates on different tables.
If it is deployed using TiDB-Ansible, run scripts/stop_importer.sh
under the deployed folder.
Otherwise, obtain the process ID with ps aux | grep tikv-importer
, and then run kill «pid»
.
If it is deployed using TiDB-Ansible, run scripts/stop_lightning.sh
under the deployed folder.
If tidb-lightning
is running in foreground, simply press Ctrl+C to stop it.
Otherwise, obtain the process ID with ps aux | grep tidb-importer
, then run kill -2 «pid»
.
It is potentially caused by starting tidb-lightning
incorrectly, which causes the system to send a SIGHUP signal to stop it. If this is the case, there should be a log entry like:
2018/08/10 07:29:08.310 main.go:47: [info] Got signal hangup to exit.
We do not recommend using nohup
directly in the command line. Rather, put the nohup
inside a script file and execute the script.
If tidb-lightning
abnormally exited, the cluster might be stuck in the "import mode", which is not suitable for production. You can force the cluster back to "normal mode" using the following command:
tidb-lightning-ctl --switch-mode=normal
The TiDB-Lightning toolset requires a 10-Gigabit network card. The 1-Gigabit network card is not acceptable, especially for tikv-importer
.
A 1-Gigabit network card can only provide a total bandwidth of 120 MB/s, which has to be shared among all target TiKV stores.
TiDB-Lightning can easily saturate all bandwidth of the 1-Gigabit network, and brings down the cluster because PD is unable to contact it anymore.
With the default settings of 3 replicas, the space requirement of the target TiKV cluster is 6 times the size of SQL dump. The extra multiple of “2” is a conservative estimation because the following factors are not reflected in the SQL dump:
- The space occupied by indices
- Space amplification in RocksDB