Выдача таблиц Innodb и MyISAM

Question

У меня был сбой жесткого диска, который привел к некоторым проблемам в базе данных SQL.С тех пор я восстановил из резервной копии, но проблема продолжает появляться, которая не имеет смысла для меня.Надеюсь, это будет кому-то здесь.Я действительно просто ищу помощь в том, где найти источник проблемы.Я могу исправить оттуда.Я прочитал сотни постов и без конца искал в Интернете.Конечно, кто-то может опубликовать ссылку с ответом, который я пропустил.

Сервер старый, работает под управлением CentOS 5 и MySQL 5.0.77.Я собираюсь выполнить обновление после исправления этой проблемы.

В базе данных есть таблицы MyISAM и InnoDB.Через phpmyadmin я вижу, что InnoDB не работает.Я проверил my.cnf, и там нет никаких признаков того, что он не работает, если только я что-то упустил.

    [mysqld]
innodb_file_per_table = 1
log-bin=/var/lib/mysql/

binlog-ignore-db=supp
server-id=5
#master-host=
#master-user=
#master-password=
#master-connect-retry=60
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
skip-name-resolve
relay-log=/data1/mysqld/mysqld-relay-bin
skip-slave
#set-variable    = join_buffer_size=60M
set-variable    = key_buffer=128M
set-variable    = max_allowed_packet=30M
set-variable    = table_cache=64
set-variable    = sort_buffer=8M
set-variable    = record_buffer=2M
set-variable    = myisam_sort_buffer_size=8M
set-variable    = thread_cache=4
set-variable    = thread_concurrency=2
set-variable    = max_connections=500
set-variable    = wait_timeout=3600

#


# Uncomment the following if you are using BDB tables
#set-variable   = bdb_cache_size=64M

# Point the following paths to different dedicated disks
tmpdir          = /var/tmp/
#log-update     = /path-to-dedicated-directory/hostname

innodb_data_home_dir=
innodb_data_file_path = /data1/ibdata/ibdata1:5000M;/data1/ibdata/ibdata2:5000M;/data1/ibdata/ibdata3:5000M;/data1/ibdata/ibdata4:5000M:autoextend
set-variable = innodb_buffer_pool_size=1G
set-variable = innodb_additional_mem_pool_size=5M
innodb_log_group_home_dir= /data1/iblogs
innodb_log_arch_dir = /data1/iblogs
set-variable = innodb_log_files_in_group=3
##
set-variable = innodb_log_file_size=100M
set-variable = innodb_log_buffer_size=16M
set-variable = innodb_file_io_threads=8
set-variable = innodb_lock_wait_timeout=100
set-variable = innodb_autoextend_increment=200
#
innodb_flush_log_at_trx_commit=0
innodb_log_archive=0

set-variable = innodb_lock_wait_timeout=100
#innodb_flush_method = O_DSYNC

[mysqldump]
quick
set-variable    = max_allowed_packet=16M

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

[isamchk]
set-variable    = key_buffer=2M
set-variable    = sort_buffer=1M
set-variable    = read_buffer=1M
set-variable    = write_buffer=1M

[myisamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

В phpmyadmin все таблицы InnoDB отображаются как «В работе» и сообщают об ошибке 1033.Когда я создаю новую базу данных и копирую таблицы, происходит то же самое.Единственное, что сработало, - это создание базы данных из файла дампа sql, но это создавало старые данные, так как резервная копия немного старая.В новой базе данных были все таблицы MyISAM, и они работают, за исключением некоторых синтаксических ошибок из файлов CGI, запрашивающих данные из них.Сейчас я могу обойти это.

Я не создавал этот сервер и никогда не управлял им.Я исправил множество проблем и работаю над тем, чтобы помочь кому-то помочь, но это было сложно.Я только прошу, чтобы кто-то указал мне правильное направление.

Что может вызвать проблемы с неверной информацией только у таблиц InnoDB?Я искал журналы ошибок, и они сообщают почти то же самое, множество ошибок «Неверная информация в table.frm».

Чтобы это было как можно короче, я остановлюсь здесь, но с удовольствием объяснюбольше, если необходимо.

mysqld log:

    190122 12:45:02  mysqld started
190122 12:45:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
190122 12:45:02 [Warning] option 'max_join_size': unsigned value 18446744073709551615 adjusted to 4294967295
InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.
InnoDB: If that is the case, please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.0/en/error-creating-innodb.html
190122 12:45:03 [Warning] 'user' entry 'root@fmdb2' ignored in --skip-name-resolve mode.
190122 12:45:03 [Warning] 'user' entry 'leadtraffic@www.bravelcon.com' ignored in --skip-name-resolve mode.
190122 12:45:03 [Warning] 'db' entry 'leadtraffic leadtraffic@www.bravelcon.com' ignored in --skip-name-resolve mode.
190122 12:45:03 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.0.77-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source distribution

Answer 1

Вот блог, который, я думаю, похож на ваш случай: https://eric.lubow.org/2010/mysql-error-1033-incorrect-information-in-file/

В этом случае пользователь запустил MySQL Server, но не удалось инициализировать механизм хранения InnoDB. В старых версиях MySQL, если механизм InnoDB не может запуститься, это не является фатальной ошибкой, но, как вы можете догадаться, вы не сможете читать или писать таблицы InnoDB без этого механизма. Была возможность принудительно остановить сервер, если он не может инициализировать InnoDB, но этот параметр не был включен по умолчанию в те дни.

Как показано в блоге, вы можете подтвердить, если InnoDB отключен или отсутствует в списке движков:

mysql> SHOW ENGINES;

Файлы .FRM - это файлы метаданных, которые присутствуют для таблиц независимо от механизма хранения, поэтому при запросе к таблице сначала открывается файл .FRM, чтобы получить определение таблицы. Это нормально, но если он не может прочитать таблицу data из-за того, что движок InnoDB не работает, он запутается. " Есть метаданные таблицы, но нет таблицы ?? "

Вам необходимо выяснить, почему InnoDB не может запуститься, и исправить эту проблему. Подсказки, вероятно, будут в журнале ошибок MySQL. См., Например, случай, сообщенный в этом блоге.

В блоге пользователь обнаружил, что другой процесс mysqld уже запущен и удерживал блокировку файла в табличном пространстве InnoDB ibdata1. Так что во втором случае, запуск MySQL Server не смог получить блокировку этого файла и сдался.

В вашем случае, как вы сообщали в своем вопросе пару недель назад ( ОШИБКА / usr / libexec / mysqld: неверная информация в файле ), был какой-то признак того, что у вас есть другой экземпляр mysqld работает:

190105 17:11:09 [ERROR] Can't start server: Bind on TCP/IP port: Address already in use
190105 17:11:09 [ERROR] Do you already have another mysqld server running on port: 3306 ?

---

Ошибка, которую вы указали в журнале ошибок:

InnoDB: No valid checkpoint found.
InnoDB: If this error appears when you are creating an InnoDB database,
InnoDB: the problem may be that during an earlier attempt you managed
InnoDB: to create the InnoDB data files, but log file creation failed.

Это указывает на то, что что-то не так с файлами журналов InnoDB, ib_logfile0 и ib_logfile1. Они могут быть повреждены или непригодны. Это иногда происходит, когда вы пытаетесь переместить файлы журнала во время работы mysqld.

Вы перевели свой экземпляр MySQL в рискованное состояние и можете потерять все свои данные. Я действительно рекомендую вам обратиться к квалифицированному специалисту по восстановлению данных. Я сделал эту рекомендацию и в своем последнем ответе.

Другой вариант - записать это на свой счет. Удалите все файлы InnoDB, перезапустите MySQL Server и дайте ему инициализировать новое табличное пространство (которое будет пустым).