Wondering if there is a way to skip / ignore all temp tables using mysqldump. In our instance, these tables are prefixed as tmp{guid}.
These temp tables have a very short lifespan, they are used for building some sort of reports in its parent application. Lifetime may be up to 1 minute.
EDIT:
It has been suggested that I use the ignore-tables parameter, unfortunately this doesn't provide a way for me to specify a wildcard as the table name (tmp*).
You are not talking about tables from CREATE TEMPORARY TABLE ..., correct? Instead, you are talking about a set of tables with a particular naming convention?
Instead of trying to do it with table names, do it with a DATABASE:
CREATE TABLE TempTables;
CREATE TABLE TempTables.abcd (...);
And reference them via the db name:
INSERT INTO TempTables.abcd ...
SELECT ... FROM TempTables.abcd JOIN ...
Then use the suitable parameters on mysqldump to avoid that oneDATABASE` (or pick all the other databases to dump).
Related
So I have this problem where I need to create an exact copy of another table (schema, indexes) but not the data. We need to temporarily store data before we move it to the table it mirrors.
I can create a mirror table like CREATE TABLE foo_mirror LIKE foo; But I want to automatically update the schema when the schema of the table foo changes'.
I have considered temporary tables as well instead of mirror tables but we will have 2 different processes copying data to the mirror table foo_mirror and copying data to the actual table foo. So I can't use a single session.
So I can compare the schema using the following queries:
-- for_mirror schema
SELECT DISTINCT *
FROM `information_schema`.`columns`
WHERE `TABLE_NAME` LIKE 'foo_mirror'
-- foo schema
SELECT DISTINCT *
FROM `information_schema`.`columns`
WHERE `TABLE_NAME` LIKE 'foo'
I could write some code that will apply updates in a job, or perhaps a trigger. I'm wondering if there is a better way to keep tables in sync or even a tool where I don't need to manage this myself.
I also see a potential problem e.g. Changing the type for a column may fail if data hasn't been updated correctly in the mirror table (string to integer - "one" -> 1).
I am copying individual tables from a master databases to a number of read-only slaves (the mysql user is restricted to read-only). One easy way to copy tables is:
CREATE TABLE slave_db.x LIKE master_db.x;
INSERT INTO slave_db.x SELECT * FROM master_db.x;
This will not copy the foreign keys or set the auto increment index correctly. Is there any reason to transfer the constraints, given there is no possibility of slave database modifications?
No, if it is only to read purposes you don't need to copy the constraints. It will be even faster this way (Although you should create appropriate indexes).
Also, you can do as simple as:
CREATE TABLE slave_db.x as
SELECT * FROM master_db.x;
I want to replicate certain table from one database into another database in the same server. This tables contain exactly the same fields.
I was considering to use MySQL Replication to replicate that table but some people said that it will increase IO so i find another way to create 3 Trigger (Insert, update and Delete) that will perform exactly the same thing like what i expect.
My Question is, which way is better? Is it using MySQL replication is better even though it's in the same server or using Trigger to replicate the data is better.
Thanks.
I don't know what is your goal, but I got mine getting use of the VIEW functionality.
I had two different applications with separate databases but in the same Mysql server. Application2 needed to get a few data from Application1. In general, this is a trivial situation that you can handle with USE DB1; or USE DB2; as your needing, but my programming framework does not work very well with multiple DBs.
So, lets see my solution...
Here is my select query to retrieve this data:
SELECT id, name FROM DB1.customers;
So, using DB2 as default schema, I've created a VIEW:
USE DB2;
CREATE VIEW app1_customers AS SELECT id, name FROM DB1.customers;
Now I can retrieve this data in DB2 as a regular table with a regular SELECT statement.
SELECT * FROM DB2.app1_customers;
Hope ts useful. BR
Assuming you have two databases on the same server i.e DB1 and DB2 and the table is called tbl1 and it is sitting in DB1 you can query the table like this:
USE DB1;
SELECT * FROM tbl1;
USE DB2;
SELECT * FROM DB1.tbl1;
This way you wont need to copy the data and worry about extra space and extra code. You can query a table in another database on the same server. Replication and triggers are not your answer here. You could also create a view to encapsulate the SQL statement.
Definitely triggers is the way to go. Having another server (slave) will need to spare several MB for installation, logs, cpu and memory usage.
I'd use triggers to keep both tables equal. If you want to create a table with the same columns definition and data use:
USE db2;
CREATE TABLE t1 AS SELECT * FROM db1.t1;
After that, go ahead and create the triggers for Update, Insert and Delete statemetns.
Also you could ALTER the new table to a different engine like MEMORY or add indexes to see if you can improve something.
so the code I am working on has this statement executed by PHP (note:This is taken from the PostgreSQL log file so it doesn't include any PHP stuff):
CREATE temporary table IF NOT EXIST temp tablename(id int primary key,
shared int default 0) replace select 1, userid as id
from tablefoo where sharedid = 1337
I don't quite understand what's going on here exactly, I know what a temporary table is, and I can quite accurately guestimate what IF NOT EXIST does, but what is replace doing here? I know replace is like insert but it replaces stuff as well, but in this case, nothing is specified for it to replace with, so does it just replace something with nothing and why the Select 1, I know that pretty much just tells you if your table has rows or something, but what is the point of using it here?
After some research, I found that IF NOT EXIST and replace do not exist in PostgreSQL. Most online sources suggest that SQL functions be used to replace them.
Should I use an SQL function to emulate IF NOT EXIST? If so, what would I write (sorry, I am pretty new to SQL) or should I just use a PHP function.
What about replace?
Sorry for the trouble, thanks for your time, oh and if you guys aren't busy or anything, you could also tell me about how to emulate "ignore", my current solution involves arbitrarily removing it.
Many uses in MySQL for temporary tables can be replaced in PostgreSQL with common table expressions or ordinary subselects.
WITH someCTE AS (
SELECT
...
) SELECT/UPDATE/DELETE ... WHERE sometable.column = someCTE.another_column;
Look into CREATE TABLE documentation. Temporary tables are just as name suggests not permanent:
If specified, the table is created as a temporary table. Temporary
tables are automatically dropped at the end of a session, or
optionally at the end of the current transaction (see ON COMMIT
below). Existing permanent tables with the same name are not visible
to the current session while the temporary table exists, unless they
are referenced with schema-qualified names. Any indexes created on a
temporary table are automatically temporary as well.
In particular temp tables are stored in diffrent (non-public) schema, e.g.:
=> Create Temporary Table someTempTable (value integer);
CREATE TABLE
=> \dt someTempTable
List of relations
Schema | Name | Type | Owner
-----------+---------------+-------+----------
pg_temp_2 | sometemptable | table | postgres
(1 row)
PostgreSQL doesn't have IF NOT EXISTS like in MySQL's CREATE TABLE, so you can't use it. If you want to create some table you need to firstly drop existing one (if it exists). Fortunately you could use SQL command DROP TABLE IF EXISTS to handle this:
=> Drop Table If Exists someTempTable;
DROP TABLE
=> Drop Table If Exists someTempTable;
NOTICE: table "sometemptable" does not exist, skipping
DROP TABLE
What is the purpose of a temporary table like in the following statement? How is it different than a regular table?
CREATE TEMPORARY TABLE tmptable
SELECT A.* FROM batchinfo_2009 AS A, calibration_2009 AS B
WHERE A.reporttime LIKE '%2010%'
AND A.rowid = B.rowid;
Temp tables are kept only for the duration of your session with the sever. Once the connection's severed for any reason, the table's automatically dropped. They're also only visible to the current user, so multiple users can use the same temporary table name without conflict.
Temporary table ceases to exist when connection is closed. So, its purpose is for instance to hold temporary result set that has to be worked on, before it will be used.
Temporary tables are mostly used to store query results that need further processing, for instance if the result needs to be queried or refined again or is going to be used at different occasions by your application. Usually the data stored in a temporary database contains information from several regular tables (like in your example).
Temporary tables are deleted automatically when the current database session is terminated.
Support for temporary tables exists to allow procedural paradigms in a set-based 4GL, either because the coder has not switched their 3GL mindset to the new paradigm or to work around a performance or syntax issue (perceived or otherwise).