I have a staging server in which I need to drop a database and re-populate it with different tables. This is normally as easy as:
DROP DATABASE testbd;
However, usually whenever I drop the staging database, there are about 100 (valid) connections to it, and I do not care about those. Is there a fool-proof method to do a drop database without having to figure out whether there are open transactions, or this or that?
My thought was doing something like the following conceptually:
# get a global lock on everything -- no one except me can do anything now
CREATE LOCK
# get all active connections and then kill them
select concat('CALL mysql.rds_kill( ',id,');') from information_schema.processlist where DB='avails';
-- run each select statement
# drop the database
DROP DATABASE testdb
# if this is required?
END LOCK
The above is pseudo-code but I'm basically looking for a way to be able to issue a command and the database to drop within 5 seconds in a failproof way.
Related
in my database when select from 2 of 10 tables, in spesefic rows , i give this message :
ERROR 2006 (HY000): MySQL server has gone away
for example whene i try :
select * from records where id=238
every thing is ok , and even this:
select * from records where id=270
is ok.
but when try this one:
select * from records where id=239
return error :
i already search in stackoverflow and google for this and all refrence mention that increace buffer size and...
but i dont think this problem relate to this subjects , its seems that some data is currept the table.
p.s : engine that use is innodb
any clue please
MySQL closes itself when a operation tries to read from a corrupted InnoDB table.
This is very annoying but is the only way I know by heart.
Is possible to recover all data in most of times, the procedure is the same for MySQL, MariaDB and XtraDB.
There is a lot of explanation on the official manual https://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html.
But, essentially, you need to add an option named innodb_force_recovery on MySQL configuration file, restart MySQL and try to SELECT that corrupted data. This options goes from number 1 to 6, but above 3 you could lose some data.
When you found a number that allow you to make a SELECT on that rows, mysqldump the entire table to recover after.
Depending on table state you'll need to remove the file manually before start MySQL without innodb_force_recovery:
rm /var/lib/mysql/myschema/corrupted_table.ibd
This will cause other problems, but once the database start you'll need to drop the old tablespace, create "the same table" in another database and swap the tablespaces:
USE a;
ALTER TABLE corrupted_table DISCARD TABLESPACE;
CREATE DATABASE b;
-- import the dump inside database b
-- fisically move the "ibd" file from "b" to "a"
-- mv /var/lib/mysql/a/corrupted_table.idb /var/lib/mysql/b/corrupted_table.idb
USE a;
ALTER TABLE corrupted_table IMPORT TABLESPACE;
DROP TABLE b.corrupted_table;
This situation makes no sense.
I have the following sequence of SQL operations in my php code:
DROP TABLE IF EXISTS tablename;
CREATE TABLE tablename;
Of course the php code does not look like that, but those are the commands being executed.
Every once in a while on the CREATE statement, the system returns "table already exists".
I would not think this could happen, unless it is some kind of delay in the dropping. The table is Innodb and I read that there could be processes using the table. However, the tablename has embedded within it a session_id for the user, because this table is somewhat transient and is dedicated to the specific user only--no other user can be using the table, and not even any other script can be using it. It is a "user-specific, script-specific" table. However, it is possible that the user could execute this script, go away to a different script, then come back to this script.
The describe code is in a routine that decides whether it can re-use the table, or whether it has to be recreated. If it has to be recreated, then the two lines execute.
Any ideas what is causing this error condition?
EDIT:
The problem with "actual code" is that sometimes it just leads to more questions that diverge from the actual point. Neverthess, here is a copy from the actual script:
$query1 = "DROP TABLE IF EXISTS {$_SESSION['tmpContact']}";
SQL($query1);
$memory_table = "CREATE TABLE {$_SESSION['tmpContact']}";
The SQL() function executes the command and has error handling.
Plan A: Check for errors after the DROP. There may be a clue there.
Plan B: CREATE TEMPORARY TABLE ... -- That will be local to the connection, so [presumably] you won't need the DROP.
$a = mysql_query("SELECT TABLE");
if($a != ''){}else{}
try mixing the php with the sql.
I want be able to debug easily my scripts in Mysql, like in MSSQL (run a chunk of the script then verify the tables and so on), but the temporary tables are not persisted on the server.
For example :
CREATE temporary table a(i int);
INSERT INTO a VALUE (1);
SELECT * FROM a;
If I run the whole script it returns me the right result, but if I run it statement by statement on the insert I get the following error:
SQL.sql: Error (2,13): Table 'test.a' doesn't exist
I suppose this is a server configuration problem.
Temporary tables are dropped when the transaction is over.
from dev.mysql:
Temporary Tables:
You can use the TEMPORARY keyword when creating a
table. A TEMPORARY table is visible only to the current connection,
and is dropped automatically when the connection is closed. This means
that two different connections can use the same temporary table name
without conflicting with each other or with an existing non-TEMPORARY
table of the same name. (The existing table is hidden until the
temporary table is dropped.) To create temporary tables, you must have
the CREATE TEMPORARY TABLES privilege.
Note CREATE TABLE does not automatically commit the current active
transaction if you use the TEMPORARY keyword.
So if you run all these sql in deferent transactions you temporary table wont exist when you run the insert statement.
If these executions are executed in diferent transactions depend on what interface you use. Thats wy if you "run the whole script it returns me the right result" because its all in the same transaction.
You can try to force it to run on the same transaction with:
START TRANSACTION;
<SQL QUERYS>
COMMIT;
anyway i recomend you MySQL Workbench as interface.
my best regards, i hope this help you.
I'm doing an update to MySQL Database which includes MySQL scripts that make ALTER TABLE sentences, as well as DIU sentences (delete, insert, update).
The idea is to make a transactional update, so if a sentence fails, a rollback is made, but if I put ALTER TABLE sentences or others specified in http://dev.mysql.com/doc/refman/5.0/en/implicit-commit.html an implicit commit is made, so I can't make a complete rollback, because the indicated operations remains commited.
I tried to use mysqldump to make a backup which is used in case of error (mysql returns distinct to zero), but it is too slow and can fail too.
What can I do? I need this to ensure that future updates are safe and not too slow, because databases contains between 30-100 GB of data.
dump and reload might be your best options instead of alter table.
From mysql prompt or from the database script:
select * from mydb.myt INTO OUTFILE '/var/lib/mysql/mydb.myt.out';
drop table mydb.myt;
create tablemyt(your table ddl here)
load data infile '/var/lib/mysql/mydb.myt.out' INTO TABLE mydb.myt;
Check this out:
http://everythingmysql.ning.com/profiles/blogs/whats-faster-than-alter
I think it offers good guidance on "alternatives to alter".
Look at pt-online-schema change.
You can configure it to leave the 'old' table around after the online ALTER is completed. The old table will have an underscore prefix. If bad things happen, drop the tables you altered and renamed the OLD tables to the original tables. If everything is OK, then just drop the OLD tables.
http://www.percona.com/doc/percona-toolkit/2.1/pt-online-schema-change.html
I'm having a problem dropping a temporary table. The user account does not have the 'drop' privilege. I don't want to grant that privilege due to security reasons.
I tried to find a privilege like 'drop temporary' but there isn't. It seems the only option is to remove all the 'drop table' statements. I know that the temporary tables will be automatically dropped after the DB sessions end.
However, I'm not sure if there are any side effects leaving this job to MySQL. Please, advice.
Temporary tables are dropped automatically as soon as you disconnect from database
A TEMPORARY table is visible only to the current connection, and is dropped automatically when the connection is closed
http://dev.mysql.com/doc/refman/5.1/en/create-table.html
So - create them, use and don't bother of theirs deletion
It will use current machine's Ram space.
So better idea is drop the temporary table on the next step ,once its use is over
If the user has CREATE TEMPORARY TABLES privilege, he can perform DROP TABLE, INSERT, UPDATE and SELECT.
Please see: https://dev.mysql.com/doc/refman/5.7/en/privileges-provided.html#priv_create-temporary-tables