Fault tolerance for Database sharding and Database partitioning
Sharding is for write scaling.  And, yes, each shard has part of the data.  (It might have part of the biggest table.  Meanwhile, smaller tables might be manually kept in sync across the shards.  Or you might have other servers for other things.)
Replication (Master(s) + Replica(s)) has a complete copy of the data on each server.  One Master + one Replica provides some degree of HA, but the &quot;failover&quot; is likely to be manual.
Each shard could have a Replica for HA purposes.  Or you could use a cluster (InnoDB Cluster or Galera) for each shard.  That would give you a combination of read scaling, a little write scaling, and a lot of HA.
When using Master+Replica, all writes go to the Master.  &quot;Critical reads&quot; need to go to the Master, too.  Other reads can go to the Replica.  Since you can have an arbitrary number of replicas, reads can scale &quot;infinitely&quot;.  (Booking.com had over 100 replicas a few years ago; I don't know how many today.)
A cluster has at least 3 nodes.  It can be one Master and the rest as replicas, or it can be all Masters.  With 3 (or more) they can vote on what to do if one machine goes dark.  Then those in the majority continue running until you can fix the broken node.
Of course, if you put the Master and all its replicas (or all cluster nodes) in a single datacenter, you run the risk of a failure of all of them.  (Yes, DCs do go down.)
PARTITIONing is rarely of any use.  (I list 4 use cases here:  http://mysql.rjweb.org/doc.php/partitionmaint )
(Please switch from the term &quot;Slave&quot; to &quot;Replica&quot;.)