I have a table in my MySQL for which I want to create a replica in some other database on the same MySQL instance with a different table name.
For eg
I have two database X and Y.
X contains a table by the name of A. Direct insertions takes place in this table only.
Y database will contain a table by the name of B which will contain the same data as of A.
MySQL version - 5.6
I have explored the options for copy of data. But this will not happen at runtime. I want a structure something like as soon as an insertion or updation takes place in table A, same data gets copied/updated to table B.
I also explored the option for the master-slave concept, in which it provides the copy to some other server. However, for this, a separate DB is needed but I want to be in the same DB instance.
I have no idea as to such a feature exists or not, or do I need to create such thing manually via code, or I have missed something in the above two ways which they can be modified and get the required result.
Can anyone please guide/help me with this problem? Thank you in advance.
Related
I have basic knowledge of MS SQL which actually sabotages me as the syntax differs from MySQL in which I need the code written.
I have X databases named "project_%". It's 1 database per project. I need a script or a procedure (it's gonna be rarely used by support) that's gonna take some user info from master DB and add a list of users (or at least a single user) into all (later a list might be required) "project_%" databases.
My idea was to create a variable/temp table to fill with the list of databases and run a cycle (for/while) to set a default schema and insert required data. This is where I'm stuck as I have no idea how to set default schema from a variable or to input the variable into variable_db.table.
What I've found so far always differed from what I needed and couldn't apply it to my code.
Thanks,
Z
I have access to a remote database, and I would like to dump the schema and data of several views onto my local machine and load this into my local database as tables in a quick and easy way.
I lack the user privileges to run CREATE TABLE AS (SELECT * FROM target_view), otherwise this would be trivial to solve. In other words, I want to retrieve and recreate the "composite" schema of target_view as if it were a table.
I do not want the output of SHOW CREATE VIEW, as this only shows a complex SELECT statement with joins to various tables on remote I have limited ability to access. And a problem I'm seeing in MySQL 8.x is when I run SHOW CREATE TABLE on the view, this command simply acts as an alias of SHOW CREATE VIEW (which is reasonable).
Frustratingly, I can run DESCRIBE and see the schema of these views as they were tables. I really just need to convert this information into a CREATE TABLE statement without actually being able to run CREATE TABLE.
In case it weren't obvious, the key is to avoid manual reconstruction of these views' tabular schemas (as they may change in the future). I also want to avoid the solution of reverse engineering a generic table construction of 20-30 generic VARCHAR or TEXT columns from a CSV dump.
I don't know of any way to display the metadata of a result set in CREATE TABLE syntax.
What I would do given your circumstance is first create on your local MySQL instance the base table and the view, then you can use the CREATE TABLE AS SELECT ... syntax to produce a concrete table to match the metadata of the view result set.
When you dump the database 'A' using mysqldump and imported into 'A_test', would they be two independent copies of the same database? Or changes to one of them would also affect the other one?
No, they become two different identical database, and changes on one does not reflects on the other, after the dump and import procedure.
If you create any data in database B, then it is completely independent of database A. As far as I know, there is no way to connect tables of different databases in any way.
if you want to make sure nothing bad happens,
create a user B that only has access rights to database B.
Use user B to import the database into B.
Use user B to access database B from your app.
User B cannot change anything belonging to database A.
(you always should create user/database pairs with the same name)
You have two independent databases. Database 'A' AND you also have database 'A_test'. And quires made to one will not affect the other unless you reference both in the query itself. I.E. if you add an entry to 'A', it will not also be added to 'A_Test' unless you also add it to 'A_Test'.
I am looking for a solution to the following:
Database: A
Table: InvoiceLines
Database: B
Table: MyLog
Every time lines are added to InvoiceLines in database A, I want to run a query that updates the table MyLog in database B. And I want it instantly.
Normally I would create a trigger in database A on INSERT in InvoiceLines. The problem is that database A belongs to a ERP program where I don't want to make any changes at all (updates, unknown functionality in 3-layer program, etc)
Any hints to help me in the right direction...?
You can use transactional replication to send changes from your table in database A to a copy in DB B, then create your triggers on the copy. It's not "instant," but it's usually considered "near real time."
You might be able to use DB mirroring to do this somehow, but you'd have to do some testing to see if you could get it to work right (maybe set up triggers in the mirror that don't exist in the original?)
One possible solution to replicate trigger's functionality without database update is to poll the table by an external application (i.e. java) which on finding new insert would fire required query.
In SQLServer2008, something similar can be done via C# assembly but again this needs to be installed which requires database update.
I got a case where I have several databases running on the same server. There's one database for each client (company1, company2 etc). The structure of each of these databases should be identical with the same tables etc, but the data contained in each db will be different.
What I want to do is keep a master db that will contain no data, but manage the structure of all the other databases, meaning if I add, remove or alter any tables in the master db the changes will also be mirrored out to the other databases.
Example: If a table named Table1 is created in the master DB, the other databases (company1, company2 etc) will also get a table1.
Currently it is done by a script that monitors the database logs for changes made to the master database and running the same queries on each of the other databases. Looked into database replication, but from what I understand this will also bring along the data from the master database, which is not an option in this case.
Can I use some kind of logic against database schemas to do it?
So basicly what I'm asking here is:
How do I make this sync happen in the best possible way? Should I use a script monitoring the logs for changes or some other method?
How do I avoid existing data getting corrupted if a table is altered? (data getting removed if a table is dropped is okay)
Is syncing from a master database considered a good way to do what I wish (having an easy maintainable structure across several datbases)?
How will making updates like this affect the performance of the databases?
Hope my question was clear and that this is not a duplicate of some other thread. If more information and/or a better explantion of my problem is needed, let me know:)
You can get the list of tables for a given schema using:
select TABLE_NAME from information_schema.tables where TABLE_SCHEMA='<master table name>';
Use this list for a script or stored procedure ala:
create database if not exists <name>;
use <name>;
for each ( table_name in list )
create table if not exists <name>.table_name like <master_table>.table_name;
Now that Im thinking about it you might be able to put a trigger on the 'information_schema.tables' db that would call the 'create/maintain' script. Look for inserts and react accordingly.