For your first question, it depend on how you are taking backup. If you are using mysqldump, then just pass “no create db” as its parameter. Before restoring, create your database and restore the sql file at destination. For more assurity, you can also check sql file should not contain the name of database in create table statement.
For your second question, some work around are mentioned below ::
Create a chain topology of A-B-C mysql. Replicate from A to B with same name. Create additional database with your desired name on B. Create triggers on this new database to absorb all the changes. Replicate B to C with replication filters.
Introduce a layer of tools like maxwell which can read the data from binary log of slave and write it on slave. You have to see how to avoid the database name in maxwell only.
The commands you have will completely restore to Server_2, only a specific database. There will be no other data restored. If that is what you want, then that is fine. You don’t need to specify --databases on the prepare/restore steps.
Easiest is to do a logical dump/restore with mydumper or mysqldump. Using xtrabackup to backup/restore a single database to an existing MySQL will require multiple steps and the use of InnoDB transportable tablespaces.
xtrabackup is the de-facto standard for hot physical backups of your entire MySQL database server supporting incremental backups, differential backups, streaming backups, compressed/encrypted backups, etc.
You can do exactly what you want with xtrabackup but if you are not familiar with all the steps and not familiar with InnoDB transportable tablespaces, it will be difficult for you to do. It is not a simple command to restore a single database using physical backups. This is not the fault of xtrabackup but the fault of InnoDB’s tablespace design.