I am using mysql table on my website where I update table frequently. Instead of altering table on remote server I do it on localhost and then upload it. While uploading I drop table first which causes problem for website user for a moment.
Is there anyway to replace table without dropping.
You can upload the table with a temporary name. After the upload completes you can drop the original and rename the temporary.
In this way the downtime would be very limited.
Related
I'm trying to run a query into a table in our MySQL database, table is called 'ac_userdata'. Whenever i run a query or update or anything, it just constantly loads and eventually (after ~5 minutes) it times out. I tried dropping the table and making a new one, but i can't even drop it. I checked to see if the table was locked, and even unlocked all tables in the database, no luck. No other table in the database and on the server has this problem, and this is one of the smallest tables in the database...
Any ideas?
Thanks!
Erouax
If there is only one table in database or you have tried to drop the table then why you don't drop the database delete database and create a new one if your current database have no data.
I'm trying to drop a table containing several hundred thousand column-based records. Normally when creating the database I use a column-based engine (infinidb) but in this case I forgot to include the ENGINE statement. So the database is pretty much unusable for my needs. Now I have a database full of tables that are taking forever to drop (it's been two hours and nothing has happened). I tried the ALTER TABLE table ENGINE=INFINIDB command but again, it's taking forever (see above re: two hours). EDIT: The first command I tried was DROP TABLE. It hung with every single table. Then I tried the ALTER command in case that was faster for some reason, but it wasn't.
Is there another way to get rid of this database? E.g. manually going into the /mysql/ directory and deleting the database? I guess I could just rename it and leave it, but I'd rather get rid of it entirely so it's not taking up space.
First of all you said Can't drop table. But in post you mentioned ALTER TABLE table ENGINE=INFINIDB.
But DROP != ALTER it is two different things.
So you can do following:
CREATE new table with same structure but engine you need.
copy(UPDATE) data from old table to the one you just created.
DROP old table.
RENAMErename new one to old name
It turned out that another process (a website) was using this database and had a couple of queries that got 'stuck' in the SQL server and caused the table to hang due to the database using the wrong engine, which I'm assuming was InnoDB since I didn't specify an engine when I initially used the "CREATE TABLE table1 AS SELECT * FROM table2" command. We finally managed to wipe the database and start over. Thanks for your help.
I am trying to use MySql temporary tables with my joomla site.
the problem is that whenever I query about the content of the table I get an empty result (except when using select statement in the same function where I create the table).
My questions are:
everytime I use $db = JFactory::getDBO() - do I create a new DB connection?
if so - how can I use temporary files?
if not - why don't I get the data of the temp table?
How can I create a temporary table that will remain until the user logs out?
You cannot use temporary tables like this, read the docs on temporary tables in MySQL here. The table will be deleted on each session, which will probably be each page load, possibly sooner, depending on how this is handled throughout Joomla.
If you want your temporary table to persist, you need to create normal table, not a temporary table...
I have a mysql table y in database xxx which I attempted to change compression type before using
alter table y row_format=compressed key_block_size=8
the process stopped half way. I removed temp file '#sql-ib265.frm and #sql-ib265' in mysql lib directory and restarted the server. However
Now when I attempt the alter table y (with the same command above) again I get error.
ERROR 1050 (42S01) at line 1: Table 'xxx/#sql-ib265' already exists
I can't drop table 'xxx/#sql-ib265' because it can't be found.
what should I do?
Edit
Solution:
I ended up dropping the old database and recreate the database.
Try to restart mysql client with the --skip-auto-rehash option and try DROP TABLE again.
If above does not work, try this from MySQL Manual:
You have a corrupt innodb data dictionary..
https://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html
Problem with Temporary Table
If MySQL crashes in the middle of an ALTER TABLE operation, you may end up with an orphaned temporary table inside the InnoDB tablespace. Using the Table Monitor, you can see listed a table with a name that begins with #sql-. You can perform SQL statements on tables whose name contains the character “#” if you enclose the name within backticks. Thus, you can drop such an orphaned table like any other orphaned table using the method described earlier. To copy or rename a file in the Unix shell, you need to put the file name in double quotation marks if the file name contains “#”.
There are two ways to fix this problem.
As other answer suggests, official MySQL documentation suggests to drop a specially crafted table. But please note in versions >= 5.1 you need to prefix table name with #mysql50#.
Move (use RENAME TO) all good tables to a temporary database, drop&recreate the original one and then move the tables back. See a blog post for details.
in additional I'm loging in with root to do the recover job but failed. then i chown the .frm file to meet the owner of mysql service and succeed.
For anyone still facing this problem, I have just followed the following steps to solve it, which (to me at least) seem far less daunting than other solutions:
Use mysqldump to back up the database with all its data.
Drop and recreate the database.
Reload the database and all its schema from the file generated in (1).
Because the orphaned tables are hidden anyway, they don't get backed up, so you end up with a database without them. I had all my procedures/functions scripted out anyway, so was able to restore them easily - if you don't, make sure you use the --routines parameter to dump those too.
My dump file was around 1.5GB for the database in question (so it's not small), and the whole thing was completed in a few minutes.
I had the same error. I fixed it by switching the order in which I dropped the tables at the beginning of the file:
DROP TABLE IF EXISTS table_name;
This line is repeated for each table. Tables with foreign keys need to be deleted before the tables with the primary keys to which they point.
I am working on a restructuring of a legacy database and its associated applications. To keep old and new working in parallel I have created a development database and copied the tables of interest to it, e.g.
create database devdb;
drop table if exists devdb.tab1;
CREATE TABLE devdb.tab1 like working.tab1;
insert into devdb.tab1 select * from working.tab1;
Having done this I notice that triggers affecting tab1 have not been copied over. Is there any way in which I can produce a working copy of tab1, i.e. data, permissions, triggers, everything?
Hmm, kind of obvious in hindsight but it would appear that dumping the tables via mysqldump and loading those dumps in the new database restores triggers (and I would hope any other relevant information).
Shame as I had wanted to do the whole process via the DbVisualizer database manager. You learn something everything day ...
Note that the "create table x select * from y" syntax will not create an exact working copy of the table, even if you're not concerned about triggers an whatnot. The new table will:
Use the default MyISAM table type (even if the parent table is InnoDB)
Default to the Latin1 character set (even if the parent table is UTF-8)
May wipe out the values of auto_incremented fields and replace them with 0 (depends on table structure but really nasty if it happens to you)
There is a quicker way to both recreate the structure and import datas (albeit you lose your indexes ;)):
create table devdb.tab1 select * from working.tab1;
For the triggers and friends, you will have to query in information_schemas