maxpayne
Новичок
База перманентно падает
Server version: 4.1.9-standard
В лог цыклично выдает одно и то же:
Number of processes running now: 0
060124 16:34:47 mysqld restarted
060124 16:34:47 [Warning] Asked for 196608 thread stack, but got 126976
060124 16:34:48 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
060124 16:34:48 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 1266877165.
InnoDB: Doing recovery: scanned up to log sequence number 0 1266878740
060124 16:34:48 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 30841285, file name host2-bin.000004
InnoDB: Last MySQL binlog file position 0 252338, file name ./host1-bin.000024
060124 16:34:49 InnoDB: Flushing modified pages from the buffer pool...
060124 16:34:49 InnoDB: Started; log sequence number 0 1266878740
060124 16:34:49 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
/usr/sbin/mysqld: ready for connections.
Version: '4.1.9-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM
060124 16:34:49 [Note] Slave SQL thread initialized, starting replication in log 'host2-bin.000004' at position 31249698, relay log './host1-relay-bin.000023' position: 98305
060124 16:34:50 [Note] Slave I/O thread: connected to master 'replica@someip:3306', replication started in log 'host2-bin.000004' at position 31250087
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1752.
InnoDB: You may have to recover from a backup.
060124 16:44:34 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex ...тут идет длинный дапм ;InnoDB: End of page dump
060124 16:44:34 InnoDB: Page checksum 2890927335, prior-to-4.0.14-form checksum 2794686309
InnoDB: stored checksum 1565558639, prior-to-4.0.14-form stored checksum 2794686309
InnoDB: Page lsn 0 1256100443, low 4 bytes of lsn at page end 1256100443
InnoDB: Page number (if stored to page already) 1752,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 2661
InnoDB: (index GEN_CLUST_INDEX of table dbname/user_preferences)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1752.
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/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
Я так понимаю, главная трабла из-за которой сервер шатдаунится - битая таблица dbname/user_preferences?
Server version: 4.1.9-standard
В лог цыклично выдает одно и то же:
Number of processes running now: 0
060124 16:34:47 mysqld restarted
060124 16:34:47 [Warning] Asked for 196608 thread stack, but got 126976
060124 16:34:48 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
060124 16:34:48 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 1266877165.
InnoDB: Doing recovery: scanned up to log sequence number 0 1266878740
060124 16:34:48 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 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
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 30841285, file name host2-bin.000004
InnoDB: Last MySQL binlog file position 0 252338, file name ./host1-bin.000024
060124 16:34:49 InnoDB: Flushing modified pages from the buffer pool...
060124 16:34:49 InnoDB: Started; log sequence number 0 1266878740
060124 16:34:49 [Warning] mysql.user table is not updated to new password format; Disabling new password usage until mysql_fix_privilege_tables is run
/usr/sbin/mysqld: ready for connections.
Version: '4.1.9-standard-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM
060124 16:34:49 [Note] Slave SQL thread initialized, starting replication in log 'host2-bin.000004' at position 31249698, relay log './host1-relay-bin.000023' position: 98305
060124 16:34:50 [Note] Slave I/O thread: connected to master 'replica@someip:3306', replication started in log 'host2-bin.000004' at position 31250087
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1752.
InnoDB: You may have to recover from a backup.
060124 16:44:34 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex ...тут идет длинный дапм ;InnoDB: End of page dump
060124 16:44:34 InnoDB: Page checksum 2890927335, prior-to-4.0.14-form checksum 2794686309
InnoDB: stored checksum 1565558639, prior-to-4.0.14-form stored checksum 2794686309
InnoDB: Page lsn 0 1256100443, low 4 bytes of lsn at page end 1256100443
InnoDB: Page number (if stored to page already) 1752,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 2661
InnoDB: (index GEN_CLUST_INDEX of table dbname/user_preferences)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 1752.
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/mysql/en/Forcing_recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
Я так понимаю, главная трабла из-за которой сервер шатдаунится - битая таблица dbname/user_preferences?
