Назад | Перейти на главную страницу

Не вся таблица в mysql отображается в phpmyadmin

Недавно я случайно удалил всю свою базу данных для Wordpress, но, к счастью, я поддержал Time Machine.

Проблема теперь в том, что когда я копирую файл базы данных обратно на путь, где я храню всю базу данных, теперь только 11 из 28 таблиц отображаются в PhPAdmin Не знаю почему.

Даже я дважды проверял группу разрешений и разрешал все точно так же, как и другие базы данных, но все же я вижу только 11 из них.

Дело в том, что если он ничего не делает, я бы не возражал, но теперь мой Wordpress «Я не могу войти», он говорит, что пользователь не найден.

БОЛЬШЕ ИНФОРМАЦИИ:

Я пытался сделать ls в терминале, чтобы увидеть, была ли скопирована вся таблица, и я действительно вижу, что все они там (28 таблиц, включая какой-то файл, я не знаю, что это такое.)

Я снова делал листинг в своей базе данных и обнаружил, что здесь что-то не так.

-rw-------@ 8 _mysql  admin        65 Apr 29 20:29 db.opt
-rw-------@ 8 _mysql  admin      8802 Apr 29 22:50 wp_amazonpin_articles_keys.frm
-rw-------@ 8 _mysql  admin      8726 Apr 29 22:50 wp_amazonpin_articles_links.frm
-rw-------@ 8 _mysql  admin      9239 Apr 29 22:50 wp_amazonpin_camps.frm
-rw-------@ 8 _mysql  admin      8568 Apr 29 22:50 wp_amazonpin_categories.frm
-rw-------@ 8 _mysql  admin      8596 Apr 29 22:50 wp_amazonpin_feeds_links.frm
-rw-------@ 8 _mysql  admin      8668 Apr 29 22:50 wp_amazonpin_feeds_list.frm
-rw-------@ 8 _mysql  admin      8712 Apr 29 22:50 wp_amazonpin_keywords.frm
-rw-------@ 8 _mysql  admin      8856 Apr 29 22:50 wp_amazonpin_links.frm
-rw-------@ 8 _mysql  admin      8680 Apr 29 22:50 wp_amazonpin_log.frm
-rw-------@ 8 _mysql  admin      8688 Apr 29 22:50 wp_commentmeta.frm
-rw-------@ 8 _mysql  admin     13380 Apr 29 22:50 wp_comments.frm
-rw-------@ 8 _mysql  admin       540 Apr 29 22:12 wp_links.MYD
-rw-------@ 8 _mysql  admin      3072 Apr 29 22:50 wp_links.MYI
-rw-------@ 8 _mysql  admin     13176 Apr 29 22:12 wp_links.frm
-rw-------@ 8 _mysql  admin         0 Apr 29 22:12 wp_maker.MYD
-rw-------@ 8 _mysql  admin      1024 Apr 29 22:12 wp_maker.MYI
-rw-------@ 8 _mysql  admin      8716 Apr 29 22:12 wp_maker.frm
-rw-------@ 8 _mysql  admin      6404 Apr 29 22:12 wp_option_tree.MYD
-rw-------@ 8 _mysql  admin      8192 Apr 29 22:50 wp_option_tree.MYI
-rw-------@ 8 _mysql  admin      8800 Apr 29 22:12 wp_option_tree.frm
-rw-------@ 1 _mysql  admin   2334552 Apr 30 06:23 wp_options.MYD
-rw-------@ 1 _mysql  admin    318464 Apr 30 06:23 wp_options.MYI
-rw-------@ 8 _mysql  admin      8734 Apr 29 22:12 wp_options.frm
-rw-------@ 8 _mysql  admin      8682 Apr 29 22:50 wp_postmeta.frm
-rw-rw----@ 2 _mysql  admin  26169304 Apr 30 06:02 wp_posts.MYD
-rw-rw----@ 2 _mysql  admin  55496704 Apr 30 06:02 wp_posts.MYI
-rw-rw----@ 7 _mysql  admin     13684 Apr 30 01:14 wp_posts.frm
-rw-------@ 2 _mysql  admin    198896 Apr 30 05:55 wp_stt2_meta.MYD
-rw-------@ 2 _mysql  admin    475136 Apr 30 05:55 wp_stt2_meta.MYI
-rw-------@ 8 _mysql  admin      8698 Apr 29 22:12 wp_stt2_meta.frm
-rw-------@ 8 _mysql  admin      8666 Apr 29 22:50 wp_term_relationships.frm
-rw-------@ 8 _mysql  admin      8768 Apr 29 22:50 wp_term_taxonomy.frm
-rw-------@ 8 _mysql  admin      8668 Apr 29 22:50 wp_terms.frm
-rw-------@ 8 _mysql  admin      8684 Apr 29 22:50 wp_usermeta.frm
-rw-------@ 8 _mysql  admin      8968 Apr 29 22:50 wp_users.frm
-rw-------@ 8 _mysql  admin         0 Apr 29 22:12 wp_visitor_maps_ge.MYD
-rw-------@ 8 _mysql  admin      1024 Apr 29 22:12 wp_visitor_maps_ge.MYI
-rw-------@ 8 _mysql  admin      8628 Apr 29 22:12 wp_visitor_maps_ge.frm
-rw-------@ 8 _mysql  admin        84 Apr 29 22:12 wp_visitor_maps_st.MYD
-rw-------@ 8 _mysql  admin      2048 Apr 29 22:50 wp_visitor_maps_st.MYI
-rw-------@ 8 _mysql  admin      8622 Apr 29 22:12 wp_visitor_maps_st.frm
-rw-------@ 8 _mysql  admin    160612 Apr 29 22:12 wp_visitor_maps_wo.MYD
-rw-------@ 8 _mysql  admin     17408 Apr 29 22:50 wp_visitor_maps_wo.MYI
-rw-------@ 8 _mysql  admin      9408 Apr 29 22:12 wp_visitor_maps_wo.frm
-rw-------@ 8 _mysql  admin         0 Apr 29 22:12 wp_wpseon_syndacc.MYD
-rw-------@ 8 _mysql  admin      1024 Apr 29 22:50 wp_wpseon_syndacc.MYI
-rw-------@ 8 _mysql  admin     12901 Apr 29 22:12 wp_wpseon_syndacc.frm
-rw-------@ 4 _mysql  admin     34032 Apr 30 05:10 wp_wpseon_visits.MYD
-rw-------@ 3 _mysql  admin      4096 Apr 30 06:16 wp_wpseon_visits.MYI
-rw-------@ 8 _mysql  admin      9085 Apr 29 22:12 wp_wpseon_visits.frm

Как видно из приведенного выше списка, тот, который отображается в моем phpadmin тот, у кого MYD MYI и frm есть 11 реально отображаемых таблиц, а остальные отсутствуют.

Я не знаю, почему это действительно происходит?

Возможно, сейчас это не сильно поможет вам, но правильный способ резервного копирования базы данных - использовать утилиту для ее выгрузки (в сериализованную форму) и сохранения. Затем, когда вам нужно восстановить его, вы можете просто очистить базу данных, а затем импортировать свой дамп. Некоторое программное обеспечение позволяет создавать резервные копии базы данных через веб-интерфейс, или вы можете использовать mysqldump утилита.

Проблема, с которой вы столкнетесь при создании резервных копий путем сохранения фактических файлов базы данных, заключается в том, что они представляют собой нечто вроде черного ящика. У вас мало или нет никаких гарантий относительно них. Например, СУБД (mysql) может хранить некоторые вещи в памяти и ждать, чтобы сбросить их на диск по причинам, связанным с памятью. Это означает, что когда вы это сделаете, даже если вы получили все файлы и правильно скопировали их обратно, а СУБД их принимает, они могут оказаться в несогласованном состоянии, если вы сделаете что-либо, кроме резервного копирования каталога данных полностью, пока демон mysql не запущен.

Однако убедитесь, что mysql имеет разрешение на файлы таблиц. Например, если вы используете MyISAM, убедитесь, что tablename.frm, tablename.MYD, и tablename.MYI существует. Если вы используете innodb, есть также файл с именем ibdata1 и еще один позвонил db.opt в котором, если я помню, хранится часть определений таблиц.

Как правило, если вы собираетесь выполнить двоичное восстановление, что является крайней мерой, вы не просто восстанавливаете часть каталога данных; вы останавливаете демон mysql, переименовываете существующий каталог данных и копируете весь резервный каталог на место перед перезапуском демона. Попытка выполнить двоичное восстановление только для некоторых таблиц дает неопределенные результаты, включая, но не ограничиваясь тем, что вы испытали.