In SQL 2008 you're looking for minimum downtime vs no downtime in these cases unless you're willing to shell out a lot of money/time for a few seconds. This sounds like hopefully it's not too complex of an environment so you have several options.
How about SQL Mirroring? If your data isn't coming in too fast, it'll sync up and you can 'failover mirror' option. Also, it's a very easy rollback, you just hit failover mirror again and it'll fail right back to the old cluster. If you go with High Safety mode, all writes have to be hardened on the other side before committing, thus you will have some transactional delay while the mirror is up. The upside is that it's super fast to just fail over as the data is certainly up to date. High performance mode is available in Enterprise. Mirroring is much more simple than replication and requires a lot less configuration items/requirements. For example, in Replication, every replicated table must have a PK, this isn't required in Mirroring. You also have the option of a witness server which will help with it being transparent to the application.
Worst case, you can do log shipping with automated scripts to restore the tail of the log. You can take a log backup, restore, put the DB in read only mode, take another log backup, and restore again. Be sure to check your VLFS (DBCC LOGINFO;) because if you have hundreds upon hundreds, your log restores will be slow complicating things.
Ensure security matches on both sides. Are they different domains? Then you'll have different users you'll need to add to your DB as soon as they go live. SQL user? Copy the user and SID together. There's scripts to do this.
Prior to the failover, run a trace or profiler to see what apps are connecting from where. Make sure to account for them on the new cluster. This includes user security. Also run a trace or profiler looking for logins to the old server. Let the app owner know they are connecting to the wrong DB.
Whatever you do, make sure to test and stage the process multiple times and automate it to where it's a couple of key strokes. Test failure scenarios and go into this confident.
1) No. You have to restart MySQL and that means downtime.
2) To minimize the downtime you need an identical server which you can switch to and back. The procedure on high level:
you can build a passive master using percona-xtrabackup for example without downtime
Set up master-master replication
Upgrade the passive master to 5.6 and wait for it to catch up in replication
Switch active master to be the upgraded one (running 5.6)
Stop and rebuild the old master with the same process you did in step #1 but now from the new version (5.6)
Repeat the procedure to upgrade for 5.7
If you don't need it trash the passive master
Best Answer
In general I don't think it's possible to move a database without any downtime with MySQL standard tools.
However you can try to use mysqldump and mysqlbinlog to minimize "data loss": see section "Example: mysqldump + mysqlbinlog for Backup and Restore" in https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html