Fault tolerance in mysql servers

I have built an application as part of my UG thesis that uses mysql database (community edition). Now, my professor wants me to provide fault-tolerance to the database (by parity!!)! I argued that we wouldn't need that. Anyway I searched, and found here that mysql has built-in replication engine (a mechanism to provide fault-tolerance, right?), along with many other techniques to provide reliability. But what I learned from there is that there is a master server and some slave servers to provide the fault tolerance using replication. Now my questions are:

-
What if I have only one database server? Does mysql have any fault-tolerance for single standalone database servers (i.e. no master-slave formation, no cluster, etc.)?

-
Do I need to try to provide any kind of fault-tolerance whatsoever for the data stored in mysql database?

-
What kind of differences are there (in terms of fault-tolerance only) between community edition and enterprise edition of mysql servers?

Somehow I get the feeling that we don't need to do anything for providing fault-tolerance to mysql db, and it is fine by itself. But I need some solid info on the matter.

Bounty edit:

The second question from above again:

-
Do I need to try and provide any kind of fault-tolerance whatsoever for the data stored in mysql database?

-
What is the sensibleness of trying to provide fault tolerance to a mysql database by using parity (bit per byte)?

A little details about the data in the database:

The data to be specific is a collection of about 6500 Unicode strings, less than 1 MB in size, is initialization data, that will never change over time. The only transaction will be to read the data from the database, no update no delete. My application requires full-text search on those strings, and this is the only reason I am using mysql since it provides full-text search. I am aware that I could avoid mysql's FT search by using something like elasticsearch instead.

• 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?)

StackExchange Database Administrators Q#129827, answer score: 4