2017-09-24 8 views
0

毎回私はすべてのテーブルをバックアップまたはチェックしようとします。Windowsサーバ2012でmysqlサーバがクラッシュする 自分の開発環境にXAMPPスタックを使用しています。 データベース暗号には、DB内に1100以上のテーブルがあります。 以下のログを含めます。mysqldump/mysqlcheckの間にMySQLがクラッシュする

のInnoDB:ページダンプの終了 2017年9月24日午前13時58分35秒7dcのInnoDBは:圧縮されていないページ、フィールド1 2521749199で保存されているチェックサム、フィールド1のために計算されたチェックサム:CRC32 2344073126、InnoDBは、なし3735928559、保存されましたフィールド2のチェックサム、フィールド2の計算チェックサム:crc32 2344073126、innodb 2892594725、なし3735928559、ページLSN 0 2936733816、LSN 0 2936733816、ページ番号0、ページ番号(ページに既に格納されている場合)34、スペースID InnoDB:ページタイプ17855はインデックスを意味します InnoDB:インデックスIDが1522のインデックスページになる可能性があります。 InnoDB:( "crypto"テーブルのインデックス "PRIMARY" 300トークン」) 2017-09-24 13:58:35 2012 [ ERROR] InnoDB:オペレーティングシステムが独自のファイルキャッシュを壊している可能性もあります。 2017-09-24 13:58:35 2012 [ERROR] InnoDB:コンピュータを再起動するとエラーが取り除かれます。 2017-09-24 13:58:35 2012 [ERROR] InnoDB:破損したページがインデックスページの場合は、 2017-09-24 13:58:35 2012 [ERROR] InnoDB:破損を修正してくださいダンピング、削除、再インポートによって 2017-09-24 13:58:35 2012 [ERROR] InnoDB:破損したテーブル。 CHECKを使用することができます 2017-09-24 13:58:35 2012 [ERROR] InnoDB:TABLEを使用してテーブルの破損をスキャンします。 2017-09-24 13:58:35 2012 [ERROR] InnoDB:回復を強制することについてhttp://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.htmlも参照してください。 2017-09-24 13:58:35 7dc InnoDB:ファイル内のアサーションエラーbuf0lru.cc行2394 InnoDB:失敗アサーション:bpage-> buf_fix_count == 0 InnoDB:意図的にメモリトラップを生成します。 InnoDB:詳細なバグレポートをhttp://bugs.mysql.comに提出してください。 InnoDB:アサーションの失敗やクラッシュが繰り返された場合でも、 InnoDB:mysqldの起動直後に、 InnoDB:InnoDBテーブルスペースが破損する可能性があります。 InnoDBを参照してください:http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html InnoDB:リカバリについて 170924 13:58:35 [エラー] mysqldが例外0x80000003を取得しました。 これは、バグを起こした可能性があります。このバイナリ またはそれがリンクされたライブラリの1つが壊れていたり、不適切に構築されていたり、 または誤って構成されている可能性もあります。このエラーは、誤動作したハードウェアによっても発生する可能性があります。

我々がうまくいけば が問題を診断するのに役立ちますが、我々はすでにクラッシュしておりますので、何かが 間違いなく間違っていると、これは失敗する可能性がいくつかの情報をこすりするために全力を尽くすhttps://mariadb.com/kb/en/reporting-bugs

を参照してください、このバグを報告するには。

Serverバージョン:10.1.22-MariaDB key_buffer_sizeは= 16777216 read_buffer_size = 262144 max_used_connections = 1 MAX_THREADS = 1001 THREAD_COUNT = 1これは、mysqldが key_buffer_sizeは+(read_buffer_size + sort_buffer_size)まで使用可能性がある* MAX_THREADS = 787106 Kバイトのメモリが大丈夫です。もしそうでなければ、数式中のいくつかの変数を減らしてください( )。

スレッドポインタ:0x0バックトレースを試みています。次の 情報を使用して、mysqldがどこで亡くなったかを調べることができます。あなたはこの後何もメッセージ が表示されない場合、何かがひどく間違っ... mysqld.exe!my_parameter_handler()mysqld.exe!my_wildcmp_mb_bin() mysqld.exe!?save_in_result_fieldの@項目@@ UAEX_Nする@ Z() mysqldを行ってきました。 mysqld.exe!save_in_result_field @ item @@ UAEX_N @ Z() mysqld.exe!save_in_result_field @ Item @@ UAEX_N @ Z() mysqld.exe! ?save_in_result_fieldの@項目@@ UAEX_N @ Z() KERNEL32.DLL!BaseThreadInitThunk() ntdll.dllの!RtlInitializeExceptionChain() ntdll.dllの!RtlInitializeExceptionChain() http://dev.mysql.com/doc/mysql/en/crashing.htmlのマニュアルページでは見つける手助けすべき情報 が含まれていますthを引き起こしているものeクラッシュ。

誰かが私を助けてくれることを願っています。 ありがとうございました。あなたの質問でこの内容から

+0

「chkdsk」を実行してMySQLを再インストールするような基本的なことを試してください。 Windowsは一般的に不安定なので、可能であれば、Linuxシステムでこれを試してみてください。 – kmoser

答えて

0

、 「Serverバージョン:10.1.22-MariaDB key_buffer_sizeは= 16777216 read_buffer_size = 262144 max_used_connections = 1 MAX_THREADS = 1001 THREAD_COUNT = 1それは(mysqldが+ key_buffer_sizeはまで使用可能性があるread_buffer_size + sort_buffer_size)* max_threads = 787106 K .... "

max_threads=1001上記のヒント - my.iniまたは.cnfのmax_connectionsを確認してください。 max_connectionsを= 100に下げると、BaseThreadInitThunk()ntdll.dllを越えてしまうかもしれません。

関連する問題