log_diag_50: 乐观事务中的写写冲突，同时多个事务对相同的 key 进行修改，只有一个事务会成功，其他事务会自动重取 timestamp 然后进行重试，不影响业务。如果业务冲突很严重可能会导致重试多次之后事务失败，这种情况下建议使用悲观锁。
log_diag_111: '事务执行时间太长，超过了 GC lifetime（默认为 10 分钟. 用户侧排查相关 SQL 是否需要优化，或者通过修改系统变量 tidb_gc_life_time 来延长 life time，通常情况下不建议修改，因为延长时限可能导致大量老版本数据的堆积（如果有大量 UPDATE 和 DELETE 语句）。'
log_diag_112: 可以通过调大 [tikv-client] max-txn-time-use = 590 参数，以及调大 GC life time 来绕过该问题（如果确实有这个需求）。通常情况下，建议看看业务是否真的需要执行这么长时间的事务。
log_diag_113: '执行 admin check table <TableName> 命令，如果失败，则执行 "SET GLOBAL tidb_gc_enable = 0;" 禁用 GC绕过问题，并报 bug。'
log_diag_114: 考虑改用悲观锁。
log_diag_115: 添加参数 [rocksdb] max-sub-compactions = 2（或者 3）加快 level0 sst 往下 compact 的速度。
log_diag_116: 通过 tikv-ctl 工具恢复 Region。
log_diag_118: 可通过查看 MVCC_CONFLICT_COUNTER 对应的 metric 来确认是否属于该情况。可以调高 scheduler-pending-write-threshold。
log_diag_119: 清理磁盘空间，然后重启 Pump。
log_diag_120: 使用 binlogctl 工具查看所有 Drainer 的状态是否有异常，保证 Online 状态的 Drainer 都在正常工作。如果某个 Drainer 的状态和实际运行情况不一致，则使用 binlogctl 修改状态，然后再重启 Pump。
log_diag_121: 该值 MySQL 8.0 和 TiDB 都不能写入成功，但是 MySQL 5.7 可以写入成功。可以开启 TiDB 动态参数 tidb_skip_utf8_check 参数，跳过数据格式检查。开启 TiDB 动态参数 tidb_skip_utf8_check 参数，跳过数据格式检查。
log_diag_122: 检查报错的表本身是否已有数据，如有则需要先清理。检查目标数据库的校验和是否全是 0，是则表示没有发生任何导入。检查是否集群太忙无法接收任何数据。
log_diag_123: 提高 tikv-importer.toml 内 max-open-engines 的值。降低 table-concurrency + index-concurrency，使之低于 max-open-engines。
log_diag_124: 方案一：编辑数据源，保存为纯 UTF-8 或 GB-18030 的文件。方案二：手动在目标数量库创建所有的表，然后设置 [mydumper] no-schema = true 跳过创建表的步骤。方案三：设置 [mydumper] character-set = "binary" 跳过这个检查。但是这样可能使数据库出现乱码。
log_diag_125: 确保 TiDB Lightning 与数据源时区一致。导出数据时，加 --skip-tz-utc 选项。确保整个集群使用的是同一最新版本的 tzdata。
log_diag_126: 清理 etcd 存储空间
log_diag_127: 尝试开启 unified sorter 特性进行同步，或者使用 BR 工具进行一次增量备份和恢复，然后从新的时间点开启 TiCDC 同步任务。
log_diag_128: 1. 将 changefeed 配置文件中 enable-old-value 的值设为 true。2. 使用 cdc cli changefeed pause 暂停同步任务。3. 使用 cdc cli changefeed update 更新原有 changefeed 的配置。4. 使用 cdc cli changefeed resume 恢复同步任务。
log_diag_129: 执行 pd-ctl service-gc-safepoint --pd <pd-addrs> 命令查询当前的 GC safepoint 与 service GC safepoint。如果 GC safepoint 小于 TiCDC changefeed 同步任务的开始时间戳 start-ts，则用户可以直接在 cdc cli create changefeed 命令后加上 --disable-gc-check 参数创建 changefeed。
log_diag_130: 排查 TiKV Coprocessor 任务队列排队原因。
log_diag_131: 排查监控 Grafana -> TiDB -> Batch Client/Pending Request Count by TiKV 是否大于 128，确定是否因发送远超 KV 处理能力导致发送堆积。
log_diag_132: 需要排查对应地址 TiKV 的响应时间和对应 Region 在当时的 PD 和 KV 日志，确定为什么 KV 未及时响应。
log_diag_133: 可以通过查看 TiDB 对应 Region 的 switch region peer to next due to send request fail 日志，排查发送失败根本原因，或根据 https://docs.pingcap.com/zh/tidb/stable/tidb-troubleshooting-map#44-%E6%9F%90%E4%BA%9B-tikv-%E5%A4%A7%E9%87%8F%E6%8E%89-leader 排查是否出现了 TiKV 丢 leader 的情况。
log_diag_134: 检查 DM 到下游 TiDB 的数据库连接是否出现了异常。如果错误中仅包含 invalid connection 类型的错误，且当前处于增量复制阶段，则 DM 会自动进行重试。如果 DM 由于版本问题（v1.0.0-rc.1 后引入自动重试）等未自动进行重试或自动重试未能成功，则可尝试先使用 stop-task 停止任务，然后再使用 start-task 重启任务。
log_diag_135: 检查 master 的 binlog 是否被 purge。检查 relay.meta 中记录的位点信息。