|
Задавайте вопросы, мы ответим
Вы не зашли.
Планируем съехать с MySQL 5.1.52 на Percona XtraDB Cluster 5.5.30. Хочется переехать максимально безболезненно и с минимальным простоем, т.к. на текущем СУБД работает не малонагруженный сервис с 1000 запросов в секунду. Работает репликация, со слейва можем слить базу чтобы не останавливать мастер, но запустится ли репликация между MySQL и Percona? Больше всего интересует такой нюанс: в MySQL таблицы MyISAM, в Percona таких не бывает, будем делать InnoDB (XtraDB).
Какие могут возникнуть проблемы при таком переезде и как можно минимизировать простой мастера?
Неактивен
Репликация будет работать. Переход с MyISAM на XtraDB также возможен, если не используются fulltext индексы. В зависимости от того что именно делать, могут возникнуть любые проблемы, но заранее этого предсказать нельзя.
Неактивен
Полнотекстовые индексы отсутствуют.
Я представляю себе такой порядок действий.
1. Остановить slave MySQL и слить базы на Percona.
2. Стартовать репликацию на Percona в качестве slave с нужной позиции.
3. После того, как база на Percona будет синхронизирована, отключить master MySQL, СУБД Percona сделать master и подключить к нему клиентов.
По сути, простой сервиса будет только на третем шаге, но всё ли я учёл? 
Кстати, из-за отсутствия достаточного опыта, не могу быть уверенным в правильном выполнении второго шага. Позиция бинлога актуальна вроде как для master сервера. Есть ли возможность определить эту позицию на slave сервере? Или надо останавливать репликацию и брать позицию бинлога с мастера?
Неактивен
можно сделать бэкап на мастере с помощью percona backup, тогда бэкап будет актуальным и содержать позицию в бинлоге мастера
для вашей схемы используйте SHOW SLAVE STATUS, он покажет позицию в бинлоге мастера
Неактивен
rgbeast написал:
можно сделать бэкап на мастере с помощью percona backup, тогда бэкап будет актуальным и содержать позицию в бинлоге мастера
Но в таком случае, я так понимаю, надо останавливать мастер?
Неактивен
Neval написал:
Но в таком случае, я так понимаю, надо останавливать мастер?
Да, для MyISAM будет блокировка таблиц. Для Innodb это возможно транзакционно без остановки. Перенести слейв, как вы предложили, не проблема - просто заменить на нем бинарник MySQL на Percona и запустить. ALTER из MyISAM в Innodb можно сделать уже на перконе при остановленном треде слейва.
Неактивен
Никак нам не удаётся настроить синхронизацию...
На текущем MySQL мастере прописана переменная auto_increment_increment = 2, на Перконе почему-то значение из конфига игнорится и в сессии значение auto_increment_increment показывает 1, из-за чего данные рассинхронизированы.
Когда к перконе было подключено два слейва, то значение переменной auto_increment_increment в сессии было 3. Т.е. получается, что Перкона сам устанавливает значение auto_increment_increment равное количеству серверов в кластере. Можно ли это как-то обойти?
Неактивен
Обнаружили параметр wsrep_auto_increment_control, был включен. Выключили и вроде всё поднялось, будем далее мониторить.
Неактивен
rgbeast написал:
ALTER из MyISAM в Innodb можно сделать уже на перконе при остановленном треде слейва.
На MyISAM репликация успешно работала несколько дней, на днях сконвертировал таблицы в InnoDB, сегодня запустил репликацию и увидел, что она жутко отстаёт. Отстаёт таки сильно, вот выявил запросы, выполнившиеся на мастере в течение 3х минут, а на слейве они выполнялись в течение 13ти. С такими темпами у меня бинлог на мастере скоро перестанет быть актуальным...
Seconds_Behind_Master 90278
и постоянно растёт.
Подскажите куда копнуть? Могут ли индексы таблиц на это повлиять так сильно или стоит пересмотреть какие-то конфиги?
Неактивен
Увеличил на слейве такие параметры:
innodb_buffer_pool_size
innodb_log_file_size
Увеличивал до тех пор, пока не ощутил разницы в значениях. Отставание стало меньше, но всё же есть небольшое. Какие ещё параметры стоит поковырять? Пробовал использовать innodb_flush_method=O_DIRECT и skip-innodb-doublewrite, разницы не увидел.
Нагуглил параметры innodb_additional_mem_pool_size и innodb_thread_concurrency, но их в конфиге нет и в переменных состояния их не нашёл, потому не знаю сколько есть сейчас и на сколько можно увеличивать.
Неактивен
Попробуйте посмотреть на сами запросы. См. также ботанический определитель
Неактивен
Спасибо, занятная презентация, очень давно её не смотрел В моём случае проблема решилась путём выставления параметра innodb_flush_log_at_trx_commit в 0, было значение 1.
Неактивен
