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

Исправляя проблему с 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, это проблема?

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

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

Из скорлупы

mysql_upgrade --user=root --password=password

Это означает, что 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

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

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