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.
Related
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).
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).
Is it possible to replicate a single table?
Yes this is possible. Have a look at the slave options of the MySQL manual. This still requires to create a complete binlog of the whole database though.
To sync specific tables again to one or more slaves rather use
pt-table-checksum
and then
pt-table-sync
That should automatically identify the out-of-sync tables and only sync those.
CREATE TABLE new_table_name
SELECT *
FROM original_table_name;
Use "*" if you want to select all columns from the original table, otherwise give specific columns name.
This will replicate table within same database.
I know this is an old question but this is for anyone who comes here looking for an answer:
CREATE TABLE table2 LIKE table1;
This will create a table with the same format and columns but no data. To transfer the data use:
INSERT INTO table2 SELECT * FROM table1;
EDIT:
It is important to note that this is an information transfer only. Meaning if you had indexes on table1 they are not transferred to table2. You will have to manually index table2
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
Is there any way to create triggers on different databases? my requirement is like:-
database: a1.db consist table: t1
database:a2.db consist table: t2
now i have to use trigger on t1 (whenever any delete and update operation) happens on t1 a value has to be inserted into t2.
waiting for your feedback...
I can only speak for MySQL, but you should be able to do something like:
CREATE TRIGGER ad_t1 AFTER DELETE ON `a1.db`.t1
FOR EACH ROW
INSERT INTO `a2.db`.t2 VALUES (...)
What are the other databases you are using besides mysql? If Oracle is one of them, then you can create dblinks from Oracle to the other databases, and your trigger (running on Oracle) could use those dblinks to update the tables in the other databases.
You can refer to this link for info on creating dblinks in Oracle:
http://download.oracle.com/docs/cd/B12037_01/server.101/b10759/statements_5005.htm
Also, see this link (How to create a DB link between two oracle instances) for another answer on stackoverflow.
Looks like you need the MySQL equivalent of link servers (MSSQL) or dblink (Oracle). There is something called the FEDERATE storage engine:
Check here