The main consideration for zero (or close to) downtime is the amount of update activity. Updates (and deletes) conflict in ways that inserts don't.
Level 1. Database is pretty much totally read only (eg used for a Content Management System). This is the easiest to replicate.
Level 2. Only Inserts on a single node which get distributed to other 'read-only' nodes.
Level 3. Only inserts sharded (eg one node takes updates for America, another for Europe, a third for Asia...).
Level 4. Inserts/Updates/Deletes on a single node which get distributed to other 'read-only' nodes.
Level 5. Inserts/Updates/Deletes sharded (eg one node takes updates for America, another for Europe, a third for Asia...).
Level 6. Inserts on multiple nodes distributed to all other nodes.
Level 7. Inserts/Updates/Deletes on multiple nodes distributed to all other nodes.
At level 6/7 I'd be looking into NoSQL solutions. Maybe level 3 and 5 if I though the sharding mechanism might not be sustainable for longer timeframes.
Level 7 is practically impossible to achieve high nines availability. Ultimately you'll get person A trying to update stuff on node 1 at exactly the same time as person B is updating it on node 2....and then you'll lose node 1.