1.実稼働環境mysqlによって引き起こされたマルチテーブルロックテーブルの状況の
話は次のとおりです。ある日、運用および保守担当者が突然私を開発者として見つけ、XXのビジネスに問題があると言いました。運用および保守担当者がビジネスに精通するようにするため、より速い成長の原則。
私は尋ねた、「問題は何？」：
：運用および保守同僚「ビジネスのためのメッセージが正常にプッシュされませんでした***。」
私は再び尋ねた：「？あなたはログを見たことがあり、」
運用・保守の同僚：：」...どこにログですか」
。。。。。。
O＆Mの同僚:: "！問題のログが表示されなかった、印刷された"
私は無知な力に見えますが、通常の実行も問題です： "ログに疑問はありませんか？"
。。。。。。
私はこの悪を信じていませんが、ログが正常なときにプログラムビジネスを完了できないのはなぜですか？
問題を確認してください。
最初にページビジネスを見てください。このビジネスは、このプロセスと同様に、最終プロセスのアーカイブステップでスタックしているようです。アーカイブステップでスタックしているだけです。カードがスタックしているため、理由があります。この注文の実行スレッドは問題を見つけることができるはずです。
アーカイブモジュールのログ：si_orderモジュール：
それを開いて参照してください：私はニマです、これは通常のログとも呼ばれます、運用および保守チームはまだうまく成長していません、ここでは10,000文字が省略されています...忘れてみましょう彼はマウステールジュースになります。
ロック待機タイムアウトを超えました;トランザクションを再起動してみてください：ロック待機タイムアウト
Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
; Lock wait timeout exceeded; try restarting transaction; nested exception is com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
at org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.doTranslate(SQLErrorCodeSQLExceptionTranslator.java:262)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:72)
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:73)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:446)
at com.sun.proxy.$Proxy93.update(Unknown Source)
at org.mybatis.spring.SqlSessionTemplate.update(SqlSessionTemplate.java:294)
at org.apache.ibatis.binding.MapperMethod.execute(MapperMethod.java:63)
at org.apache.ibatis.binding.MapperProxy.invoke(MapperProxy.java:59)
at com.sun.proxy.$Proxy94.updateStatusByOrder(Unknown Source)
at com.si.service.impl.OrderServiceImpl.operateDcprQueue(OrderServiceImpl.java:1425)
at com.si.service.impl.OrderServiceImpl$$FastClassBySpringCGLIB$$a267b731.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:746)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
at com.si.config.DataSourceAspect.around(DataSourceAspect.java:61)
at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
2.問題は、なぜロック待機タイムアウトの問題が発生するのかということです。時計はロックされていますか？
si_orderモジュールは顧客ページの操作に影響を与えないため、ユーザーが認識できないモジュールです。そのため、si_orderモジュールを停止し、ロックを解除して、しばらくしてから再起動することにしました。
案の定、この操作の後、注文モジュールの再起動後に報告されるエラーは少なくなり、問題は解決されたようです。
3.しかし、数分後、再び問題が発生しました。以前のロックタイムアウトの問題は
無力でした。注文モジュールの問題はあまり関連していないようです。問題を確認し、ログに従って実行されたSQLステートメントを見つけてください。 、次にコードに移動します。sqlが呼び出される場所を確認します。確かに、このsqlは他のモジュール、タイミングタスクモジュールによって呼び出されます。ログを開いた後、一連のログがエラーを報告します。タイミングタスクモジュールが原因の問題でしょうか？
タイミングタスクモジュールログ：
まあ、タイミングタスクモジュールはユーザーの知覚に影響を与えません、それを再起動して試してみてください！ビジネスコードがそれが何であるかを知らないので、この作品を書いた人はすでに去っています、そして彼は彼のビジネスを勉強することを気にしません、ハハ。。。。。。
この方法で問題を解決することはお勧めしません。
そのため、昼休み中に時間指定タスクモジュールが再起動されました...しばらくすると、oderモジュールは、ロック待機がタイムアウトしたことを報告しなくなり、ビジネスオーダーが完了しませんでした。スムーズに進む前に。アーカイブ。問題は解決され、タイマータスクモジュールが再起動され、エラーは報告されませんでした。問題は送受信されました。。。。
4.ロック待機タイムアウトの処理
上記のモジュール停止方法は、現時点では有用であり、根本原因を解決することはできません。したがって、今後このような問題を回避するために、ビジネスのコードを慎重に分析する必要があります。同時操作の可能性があるかどうか、またはSQLの競合の問題があるかどうかを確認してください。この方法でのみ症状を治すことができます。
モジュールを手動で終了できない場合は、ロックを待機しているsqlステートメントスレッドを手動で終了することもできます。
-- 行级死锁定位： 查询到trx_mysql_thread_id 然后kill掉；
SELECT * from information_schema.INNODB_TRX;
SELECT trx_mysql_thread_id from information_schema.INNODB_TRX;
kill ***;
写真が示すように：
