summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorOwen Jacobson <owen.jacobson@grimoire.ca>2013-01-22 17:11:40 -0500
committerOwen Jacobson <owen.jacobson@grimoire.ca>2013-01-22 17:11:40 -0500
commitb39842a64b5b7718f4523f2e5abcf1fb1bc3fd58 (patch)
treeb608e8c9bdc601f82a04e31fd2b104706f55c661
parent4a9e5931022d2375f8eaa9382d38b7da8426851a (diff)
Clearer outline for backups.
-rw-r--r--wiki/mysql/choose-something-else.md30
1 files changed, 20 insertions, 10 deletions
diff --git a/wiki/mysql/choose-something-else.md b/wiki/mysql/choose-something-else.md
index a951e57..3d043e3 100644
--- a/wiki/mysql/choose-something-else.md
+++ b/wiki/mysql/choose-something-else.md
@@ -62,16 +62,26 @@ familiar with other SQL implementations).
### Preserving Data
... against unexpected changes: like most disk-backed storage systems, MySQL
-is as reliable as the disks and filesystems its data lives on.
-
-... against loss: hoo boy. MySQL's default approach to
-[backups](http://dev.mysql.com/doc/refman/5.5/en/backup-methods.html) is to
-either dump data to SQL periodically (slow and an inefficient use of space,
-with little support for incremental backups) or to use binary logs (plus a
-base filesystem backup) for ongoing backups. (Binary logs are also the basis
-of MySQL's first-party replication system.) If neither of these are
-sufficient, you're left with purchasing [a backup tool from
-Oracle](http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_mysql_enterprise_backup).
+is as reliable as the disks and filesystems its data lives on. However, the
+implicit conversion rules that bite when storing data also bite when asking
+MySQL to modify data - my favourite example being a fat-fingered `UPDATE`
+query where a mistyped `=` (as `-`, off by a single key) caused 90% of the
+rows in the table to be affected, instead of one row, because of implicit
+string-to-integer conversions.
+
+... against loss: hoo boy. MySQL, out of the box, gives you two approachesœ to
+[backups](http://dev.mysql.com/doc/refman/5.5/en/backup-methods.html):
+
+* Dump to SQL with `mysqldump`: slow, relatively large backups, and
+ non-incremental, or
+* Archive binary logs: fragile, complex, over-configurable, and configured
+ badly by default. (Binary logging is also the basis of MySQL's replication
+ system.)
+
+If neither of these are sufficient, you're left with purchasing [a backup tool
+from
+Oracle](http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_mysql_enterprise_backup)
+or from one of the third-party MySQL vendors.
Like many of MySQL's features, the binary logging feature is
[too](http://dev.mysql.com/doc/refman/5.5/en/binary-log.html)