It isn't possible with replication as has been correctly pointed out, since that's not how replication works, nor can it be configured to work that way. Replication either does or does not handle any given table (depending on configuration) but when replication does handle a given table, the data is replicated and replication depends on the rows in the tables starting out and remaining identical.
What I'm hearing you say is that you want some of the same schemas and tables on the 2nd server as exist on the master, but they will be populated via external means, and you want those tables to go away when they are dropped from the master.
Here is a high-level view of how this could be accomplished via automatic means using only things built-in to MySQL.
Obviously this is a dangerous operation if not carefully written since we're talking about the automated dropping of tables and databases, so... caveat lector.
- enable the event scheduler on the archive machine
- enable the federated storage engine on the archive machine
- within another schema you create solely for the purpose of this exercise, define 2
FEDERATED
tables that connect back to the master. One of these points to information_schema.tables and the other points to information_schema.schemata.
- write a stored procedure that selects from the archive machine's information_schema.schemata table, left join the federated schemata table on catalog_name, schema_name where schema_name not in ('mysql','information_schema','performance_schema','any','other','schemas','you want not','to be deleted','for sure')
- take values from the resulting rows, which will be all of the databases that exist on the local machine but not on the master... and, using dynamic sql, drop those databases from the archive machine.
- do the same thing with the information_schema.tables table, which will identify tables you can drop.
- use the event scheduler to automate the running of this stored procedure. Don't schedule it too often, perhaps only once a day, because selecting from the information_schema.tables table can be a resource-intensive operation. MySQL gathers stats when you do this that can be costly especially in terms of I/O.
I'm doing a fair amount of guessing here, but this is how I imagine that your model should look like. In a couple of tables I removed id columns to make it clearer, you may want to put them back in case the keys I have chosen is not stable enough:
CREATE TABLE `users` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(100),
`password` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE(`name`) -- questionable
);
insert into users(name, password) values ('bob', 'passwd');
CREATE TABLE `stock` (
stock_code varchar(100) COLLATE utf8_unicode_ci NOT NULL,
PRIMARY KEY (stock_code)
);
insert into stock(stock_code) values('AABC'), ('BBCC'), ('EEFF');
-- a user can have 0 or more stocks, a stock have 1 user
create table user_stock (
user_id int(10) unsigned NOT NULL,
stock_code varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`value` double DEFAULT NULL,
PRIMARY KEY (stock_code),
constraint fk1_user_stock foreign key (user_id)
references `users` (id)
on delete cascade
on update cascade,
constraint fk2_user_stock foreign key (stock_code)
references stock (stock_code)
on delete cascade
on update cascade
);
insert into user_stock(stock_code, value, user_id)
values('AABC', 10, 1), ('BBCC', 4.5, 1), ('EEFF', 7, 1);
CREATE TABLE `sector_a` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(100) CHARACTER SET utf8 DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE(name)
);
insert into sector_a(name) values('FOOD'), ('CAR'), ('BUILDING');
-- a stock can belong to 0 or more sectors, a sector can have 0 or more stocks
CREATE TABLE `stock_sector_a` (
stock_code varchar(100) COLLATE utf8_unicode_ci NOT NULL,
`sector_id` int(10) unsigned not NULL,
PRIMARY KEY (stock_code, sector_id),
constraint fk1_stock_sector_a foreign key (stock_code)
references stock (stock_code)
on delete cascade
on update cascade,
constraint fk2_stock_sector_a foreign key (sector_id)
references sector_a (id)
on delete cascade
on update cascade
);
insert into stock_sector_a(stock_code, sector_id)
values('AABC', 1), ('AABC', 2), ('AABC', 3), ('BBCC', 2), ('BBCC', 3);
MariaDB [test]> delete from stock where stock_code = 'AABC';
Query OK, 1 row affected (0.01 sec)
MariaDB [test]> select * from user_stock;
+---------+------------+-------+
| user_id | stock_code | value |
+---------+------------+-------+
| 1 | BBCC | 4.5 |
| 1 | EEFF | 7 |
+---------+------------+-------+
2 rows in set (0.00 sec)
MariaDB [test]> select * from stock_sector_a;
+------------+-----------+
| stock_code | sector_id |
+------------+-----------+
| BBCC | 2 |
| BBCC | 3 |
+------------+-----------+
2 rows in set (0.00 sec)
Best Answer
If you have this scenario
table_a
has an auto_increment fieldtable_b
andtable_c
have table structure identical totable_a
you can create a Stored Procedure and a MySQL event instead of a Trigger
For the sake of example, let's say
table_a
looks like this:Create a Stored Procedure on the Slave to Copy Data to
table_b
andtable_c
Then, schedule a MySQL Event on the Slave for the Stored Procedure to go off every 5 minutes starting 5 minutes after you create the event:
Don't forget to Add This to the Slave's /etc/my.cnf