Fault tolerance in mysql servers
What is likely to break?
How risk-adverse are you?
Do you need to repair the failure, or just discover it?


A "parity" check can only discover failure, hence it is not fault-tolerant.

Many people decide that the main failure point is the disk subsystem, so they use RAID.  In that context, you can assume that parity is can be used to repair -- but only because there is some other mechanism to say "this drive failed".

But what if the motherboard dies?

So you use Replication and Master-Slave with the two servers sitting next to each other.

But what if the power to the building goes out?  Or a tornado hits the two servers?  Or ...

So you put the Slave in another data center.

(I could continue this silly story, but I won't.)

You can put two "instances" of MySQL on the same server, then have one replicate to the other.  Then put a lot of spin on how great your solution is.  (Never mind that practically any failure will take out both copies.)

Or you could spend a few bucks and rent Amazon space for the other server.  Then you can honestly brag about the "fault-tolerance".

After Bounty Edit

Use Engine=InnoDB; this gives you simpler recover from server crash.

After loading the data, take a dump (mysqldump or other) of the static table, and store it elsewhere.  This is for "disaster recovery" from floods, meteorites, software glitches, disk failure, etc.  Reloading would be manual and take some time (but you have not put limits on that).

Those are simple measures, and effectively cover virtually all disasters.  If I were to list other things that can go wrong with a mysql setup, "parity" does not show up as a part of any solution.

To finish the task you have, set up your disk with RAID-5.  Three drives is the minimum.  You could probably fake it with software raid and partitions of a single drive.  However, this would make useless for recovering from any kind of failure; instead it would show the use of "parity".

"Checksums" are more often used for catching (but not correcting) errors.  This is typically 4-8 bytes overhead for 512-16KB bytes of data.  That is not, technically, "parity", but it is more efficient.

One parity bit per byte gives you error detection, but not error correction.  See SECDED for correction.  That needs, for example, 8 bits on a 64-bit 'word'.  Seymour Cray said "parity is for farmers", but eventually he implemented SECDED in 'core' memories.  (This was in the '70s.  Does your prof date back that far?)