mydumper:24017

[simpson9527]

** (mydumper:24017): CRITICAL **: 14:35:54.810: Couldn't acquire global lock, snapshots will not be consistent: FLUSH TABLES WITH READ LOCK is not supported. Please use @@tidb_snapshot

mydumper cmd is：mydumper -h 127.0.0.1 -P 4000 -u root -t 8 -F 64 -B database -c -o /data

[morgo]

This error message is generated because mydumper attempted to execute FLUSH TABLES WITH READ LOCK on a TiDB server (the command is not supported).

Please use the mydumper bundled with TiDB tools. Support for TiDB has merged into upstream mydumper, and will be available starting with the next release.

[simpson9527]

ok,i will try again

[morgo]

@simpson9527 Just checking in. How did it go? :-)

[simpson9527]

i had some problems when i use mydumper backup mysql data,shall we make some changes for mydumper.
here is the situation: when i dump a table,the column default value is illegality,for example,the datatype date's default value is '1970-00:00 00:00:00' in mysql，but which is illegality in tidb.shall we automatic transfer the default value from mysql to tidb when dump tables.

[morgo]

i had some problems when i use mydumper backup mysql data,shall we make some changes for mydumper.
here is the situation: when i dump a table,the column default value is illegality,for example,the datatype date's default value is '1970-00:00 00:00:00' in mysql，but which is illegality in tidb.shall we automatic transfer the default value from mysql to tidb when dump tables.

It is now illegal by default in MySQL as well. TiDB actually behaves the same - you can remove the sql_modes NO_ZERO_IN_DATE (and probably NO_ZERO_DATE) from TiDB's configuration to make it behave the old way:

SET GLOBAL sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

[ghost]

I am going to close this issue as stale. Please feel free to re-open if you have additional questions. Thanks!