What is the difference between INFO and WARN outputs in TiDB log entries for write conflict warnings?

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 写冲突警告的的tidblog日志INFO和WARN输出的有什么区别

| username: 舞动梦灵

Both of these alerts are write conflicts, so is the WARN write conflict problematic or is the INFO output write conflict problematic? What is the difference between the two, and can I just look at the WARN output warning information to determine write conflicts?

[2024/01/14 10:41:30.101 +08:00] [WARN] [session.go:478] [sql] [conn=43194839] [label=general] [error=“[kv:9007]Write conflict, txnStartTS=447007972396367920, conflictStartTS=447007972396367928, conflictCommitTS=447007972409475102, key={tableID=579, handle=15951961} primary={tableID=579, handle=15951961} [try again later]”] [txn=“Txn{state=invalid}”]

[2024/01/14 11:51:01.957 +08:00] [INFO] [adapter.go:621] [“pessimistic write conflict, retry statement”] [conn=43196921] [txn=447009066034921567] [forUpdateTS=447009066034921567] [err=“[kv:9007]Write conflict, txnStartTS=447009066034921567, conflictStartTS=447009066034921535, conflictCommitTS=447009066034921574, key={tableID=533, handle=17334464} primary={tableID=533, handle=17334464} [try again later]”]

| username: 小龙虾爱大龙虾 | Original post link

Thrown from different code locations, check if both occur every time.

| username: 江湖故人 | Original post link

Just ignore INFO level logs.

| username: xfworld | Original post link

There are priorities here, refer to the following:
log-level log levels: debug, info, warn, error, fatal. The default is info.

If both info and warn appear, it means there is a conflict between the two, and both need attention.

warn is more serious…

| username: 舞动梦灵 | Original post link

Are you saying that both info and warn show write conflicts for the same table, such as id110? Do you mean that the outputs of info and warn are conflicting with each other, or that both info and warn are outputting information for table_id=110? Is this a conflict that needs attention?

| username: 舞动梦灵 | Original post link

Moreover, all the conflicts are primary key conflicts. This table only has insert operations, and it only involves insert and select operations without any update or delete operations.

| username: 江湖故人 | Original post link

One is reported by session.go, and the other is reported by adapter.go. It should be reported at different stages of the writing process.

| username: 舞动梦灵 | Original post link

The table_id of the two hints are not the same.

| username: 连连看db | Original post link

TiDB’s logging is encapsulated based on zap, and the log level can be configured. Warn is more severe than info. Both indicate write conflict issues. Info indicates a conflict occurred on the first attempt, while warn indicates that the conflict persists even after multiple retries.

| username: 舞动梦灵 | Original post link

The info and warn are not reporting the same table. The info can be temporarily ignored.

| username: 有猫万事足 | Original post link

I looked at the code, and apart from the location, there isn’t much difference between the two warnings. Moreover, in version 5.0, the error level in the adapter.go file has been adjusted to debug. Your version is still too old. I checked 4.0.16, and it’s still info. It probably won’t be adjusted within the 4.0.X versions. If you don’t want to see it, you still need to upgrade.

| username: 舞动梦灵 | Original post link

Yes, the version is too old, upgrading from version 2.0 to 4.0.2. The company’s R&D department is entirely a new team within the past year. The leadership doesn’t want to make major changes; they want to ensure stability for at least one or two years before considering an upgrade. They are afraid of potential issues.

| username: 有猫万事足 | Original post link

It’s normal, I would be scared too. :joy:
Anyway, this problem is not big, it can still be used.

| username: tidb菜鸟一只 | Original post link

From what I see, the info message indicates that a write conflict has occurred but the retry hasn’t started yet. The warn message suggests that even after retrying, the conflict still exists. However, write conflicts are unavoidable and as long as they don’t affect the business, it’s fine.

| username: dba远航 | Original post link

The log levels are different depending on where they are thrown from.

| username: wangccsy | Original post link

It is probably caused by the different styles of each programmer.

| username: dockerfile | Original post link

Using an old version is worse than not using it at all. For stability, switching back to MySQL is the safest option. This is coming from a senior community user.

| username: 舞动梦灵 | Original post link

Now, including the boss, no one dares to upgrade. The database was set up around 2015 or 2016. We can only say that we will consider upgrading after more than a year.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.