2017 was a long time ago in the life of InnoDB cluster. The product has evolved a lot in the time since. There is an updated set of slides at https://www.slideshare.net/lefred.descamps/mysql-innodb-cluster-and-group-replication-in-a-nutshell-handson-tutorial-148…
I am not sure exactly what the 'Mp' stands for but I am guessing it is the 'master primary' in the three node read/write split. The primary receives all the write (and some of the reads) tasks and then replication is used to send the new data to the two nodes handling read only traffic. The servers can hold several schemas which are created with the CREATE DATABASE or CREATE SCHEMA statement.
Thanks for the update link. I just reviewed it. The migration scenario is there is one master (mysql1) and one slave (mysql2), replicate asynchronous. Then introduce a new mysql3 instance, and create single instance cluster first, then add mysql4. Last it adds mysql2 into the newly created cluster. If I have a few instances of master/slave replication like mysql1 to mysql2, and each such instance holds a few schemas, so for example mysql1 holds (3) schemas, and replicate to mysql2, then mysql3 holds (5) schemas, and replicate to mysql4, and so on. What does cluster topology look like to achieve HA? Should all schemas be consolidated into each cluster instance first? Can you have one mysqld instance holds some R/W schemas and some R/O schemas?
The primary and the replicas all have the same schemas and data. The primary receives read/write traffic via MySQL Router and the replicas only answer read requests from clients (but get the updated information via async or semi-sync replication). In the case of the primary failing, InnoDB cluster will promote one of the replicas to the new primary. New server to the clusters will be provided a copy of the InnoDB table space via the Clone plug-in when they join the cluster. Please see https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-userguide.html