mysql - 重复性 mysqld.exe 崩溃 - 操作系统错误编号 995 和 mysql 异常 0x80000003

Question

在过去的几周里，我们的 mysql 数据库一直在随机崩溃。 -

我已经检查了所有数据库是否损坏，但一切正常。

编辑 2016.01.14 - 经常弹出的错误如下 -

InnoDB: Database page corruption on disk or a failed
        InnoDB: file read of page 0.

虽然，'文件读取页'总是不同的，上次是零，但之前是4500。

一些背景知识。

• 运行 Xampp 一年多没有问题
• 我们有应用程序不断地将来自大量数据源的数据插入 MYSQL，这是 24/7。
  • 除了上述应用程序外，崩溃时没有其他应用程序在运行，我还检查了系统日志以查看是否有任何突出显示但没有。
• 两周前，我们搬到了另一台规范更好的服务器，旧服务器被克隆并放置在新服务器上。
• 数据库中没有任何更改或添加了新表。
• 一周之内，mysql 开始出错。

新服务器规范如下-

Windows Server 2008 R2 Standard - 运行 Service Pack 1

处理器:Intel(R) Xeon(R) @ 3.3ghz 2x 双处理器

8GB 内存

64 位操作系统(与旧服务器相同)

MySQL版本:5.6.20

PHP 版本 5.5.15

这是最近的错误日志-

     *************MYSQL ERROR LOG*****************



//////////////////////////////////*********************
         ERROR on 2016-01-05
******************///////////////////////

            InnoDB: The error means that the I/O operation has been aborted
            InnoDB: because of either a thread exit or an application request.
            InnoDB: Retry attempt is made.
            2016-01-05 08:42:52 cc8  InnoDB: Operating system error number 995 in a file operation.
            InnoDB: The error means that the I/O operation has been aborted
            InnoDB: because of either a thread exit or an application request.
            InnoDB: Retry attempt is made.
            2016-01-05 08:42:52 cc8  InnoDB: Operating system error number 995 in a file operation.
            InnoDB: The error means that the I/O operation has been aborted
            InnoDB: because of either a thread exit or an application request.
            InnoDB: Retry attempt is made.
            2016-01-05 08:42:53 cc8  InnoDB: Operating system error number 995 in a file operation.
            InnoDB: The error means that the I/O operation has been aborted
            InnoDB: because of either a thread exit or an application request.
            InnoDB: Retry attempt is made.
            2016-01-05 08:42:53 cc8  InnoDB: Operating system error number 995 in a file operation.
            InnoDB: The error means that the I/O operation has been aborted
            InnoDB: because of either a thread exit or an application request.
            InnoDB: Retry attempt is made.


//////////////////////////////////*********************        
        Error- 2015-12-22
********************************///////////////////////////

        2015-12-22 16:46:02 12d4 InnoDB: uncompressed page, stored checksum in field1 1169359801, calculated checksums for field1: crc32 4003191917, innodb 1169359801, none 3735928559, stored checksum in field2 4049981449, calculated checksums for field2: crc32 4003191917, innodb 587193584, none 3735928559, page LSN 128 4137924960, low 4 bytes of LSN at page end 4137853843, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 252
        InnoDB: Page may be a file space header page
        InnoDB: Database page corruption on disk or a failed
        InnoDB: file read of page 0.
        InnoDB: You may have to recover from a backup.
        InnoDB: It is also possible that your operating
        InnoDB: system has corrupted its own file cache
        InnoDB: and rebooting your computer removes the
        InnoDB: error.
        InnoDB: If the corrupt page is an index page
        InnoDB: you can also try to fix the corruption
        InnoDB: by dumping, dropping, and reimporting
        InnoDB: the corrupt table. You can use CHECK
        InnoDB: TABLE to scan your table for corruption.
        InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
        InnoDB: about forcing recovery.
        InnoDB: Database page corruption on disk or a failed
        InnoDB: file read of page 0.
        InnoDB: You may have to recover from a backup.
        2015-12-22 16:46:02 12d4 InnoDB: Page dump in ascii and hex (16384 bytes): // Lots of binary here ..

        InnoDB: End of page dump
        2015-12-22 16:46:03 12d4 InnoDB: uncompressed page, stored checksum in field1 1169359801, calculated checksums for field1: crc32 4003191917, innodb 1169359801, none 3735928559, stored checksum in field2 4049981449, calculated checksums for field2: crc32 4003191917, innodb 587193584, none 3735928559, page LSN 128 4137924960, low 4 bytes of LSN at page end 4137853843, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 252
        InnoDB: Page may be a file space header page
        InnoDB: Database page corruption on disk or a failed
        InnoDB: file read of page 0.
        InnoDB: You may have to recover from a backup.
        InnoDB: It is also possible that your operating
        InnoDB: system has corrupted its own file cache
        InnoDB: and rebooting your computer removes the
        InnoDB: error.
        InnoDB: If the corrupt page is an index page
        InnoDB: you can also try to fix the corruption
        InnoDB: by dumping, dropping, and reimporting
        InnoDB: the corrupt table. You can use CHECK
        InnoDB: TABLE to scan your table for corruption.
        InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
        InnoDB: about forcing recovery.
        InnoDB: Error: Unable to read tablespace 252 page no 0 into the buffer pool after 100 attempts
        InnoDB: The most probable cause of this error may be that the table has been corrupted.
        InnoDB: You can try to fix this problem by using innodb_force_recovery.
        InnoDB: Please see reference manual for more details.
        InnoDB: Aborting...
        2015-12-22 16:46:03 12d4  InnoDB: Assertion failure in thread 4820 in file buf0buf.cc line 2641
        InnoDB: We intentionally generate a memory trap.
        InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
        InnoDB: If you get repeated assertion failures or crashes, even
        InnoDB: immediately after the mysqld startup, there may be
        InnoDB: corruption in the InnoDB tablespace. Please refer to
        InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
        InnoDB: about forcing recovery.
        16:46:03 UTC - mysqld got exception 0x80000003 ;
        This could be because you hit a bug.
         It is also possible that this binary
        or one of the libraries it was linked against is corrupt,
         improperly built,
        or misconfigured. This error can also be caused by malfunctioning hardware.

        We will try our best to scrape up some info that will hopefully help
        diagnose the problem, 
        but since we have already crashed, 
        something is definitely wrong and this may 
        fail.

        key_buffer_size=16777216
        read_buffer_size=262144
        max_used_connections=107
        max_threads=151
        thread_count=5
        connection_count=5

        It is possible that mysqld could use up to 
        key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133778 K  bytes 
        of memory


        Hope that's ok; if not, decrease some variables in the equation.


        Thread pointer: 0x22020238
        Attempting backtrace. You can use the following information to find out
        where mysqld died.
         If you see no messages after this, something went
        terribly wrong...
        50a500 
           mysqld.exe!my_thread_name()
        74392d    mysqld.exe!my_mb_ctype_mb()
        5ecdb6   
         mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        61d611  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        647350  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        6492fa   
         mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        649383  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        6493b3  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        64945d  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        6495cb  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        5d48e3  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        53f011  
          mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        2be48e  
          mysqld.exe!?ha_write_row@handler@@QAEHPAE@Z()
        3d8d10   
         mysqld.exe!?write_record@@YAHPAVTHD@@PAUTABLE@@PAVCOPY_INFO@@2@Z()
        3df599   
         mysqld.exe!?mysql_insert@@YA_NPAVTHD@@PAUTABLE_LIST@@AAV?$List@VItem@@@@AAV?$List@V?$List@VItem@@@@@@22W4enum_duplicates@@_N@Z()
        2ecdf5    
        mysqld.exe!?mysql_execute_command@@YAHPAVTHD@@@Z()
        2ef81e    
        mysqld.exe!?mysql_parse@@YAXPAVTHD@@PADIPAVParser_state@@@Z()
        2f06f8   
         mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PAVTHD@@PADI@Z()
        2f135a   
         mysqld.exe!?do_command@@YA_NPAVTHD@@@Z()
        364e59    mysqld.exe!?do_handle_one_connection@@YAXPAVTHD@@@Z()
        364efd  
          mysqld.exe!handle_one_connection()
        6bb8cb    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
        510336  
          mysqld.exe!win_pthread_mutex_trylock()
        746c00    mysqld.exe!my_mb_ctype_mb()
        746c8a  
          mysqld.exe!my_mb_ctype_mb()
        7728338a    kernel32.dll!BaseThreadInitThunk()
        77c297f2  
          ntdll.dll!RtlInitializeExceptionChain()
        77c297c5 
           ntdll.dll!RtlInitializeExceptionChain()


        Trying to get some variables.
        Some pointers may be invalid and cause the dump to abort.
        Query (21e3387c): INSERT INTO 'WPM'(
        `Pos`, 
        `FileMod`, 
        `Duration`) VALUES (
        'IWM', 
        '2015-12-14 07:47:47 ',  
        0)Connection ID (thread ID): 3722
        Status: NOT_KILLED


        The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains

        information that should help you find out what is causing the crash.
        2015-12-23 08:21:58 4920 
        [Note] Plugin 'FEDERATED' is disabled.
        2015-12-23 08:21:58 10c4 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
        2015-12-23 08:21:58 4920 [Note] InnoDB: Using atomics to ref count buffer pool pages
        2015-12-23 08:21:58 4920 [Note] InnoDB: The InnoDB memory heap is disabled
        2015-12-23 08:21:58 4920 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
        2015-12-23 08:21:58 4920 [Note] InnoDB: Memory barrier is not used
        2015-12-23 08:21:58 4920 [Note] InnoDB: Compressed tables use zlib 1.2.3
        2015-12-23 08:21:58 4920 [Note] InnoDB: Not using CPU crc32 instructions
        2015-12-23 08:21:58 4920 [Note] InnoDB: Initializing buffer pool, size = 16.0M
        2015-12-23 08:21:58 4920 [Note] InnoDB: Completed initialization of buffer pool
        2015-12-23 08:21:58 4920 [Note] InnoDB: Highest supported file format is Barracuda.
        2015-12-23 08:21:58 4920 [Note] InnoDB: Log scan progressed past the checkpoint lsn 553893690098
        2015-12-23 08:21:58 4920 [Note] InnoDB: Database was not shutdown normally!
        2015-12-23 08:21:58 4920 [Note] InnoDB: Starting crash recovery.
        2015-12-23 08:21:58 4920 [Note] InnoDB: Reading tablespace information from the .ibd files...
        2015-12-23 08:21:59 4920 [Note] InnoDB: Restoring possible half-written data pages 
        2015-12-23 08:21:59 4920 [Note] InnoDB: from the doublewrite buffer...
        InnoDB: Doing recovery: scanned up to log sequence number 553893828751
        InnoDB: 1 transaction(s) which must be rolled back or cleaned up
        InnoDB: in total 151 row operations to undo
        InnoDB: Trx id counter is 152858880
        2015-12-23 08:22:00 4920 [Note] InnoDB: Starting an apply batch of log records to the database...
        InnoDB: Progress in percent: 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
        InnoDB: Apply batch completed
        2015-12-23 08:22:00 4920 [Note] InnoDB: 128 rollback segment(s) are active.
        InnoDB: Starting in background the rollback of uncommitted transactions
        2015-12-23 08:22:00 2c4  InnoDB: Rolling back trx with id 152858375, 151 rows to undo
        2015-12-23 08:22:00 4920 [Note] InnoDB: Waiting for purge to start
        2015-12-23 08:22:00 4920 [Note] InnoDB: Rollback of trx with id 152858375 completed
        2015-12-23 08:22:00 2c4  InnoDB: Rollback of non-prepared transactions completed
        2015-12-23 08:22:00 4920 [Note] InnoDB: 5.6.20 started; log sequence number 553893828751
        2015-12-23 08:22:00 4920 [Note] Server hostname (bind-address): '*'; port: 3306
        2015-12-23 08:22:00 4920 [Note] IPv6 is available.
        2015-12-23 08:22:00 4920 [Note]   - '::' resolves to '::';
        2015-12-23 08:22:00 4920 [Note] Server socket created on IP: '::'.
        2015-12-23 08:22:00 4920 [Note] Event Scheduler: Loaded 11 events
        2015-12-23 08:22:00 4920 [Note] c:\xampp\mysql\bin\mysqld.exe: ready for connections.
        Version: '5.6.20'  socket: ''  port: 3306  MySQL Community Server (GPL)
        2015-12-23 08:24:07 5736 [Note] Plugin 'FEDERATED' is disabled.
        2015-12-23 08:24:07 fc8 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
        2015-12-23 08:24:07 5736 [Note] InnoDB: Using atomics to ref count buffer pool pages
        2015-12-23 08:24:07 5736 [Note] InnoDB: The InnoDB memory heap is disabled
        2015-12-23 08:24:07 5736 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
        2015-12-23 08:24:07 5736 [Note] InnoDB: Memory barrier is not used
        2015-12-23 08:24:07 5736 [Note] InnoDB: Compressed tables use zlib 1.2.3
        2015-12-23 08:24:07 5736 [Note] InnoDB: Not using CPU crc32 instructions
        2015-12-23 08:24:07 5736 [Note] InnoDB: Initializing buffer pool, size = 16.0M
        2015-12-23 08:24:07 5736 [Note] InnoDB: Completed initialization of buffer pool
        2015-12-23 08:24:07 5736 [Note] InnoDB: Highest supported file format is Barracuda.
        2015-12-23 08:24:07 5736 [Note] InnoDB: Log scan progressed past the checkpoint lsn 553896050587
        2015-12-23 08:24:07 5736 [Note] InnoDB: Database was not shutdown normally!
        2015-12-23 08:24:07 5736 [Note] InnoDB: Starting crash recovery.
        2015-12-23 08:24:07 5736 [Note] InnoDB: Reading tablespace information from the .ibd files...
        2015-12-23 08:24:07 5736 [Note] InnoDB: Restoring possible half-written data pages 
        2015-12-23 08:24:07 5736 [Note] InnoDB: from the doublewrite buffer...
        InnoDB: Doing recovery: scanned up to log sequence number 553896774958
        2015-12-23 08:24:07 5736 [Note] InnoDB: Starting an apply batch of log records to the database...
        InnoDB: Progress in percent: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
        InnoDB: Apply batch completed


//////////////////////////////////*********************
Error on 2016-01-08
********************////////////////////////
    2016-01-08 00:00:14 1584 InnoDB: uncompressed page, stored checksum in field1 1299653197, calculated checksums for field1: crc32 90466284, innodb 1299653197, none 3735928559, stored checksum in field2 341870525, calculated checksums for field2: crc32 90466284, innodb 3590763946, none 3735928559, page LSN 129 3920058837, low 4 bytes of LSN at page end 3920015931, page number (if stored to page already) 75791, space id (if created with >= MySQL-4.1.1 and stored already) 0
    InnoDB: Page may be an update undo log page
    InnoDB: Database page corruption on disk or a failed
    InnoDB: file read of page 75791.
    InnoDB: You may have to recover from a backup.
    InnoDB: It is also possible that your operating
    InnoDB: system has corrupted its own file cache
    InnoDB: and rebooting your computer removes the
    InnoDB: error.
    InnoDB: If the corrupt page is an index page
    InnoDB: you can also try to fix the corruption
    InnoDB: by dumping, dropping, and reimporting
    InnoDB: the corrupt table. You can use CHECK
    InnoDB: TABLE to scan your table for corruption.
    InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    InnoDB: Ending processing because of a corrupt database page.
    2016-01-08 00:00:14 1584  InnoDB: Assertion failure in thread 5508 in file buf0buf.cc line 4195
    InnoDB: We intentionally generate a memory trap.
    InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
    InnoDB: If you get repeated assertion failures or crashes, even
    InnoDB: immediately after the mysqld startup, there may be
    InnoDB: corruption in the InnoDB tablespace. Please refer to
    InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
    InnoDB: about forcing recovery.
    00:00:14 UTC - mysqld got exception 0x80000003 ;
    This could be because you hit a bug. It is also possible that this binary
    or one of the libraries it was linked against is corrupt, improperly built,
    or misconfigured. This error can also be caused by malfunctioning hardware.
    We will try our best to scrape up some info that will hopefully help
    diagnose the problem, but since we have already crashed, 
    something is definitely wrong and this may fail.

    key_buffer_size=16777216
    read_buffer_size=262144
    max_used_connections=113
    max_threads=151
    thread_count=5
    connection_count=4
    It is possible that mysqld could use up to 
    key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133778 K  bytes of memory
    Hope that's ok; if not, decrease some variables in the equation.

    Thread pointer: 0x0
    Attempting backtrace. You can use the following information to find out
    where mysqld died. If you see no messages after this, something went
    terribly wrong...
    116a500    mysqld.exe!my_thread_name()
    13a392d    mysqld.exe!my_mb_ctype_mb()
    12c7aa2    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    12c82ad    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    1225a72    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    11d423b    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    11d4694    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    11d548a    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    11b147d    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    11b167d    mysqld.exe!?my_aes_create_key@@YAXPBEIPAEW4my_aes_opmode@@@Z()
    7728338a    kernel32.dll!BaseThreadInitThunk()
    77c297f2    ntdll.dll!RtlInitializeExceptionChain()
    77c297c5    ntdll.dll!RtlInitializeExceptionChain()
    The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
    information that should help you find out what is causing the crash.
    InnoDB: Warning: a long semaphore wait:
    --Thread 6764 has waited at trx0undo.cc line 1778 for 29770.00 seconds the semaphore:
    Mutex at 1B4F60EC created file trx0rseg.cc line 196, lock var 1
    waiters flag 1
    InnoDB: ###### Starts InnoDB Monitor for 30 secs to print diagnostic info:
    InnoDB: Pending preads 0, pwrites 0

这是 mysql.ini 设置文件(如果有帮助的话)

# The MySQL server
[mysqld]
port= 3306
socket = "C:/xampp/mysql/mysql.sock"
basedir = "C:/xampp/mysql" 
tmpdir = "C:/xampp/tmp" 
datadir = "C:/xampp/mysql/data"
pid_file = "mysql.pid"
# enable-named-pipe
key_buffer = 16M
max_allowed_packet = 1M
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log_error = "mysql_error.log"


# Change here for bind listening
# bind-address="127.0.0.1" 
# bind-address = ::1          # for ipv6

# Where do all the plugins live
plugin_dir = "C:/xampp/mysql/lib/plugin/" 

# Don't listen on a TCP/IP port at all. This can be a security enhancement,
# if all processes that need to connect to mysqld run on the same host.
# All interaction with mysqld must be made via Unix sockets or named pipes.
# Note that using this option without enabling named pipes on Windows
# (via the "enable-named-pipe" option) will render mysqld useless!
# 
# commented in by lampp security
#skip-networking
skip-federated

# Replication Master Server (default)
# binary logging is required for replication
# log-bin deactivated by default since XAMPP 1.4.11
#log-bin=mysql-bin

# required unique id between 1 and 2^32 - 1
# defaults to 1 if master-host is not set
# but will not function as a master if omitted
server-id   = 1

# Replication Slave (comment out master section to use this)
#
# To configure this host as a replication slave, you can choose between
# two methods :
#
# 1) Use the CHANGE MASTER TO command (fully described in our manual) -
#    the syntax is:
#
#    CHANGE MASTER TO MASTER_HOST=<host>, MASTER_PORT=<port>,
#    MASTER_USER=<user>, MASTER_PASSWORD=<password> ;
#
#    where you replace <host>, <user>, <password> by quoted strings and
#    <port> by the master's port number (3306 by default).
#
#    Example:
#
#    CHANGE MASTER TO MASTER_HOST='125.564.12.1', MASTER_PORT=3306,
#    MASTER_USER='joe', MASTER_PASSWORD='secret';
#
# OR
#
# 2) Set the variables below. However, in case you choose this method, then
#    start replication for the first time (even unsuccessfully, for example
#    if you mistyped the password in master-password and the slave fails to
#    connect), the slave will create a master.info file, and any later
#    change in this file to the variables' values below will be ignored and
#    overridden by the content of the master.info file, unless you shutdown
#    the slave server, delete master.info and restart the slaver server.
#    For that reason, you may want to leave the lines below untouched
#    (commented) and instead use CHANGE MASTER TO (see above)
#
# required unique id between 2 and 2^32 - 1
# (and different from the master)
# defaults to 2 if master-host is set
# but will not function as a slave if omitted
#server-id       = 2
#
# The replication master for this slave - required
#master-host     =   <hostname>
#
# The username the slave will use for authentication when connecting
# to the master - required
#master-user     =   <username>
#
# The password the slave will authenticate with when connecting to
# the master - required
#master-password =   <password>
#
# The port the master is listening on.
# optional - defaults to 3306
#master-port     =  <port>
#
# binary logging - not required for slaves, but recommended
#log-bin=mysql-bin


# Point the following paths to different dedicated disks
#tmpdir = "C:/xampp/tmp"
#log-update = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#bdb_cache_size = 4M
#bdb_max_lock = 10000

# Comment the following if you are using InnoDB tables
#skip-innodb
innodb_data_home_dir = "C:/xampp/mysql/data"
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = "C:/xampp/mysql/data"
#innodb_log_arch_dir = "C:/xampp/mysql/data"
## You can set .._buffer_pool_size up to 50 - 80 %
## of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
## Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

## UTF 8 Settings
#init-connect=\'SET NAMES utf8\'
#collation_server=utf8_unicode_ci
#character_set_server=utf8
#skip-character-set-client-handshake
#character_sets-dir="C:/xampp/mysql/share/charsets"

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

我根本不知道该怎么做，我在排除 Mysql 的技术方面没有经验。我查看了 MYsql 站点，显然错误代码 995 是一个已知错误，它本来是要修复的，但我读到它从未被推送到构建中。

如果您需要更多信息，请询问!

Answer 1

如果 InnoDB 从“磁盘”读取页面(如果相关 block 在操作系统缓存中，则可能来自 RAM)并且校验和与页眉中的校验和不匹配，InnoDB 会故意使 MySQL 崩溃。这就是发生在你身上的事情。

原因可能是:

• 如果您没有使用 ECC 内存，您可能只是在操作系统缓存中有一些损坏的数据。重新启动服务器将清除缓存，您可以获得一些 ECC 内存来防止它发生。 (不太可能)
• 关于磁盘损坏(更有可能):
  • 如果幸运的话，损坏发生在索引页上，您可以通过执行 innodb_recovery ( http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html ) 完全恢复
  • 如果损坏发生在数据页上，您肯定会丢失数据，但您仍然应该能够使用相同的方法恢复大部分信息。

在这种情况下，如果可能的话，我会从备份中恢复。您粘贴的另一个错误也表明系统级 I/O 问题，因此我会在它完全崩溃之前尽快进行调查。