Как правильно сделать резервную копию базы данных mediawiki (mysql), не испортив данные?

Я хочу сделать резервную копию базы данных mediawiki, хранящейся на сервере MySQL 5.1.36, с помощью mysqldump.

Большинство вики-статей написаны на испанском языке, и мы не хотим с этим связываться, создавая дамп с неправильным набором символов.

mysql> status
--------------
...
Current database:       wikidb
Current user:           root@localhost
...
Server version:         5.1.36-community-log MySQL Community Server (GPL)
....
Server characterset:    latin1
Db     characterset:    utf8
Client characterset:    latin1
Conn.  characterset:    latin1
...

Используя следующую команду:

mysql> show create table text;

Я вижу, что оператор создания таблицы устанавливает кодировку на двоичный:

CREATE TABLE `text` (
  `old_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `old_text` mediumblob NOT NULL,
  `old_flags` tinyblob NOT NULL,
  PRIMARY KEY (`old_id`)
) ENGINE=InnoDB AUTO_INCREMENT=317 DEFAULT CHARSET=binary MAX_ROWS=10000000 AVG_ROW_LENGTH=10240

Как мне использовать mysqldump для правильного создания резервной копии этой базы данных?

mysqldump и show create table обычно являются довольно надежными рабочими лошадками и не должны изменять кодировку самостоятельно. Если они используют «двоичный» набор символов, скорее всего, это действительно набор символов, данный таблице (не обязательно столбцы, хотя). Можете ли вы повторно проверить текущий набор символов таблицы в браузере базы данных?

Я бы попробовал простой, простой mysqldump в файл, восстанавливая дамп в зеркальной базе данных, и внимательно посмотрите на специальные символы. По моему опыту, в отличие от резервных копий, созданных с помощью phpMyAdmin, резервные копии из командной строки, как правило, работают очень хорошо.

Если вы не хотите останавливать сервер для резервного копирования, я настоятельно рекомендую вам взглянуть на Xtrabackup. Этот инструмент выполняет оперативное резервное копирование таблиц InnoDB (и XtraDB). Я использую его на своих производственных серверах. Он не слишком нагружает их и может выполнять инкрементное резервное копирование.

Резервное копирование базы данных - жизненно важная вещь, так что браво, чтобы добраться до нее.

Я рекомендую протестировать вашу стратегию резервного копирования не только из-за беспокойства по поводу языка, но и потому, что одним из наиболее часто повторяющихся печально известных сценариев наихудшего бедствия для очень многих организаций является резервное копирование, которое никогда не тестировалось и в течение многих лет выполнялось неправильно - и не работала, когда в конце концов понадобилась. Следует протестировать ВСЕ процесс резервного копирования.

Во-первых, остановите всю активность сервера и сделайте резервную копию операционной системы. Это никогда не бывает плохой идеей, за исключением времени простоя из-за отключения сервера. Некоторые системы баз данных позволяют выполнять резервное копирование ОС во время работы системы баз данных и по-прежнему создавать совершенно корректную резервную копию! PostgreSQL - такая система - я ее очень рекомендую.

Что касается наборов символов, Unicode (также известный как UTF-8) содержит весь испанский язык, но широко используется ISO-8859-1.

См. Эти ссылки:

Символы Unicode и Консорциум Unicode и я подумал, что это тоже может быть полезно: Набор символов MySQL для ISO-8859-1

Я также рекомендую выполнить вторую установку и восстановить в нее резервную копию. Это делает три вещи:

Это помогает убедиться, что сам процесс резервного копирования работает правильно.
Он предоставляет место для тестирования с реальными данными, и;
Он обеспечивает своего рода дополнительную «резервную копию», требующую меньших накладных расходов, чем полное восстановление - это может оказаться полезным в разное время по разным причинам.