Я удалил базу данных MySQL `performance_schema`, как я могу ее создать?

10

Исправляя проблему с ibdata / log, я случайно удалил свою performance_schemaбазу данных, я хотел бы создать новую.

mysql> SHOW VARIABLES LIKE 'perf%';
+---------------------------------------------------+---------+
| Variable_name                                     | Value   |
+---------------------------------------------------+---------+
| performance_schema                                | ON      |
| performance_schema_events_waits_history_long_size | 10000   |
| performance_schema_events_waits_history_size      | 10      |
| performance_schema_max_cond_classes               | 80      |
| performance_schema_max_cond_instances             | 1000    |
| performance_schema_max_file_classes               | 50      |
| performance_schema_max_file_handles               | 32768   |
| performance_schema_max_file_instances             | 10000   |
| performance_schema_max_mutex_classes              | 200     |
| performance_schema_max_mutex_instances            | 1000000 |
| performance_schema_max_rwlock_classes             | 30      |
| performance_schema_max_rwlock_instances           | 1000000 |
| performance_schema_max_table_handles              | 100000  |
| performance_schema_max_table_instances            | 50000   |
| performance_schema_max_thread_classes             | 50      |
| performance_schema_max_thread_instances           | 1000    |
+---------------------------------------------------+---------+
16 rows in set (0.06 sec)

Эти переменные кажутся мне подходящими.

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

mysql: удалил performance_schema, это проблема?

Есть предположения?

Можжевельник Икс
источник

Ответы:

17

Таблицы в базе данных performance_schema представляют собой набор представлений и временных таблиц, которые не хранят данные постоянно. Команда mysql_upgrade восстановит базу данных performance_schema

Из скорлупы

mysql_upgrade --user=root --password=password
Крейг Эфрейн
источник
2
Перезапустите mysqlсервис после этого! Работало только после перезагрузки у меня.
Цезарсоль
-1

Это означает, что DROP DATABASE может быть восстановлена, но только в нечетных условиях я не знаком с http://dev.mysql.com/doc/refman/5.0/en/binary-log.html.

Согласно Docs, binlogs - это просто последовательность команд, выполняемых на основе заданной контрольной точки. Так что, когда вы сделали «DROP DATABASE», вместо того чтобы сказать «О, он отбрасывает базу данных, мы должны сделать резервную копию сейчас на всякий случай», она просто записала «DROP DATABASE» в последний бинлог. Восстановление не так просто, как воспроизведение ленты назад.

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

http://dev.mysql.com/doc/refman/5.0/en/recovery-from-backups.html

Как определить, какие блоки использовать, неизвестно.

Нет ничего лучше, чем иметь полные резервные копии файловой системы. И вы должны по крайней мере иметь это, чтобы отступить.

Махеш Патил
источник
1
Я не заинтересован в восстановлении данных, которые были там, только в том, что показатели производительности могут быть собраны / сохранены снова. Решение Крейга Эфрейна сработало для этой цели.
Можжевельник Икс
-1. Данные схемы производительности не реплицируются, в binlog нечего восстанавливать (и в любом случае их нет в 5.0).
Марк Альф