2010-06-15 3 views
2

Что я могу сделать, чтобы гарантировать, что репликация будет использовать latin1 вместо utf-8?charsets в репликации MySQL

Я перемещаюсь между сервером MySQL 5.1.22 (master) в системе Linux и сервером MySQL 5.1.42 (подчиненный) в системе FreeBSD. Моя репликация работает хорошо, но когда символы не-ascii находятся в моих varchars, они становятся «странными». Linux/MySQL-5.1.22 показывает следующий набор символов переменных:

character_set_client=latin1 
character_set_connection=latin1 
character_set_database=latin1 
character_set_filesystem=binary 
character_set_results=latin1 
character_set_server=latin1 
character_set_system=utf8 
character_sets_dir=/usr/share/mysql/charsets/ 
collation_connection=latin1_swedish_ci 
collation_database=latin1_swedish_ci 
collation_server=latin1_swedish_ci 

Хотя FreeBSD показывает

character_set_client=utf8 
character_set_connection=utf8 
character_set_database=utf8 
character_set_filesystem=binary 
character_set_results=utf8 
character_set_server=utf8 
character_set_system=utf8 
character_sets_dir=/usr/local/share/mysql/charsets/ 
collation_connection=utf8_general_ci 
collation_database=utf8_general_ci 
collation_server=utf8_general_ci 

Установки любые из этих переменных из MySQL CLI не имеет никакого эффекта, и устанавливать их в my.cnf или в командной строке заставляет сервер не запускаться.

Конечно, оба сервера имеют соответствующие таблицы, созданные таким же образом, в этом случае с DEFAULT CHARSET = latin1. Позвольте мне дать вам пример:

CREATE TABLE `test` (
    `test` varchar(5) DEFAULT NULL 
) ENGINE=MyISAM DEFAULT CHARSET=latin1 

Когда я на хозяина этого, в терминале Latin1, «INSERT INTO тест VALUES („æøå“)», это становится на подчиненном, когда я выбираю его из Latin1 на базе терминала

+--------+ 
| test | 
+--------+ 
| æøå | 
+--------+ 

на основе терминала UTF-8 на подчиненном репликации, тест содержит:

+--------+ 
| test | 
+--------+ 
| æøå | 
+--------+ 

Так что мой вывод заключается в том, что она превращается в utf8, хотя определение таблицы латино 1. Это правильный вывод?

Конечно, на хозяина, в latin1 терминале, он по-прежнему говорит:

+------+ 
| test | 
+------+ 
| æøå | 
+------+ 

Поскольку оба набора системы символов являются UTF-8, если установить оба терминала в UTF-8 и сделать снова " INSERT INTO тест VALUES («æøå»)»на хозяина с терминалом UTF-8, на ведомом с UTF-8 я получаю:

+------------+ 
| test  | 
+------------+ 
| æøà | 
+------------+ 

Если мой вывод правилен, все мои копируемые данные преобразуются в utf8 (если это utf8, он рассматривается как latin1 и преобразован в utf8), тогда как все старые данные в таблице, как CRE ATE TABLE предлагает, latin1. Я бы хотел преобразовать все это в utf-8, если бы не тот факт, что устаревшие приложения полагаются на то, что он является latin1, поэтому мне нужно сохранить его в latin1, пока они все еще существуют.

Что я могу сделать, чтобы репликация читала latin1, рассматривает ее как latin1 и записывает ее на подчиненный как latin1?

Приветствие

Nik

ответ

0

В общем, вы должны использовать один и тот же конфигурационный файл и версию MySQL на подчиненном (за исключением обновлений/сценарии миграции, а также несколько вещей, которые должны быть различными ведомые, такие как server_id).

Вы захотите выполнить сценарий настройки базы данных, чтобы ваши серверы БД были частью развертывания вашего программного обеспечения. Очень важно, чтобы все серверы баз данных, в том числе в непроизводственных средах, использовали ту же конфигурацию.

Невозможность синхронизации конфигураций приведет к непредвиденным ошибкам.

Я не знаю, почему вы чувствуете необходимость запуска разных ОС на разных серверах, но если вы сделаете это, вы сделаете жизнь более сложной для вашего персонала Ops.

1

Репликация между серверами, где глобальные параметры character_set_% и collation% разные, не поддерживается.

http://dev.mysql.com/doc/refman/5.6/en/replication-features-charset.html

-- on both servers check the output of... 
SHOW VARIABLES LIKE 'char%'; 
SHOW VARIABLES LIKE 'collat%'; 

может не только репликацию потерпеть неудачу, если наборы & сортировки различны, но это может привести к разному роду приказы и потеря символов при конверсионных наборах/сортировке. порядок сортировки может влиять на такие вещи, как вставка/обновление, если используется репликация на основе выражений.

вам лучше настроить новый сервер на использование тех же наборов и сопоставлений, что и старый сервер. это обеспечит правильную работу репликации. вы также захотите убедиться, что базы данных, таблицы и столбцы имеют одинаковые сопоставления между master и slave. как только вы перейдете на новый сервер, вы можете изменить набор настроек & с помощью инструментов, таких как изменение схемы онлайн 5.6 или pt-online-schema-change из набора инструментов percona.

Я также рекомендую запускать контрольную сумму pt-table percona, чтобы убедиться, что ваши таблицы не расходились во время репликации или первоначального экспорта/импорта.

посмотреть здесь для получения дополнительной информации о влиянии различий:

всем, кто использует Amazon RDS, имейте в виду, что настройки mysql 5.6 по умолчанию используют смешанные utf8 (mb3) и latin1 (для сервера и базы данных). вы должны переопределить тех, у кого есть группа настраиваемых параметров, если репликация из не-RDS в/из RDS (соответствующие исходным/целевым серверам).

Смежные вопросы