log_diag_50: If multiple transactions modify the same key, only one transaction succeed and other transactions automatically obtain the timestamp again and retry the operation, with no impact on the business.If the conflict is severe, it might cause transaction failure after multiple retries. In this case, it is recommended to use the pessimistic lock.
log_diag_111: The transaction duration exceeds the GC lifetime (10 minutes by default).You can increase the GC lifetime by modifying the tidb_gc_life_time system variable. Generally, it is not recommended to modify this parameter, because changing it might cause many old versions to pile up if this transaction has a large number of UPDATE and DELETE statements.
log_diag_112: This error is returned when you commit a transaction that has not been committed for a long time (over 590 seconds).If your application needs to execute a transaction of such a long time, you can increase the [tikv-client] max-txn-time-use = 590 parameter and the GC lifetime to avoid this issue. It is recommended to check whether your application needs such a long transaction time.
log_diag_113: 'The data index seems to be inconsistent. Run the admin check table <TableName> command on the table where the reported index is. If the check fails, disable garbage collection by running "SET GLOBAL tidb_gc_enable = 0;", and report a bug.'
log_diag_114: If the conflict is severe, it might cause transaction failure after multiple retries. In this case, it is recommended to use the pessimistic lock.
log_diag_115: Add TiKV configuration max-sub-compactions = 2 (or 3) to speed up level0 sst down compaction.
log_diag_116: You can restore the Region using tikv-ctl.
log_diag_118: When the write tasks pile up in the scheduler, the pending write tasks exceed the threshold set in [storage] scheduler-pending-write-threshold (100MB). You can verify the cause by viewing the metric corresponding to MVCC_CONFLICT_COUNTER. You can increase scheduler-pending-write-threshold.
log_diag_119: You need to clean up the disk space and then restart Pump.
log_diag_120: Use the binlogctl tool to check whether each Drainer node is normal or not. This is to ensure that all Drainer nodes in the online state are working normally. If the state of a Drainer node is not consistent with its actual working status, use the binlogctl tool to change its state and then restart Pump. 
log_diag_121: This value cannot be successfully written into MySQL 8.0 or TiDB, but can be written into MySQL 5.7. You can skip the data format check by enabling the tidb_skip_utf8_check parameter.
log_diag_122: Check whether the table where the error is reported already has data, and if so, it needs to be cleaned up first. Check if the checksum of the target database is all 0, if yes means no import has occurred. Check if the cluster is too busy to receive any data.
log_diag_123: Increase the value of max-open-engines setting in tikv-importer.toml. Decrease the value of table-concurrency + index-concurrency so it is less than max-open-engines.
log_diag_124: '"Option1: Fix the schema so that the file is entirely in either UTF-8 or GB-18030. Option2: Manually CREATE the affected tables in the target database. Option3: Set [mydumper] character-set = "binary" to skip the check. Note that this might introduce mojibake into the target database."'
log_diag_125: Ensure TiDB Lightning and the source database are using the same time zone. When exporting data using Mydumper, make sure to include the --skip-tz-utc flag. Ensure the entire cluster is using the same and latest version of tzdata.
log_diag_126: You need to clean up the etcd storage after getting this error. 
log_diag_127: Try to enable the unified sorter feature in your replication task, or use the BR tool for an incremental backup and restore, and then start the TiCDC replication task from a new time.
log_diag_128: 1. Set the value of enable-old-value in the changefeed configuration file to true. 2. Execute cdc cli changefeed pause to pause the replication task. 3. Execute cdc cli changefeed update to update the original changefeed configuration. 4. Execute cdc cli changfeed resume to resume the replication task.
log_diag_129: You need to execute the pd-ctl service-gc-safepoint --pd <pd-addrs> command to query the current GC safepoint and service GC safepoint. If the GC safepoint is smaller than the start-ts of the TiCDC replication task (changefeed), you can directly add the --disable-gc-check option to the cdc cli create changefeed command to create a changefeed.
log_diag_130: Troubleshoot the cause of TiKV Coprocessor task queue queuing.
log_diag_131: You can investigate the monitoring Grafana -> TiDB -> Batch Client/Pending Request Count by TiKV and see whether the Pending Request Count is greater than 128. If the value is greater than 128, the sending goes beyond the processing capacity of KV, so the sending piles up.
log_diag_132: The request timed out after it is sent to TiKV. You need to check the response time of the corresponding TiKV address and the Region logs in PD and KV at that time.
log_diag_133: You can check the switch region peer to next due to send request fail log of the corresponding Region in TiDB to determine the root cause of the sending failure. Or according to https://docs.pingcap.com/en/tidb/stable/tidb-troubleshooting-map#44-%E6%9F%90%E4%BA%9B-tikv-%E5%A4%A7%E9% 87%8F%E6%8E%89-leader Check whether TiKV loses the leader.
log_diag_134: Check whether the database connection from DM to downstream TiDB is abnormal. If only the invalid connection error occurs during the incremental replication process, DM retries the task automatically. If DM does not retry or fails to retry automatically because of version problems (automatic retry is introduced in v1.0.0-rc.1), use stop-task to stop the task and then use start-task to restart the task.
log_diag_135: Check whether the master binlog is purged. Check the position information recorded in relay.meta.