Background:
There is a risk control module in the mall's investment promotion system, which collects credit reports for settled merchants, and gives corresponding levels based on the judicial information in the credit reports to determine whether they can be settled on the platform
If the credit rating does not meet the rules, you can go through the approval flow. Change credit rating
The credit report can be updated forcibly once a day, and the credit report will be calculated at the same time as the credit report is updated.
The loopholes in the business logic can be vaguely noticed here
The problem broke out: According to
business feedback, the credit rating of a certain company was red, but it was still red after approval.
Cannot check into the platform.
Check the log: It is
found that the sql statement is executed normally, and the return result is normal.
This. . .
Is it illogical that mysql is configured with automatic transactions?
In order to confirm that the mysql service itself is okay (mysql is likely to have no problem, recall many times in one fell swoop), I looked at the binlog and
found the corresponding statement in the binlog, and then checked the binlog and found
(according to the binlog to confirm the cause of the problem is much faster than the business log , Especially the business log or the original Linux log)
The data was updated again, causing the business system to appear to have not been updated, and the
product was pitted.
Thinking about this kind of magical problem, there is a high probability that the data has been modified again, and there is a high probability that there will be no problems with the mature mysql\middleware.
For online difficult problems, we must combine business.