In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

#ANSWER TO YOUR ACTUAL QUESTION Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database within the system tablespace (ibdata1) and the tables inside that database.

#SUGGESTION You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.

In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

ANSWER TO YOUR ACTUAL QUESTION

Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database within the system tablespace (ibdata1) and the tables inside that database.

SUGGESTION

You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.

In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

#ANSWER TO YOUR ACTUAL QUESTION Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database within the system tablespace (ibdata1) and the tables inside that database.

#SUGGESTION You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.

In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

#ANSWER TO YOUR ACTUAL QUESTION Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database within the system tablespace (ibdata1) and the tables inside that database.

#SUGGESTION You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.

In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

#ANSWER TO YOUR ACTUAL QUESTION Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database with in the system tablespace (ibdata1).

#SUGGESTION You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.

In the above example you gave, DELETE is part of DML (Data Manipulation Language). For the default transaction isolation level of REPEATABLE READ, all the rows in the t1 table are made available in the rollback segments (See the Rollback Segments and Undo Space) so that the count query can have point-in-time snapshot of the rows to count.

DROP DATABASE is DDL (Data Definition Language) not DML. There are no MySQL mechanisms in place for rolling back DROP DATABASE;. In fact, the mechanisms are centered around the OS.

During a DROP DATABASE operation, you will see Checking permissions... in the processlist to verify file permissions on each table before deleting files (.frm header files + other storage-engine related files (such as .ibd,.MYD,.MYI,etc)). The database will experience a lot of MUTEX calls on every table in the database. This involves closing open file handles to each table within the database bring dropped prior to deleting the table. During that period, none of the tables are available.

#ANSWER TO YOUR ACTUAL QUESTION Once you issue DROP DATABASE;, please don't kill it. Even if you did, it is an irreversible atomic operation. For InnoDB, this includes disavowing any knowledge of that database within the system tablespace (ibdata1) and the tables inside that database.

#SUGGESTION You should configure backups (XtraBackup, mysqldump, binary logs, LVM snapshots) as a preventative measure against DROP DATABASE;. You should also schedule regular restores of the backups on Staging Servers to make sure your data is consistent.