Descarté la base de datos `performance_schema` de MySQL, ¿cómo puedo crearla?

Mientras solucionaba un problema de ibdata / log, accidentalmente dejé caer mi performance_schemabase de datos, me gustaría crear una nueva.

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)

Esas variables me parecen estar bien.

La siguiente pregunta hace lo mismo, sin embargo, el usuario concluye que pudieron crearla siguiendo la documentación en la que no pude encontrar tales instrucciones.

mysql: eliminado performance_schema, ¿es un problema?

¿Alguna idea?

Las tablas en la base de datos performance_schema son una colección de vistas y tablas temporales que no almacenan datos permanentemente. El comando mysql_upgrade restaurará la base de datos performance_schema

De la cáscara

mysql_upgrade --user=root --password=password

Alude a que DROP DATABASE sea recuperable, pero solo en condiciones extrañas no estoy familiarizado con http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

Según Docs, los binlogs son solo una secuencia de comandos ejecutados en función de un punto de referencia dado. Entonces, cuando hiciste "DROP DATABASE", en lugar de decir "Oh, está descartando la base de datos, deberíamos hacer una copia de seguridad ahora por si acaso" simplemente escribió una "DROP DATABASE" en el último binlog. La recuperación no es tan simple como reproducir la cinta al revés.

Lo que debe hacer es recuperar la base de datos de un último bien conocido y aplicar los binlogs que ocurrieron entre ese punto de recuperación y el comando DROP.

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

Cómo se determina qué binlogs usar, no está claro.

No hay nada mejor que tener copias de seguridad completas del sistema de archivos. Y al menos debería tener estos a los que recurrir.