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.