Доброго времени суток, aLL.Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются дампы mysqldump'ом. Вертится на сервере ПО на PHP.
Простой перенос mysqldump'ом не подходит, ибо разворачивается новая база более 8 часов. Данный простой неприемлем.
В связи с этим возникла мысль: можно ли, например, будущий основной сервер сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый сервер и "поднять" новый slave до мастера?
Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое железо с минимальным простоем?
> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:рассказываю, наймите одмина, за деньги,
или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то мигрировать будет?
> рассказываю, наймите одмина, за деньги,
> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
> мигрировать будет?Откуда столько агрессии, уважаемый?
Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. Для этого форумы и созданы - делиться знаниями.
>> рассказываю, наймите одмина, за деньги,
>> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
>> мигрировать будет?
> Откуда столько агрессии, уважаемый?
> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
> Для этого форумы и созданы - делиться знаниями.Для этого деньги и созданы - получать необходимые услуги с требуемым качеством.
>>> рассказываю, наймите одмина, за деньги,
>>> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
>>> мигрировать будет?
>> Откуда столько агрессии, уважаемый?
>> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
>> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
>> Для этого форумы и созданы - делиться знаниями.
> Для этого деньги и созданы - получать необходимые услуги с требуемым качеством.Если у вас 50ГБ разворачивается 8 часов, то:
1) не хватает CPU
2) мало ОЗУ
3) не SSD диски
4) отсутствует тюнинг Mysql и системы
5) не пробовали альтернативные форки Mysql.
> Если у вас 50ГБ разворачивается 8 часов, то:
> 1) не хватает CPU
> 2) мало ОЗУ
> 3) не SSD диски
> 4) отсутствует тюнинг Mysql и системы
> 5) не пробовали альтернативные форки Mysql.N+1) возможнo бюджетный V{D,P}S хостинг ?
Спасибо за ответ.> Если у вас 50ГБ разворачивается 8 часов, то:
Согласен, долго. На новоустановленном сервере поменьше - 5 с копейками часов. Но это тоже много.
> 1) не хватает CPU
> 2) мало ОЗУ
> 3) не SSD дискиhp dl180g6 (2 x Xeon 5645 2.4 Ггц , 48 Gb RAM, raid 60 из 10 дисков 15к sas). Сейчас это все в proxmox окружении, 90% ресурсов которого выделено именно под контейнер с базой. Новый сервер аналогичный по железу, разве что памяти гиг на 8 больше будет и чистый дебиан, только под базу.
> 4) отсутствует тюнинг Mysql и системы
Да, весь тюнинг в общем-то - рекомендации скрипта mysqltuner'a и некоторые "игры" с опция самостоятельно. Пока еще нет достаточного опыта у меня.
> 5) не пробовали альтернативные форки Mysql.
Не пробовали. Но тут разработчики "правят бал".
Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера.> hp dl180g6 (2 x Xeon 5645 2.4 Ггц , 48 Gb RAM,
> raid 60 из 10 дисков 15к sas). Сейчас это все в
> proxmox окружении, 90% ресурсов которого выделено именно под контейнер с базой.
> Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера.Спасибо за ответ.
Как раз хочу "соскочить" с proxmox в контексте БД, по крайней мере для мастер-сервера. Почему:
- странные, абсолютно бессистемные просадки производительности БД. Порой довольно ощутимые. Это не влияние загрузки БД, не влияние соседних контейнеров, не железо хоста, не дисковые операции, не софт. Не выявил никакой последовательности. Нечасто возникают, но таки есть. Причем такие одинаковые "просадки" возникают на двух разных серверах proxmox, в которых разные БД, с разным размером и разной загрузкой. Так что подозрение на openvz контейнеры (и там и там версия proxmox'a, а, равно, openvz одинаковая).
- openvz не поддерживает audit, а сие нужно.
- в новых версиях proxmox таки уже lxc. Не тестировал данную виртуализацию и как-то начинать знакомство с критически важных задач не хочется...
...
> Откуда столько агрессии, уважаемый?
> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
> Для этого форумы и созданы - делиться знаниями.- поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
- делается snapshot VM
- проигрываются различные сценарии переноса/миграции/etc
- выбирается лучший и т.д.
> ...
>> Откуда столько агрессии, уважаемый?
>> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
>> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
>> Для этого форумы и созданы - делиться знаниями.
> - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
> - делается snapshot VM
> - проигрываются различные сценарии переноса/миграции/etc
> - выбирается лучший и т.д.Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может привести к деградации работы соседних VM. В итоге приведет к suspend проблемной VM :)
> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может
> привести к деградации работы соседних VM. В итоге приведет к suspend
> проблемной VM :)угу, см. 5 выше
> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может
> привести к деградации работы соседних VM. В итоге приведет к suspend
> проблемной VM :)Есть такой момент, иногда простреливает. Оно, конечно, на данном хосте еще пара "легких" контейнеров работает, почти все ресурсы под контейнер с базой отданы, но тем не менее...
И, да, долгие очень игры получаются.
Спасибо за ответ.> - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
> - делается snapshot VM
> - проигрываются различные сценарии переноса/миграции/etc
> - выбирается лучший и т.д.Чтобы все это сделать нужно понимать что и как вообще. Это все - БДшные дела - все висит на мне. А я никогда до этого администрированием БД не занимался. Опыта совсем 0. Вообще.
И, как всегда, нет времени на разобраться нормально, "поиграться и поизучать".
Предложенный мной вариант в принципе реализуем? Или же я неправ? Проблемы со стороны софта могут какие-либо быть?
> В связи с этим возникла мысль: можно ли, например, будущий основной сервер
> сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый
> сервер и "поднять" новый slave до мастера?
> Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое
> железо с минимальным простоем?Да, можно.
Именно так и делается.
> Да, можно.
> Именно так и делается.Спасибо за ответ.
> В связи с этим возникла мысль: можно ли, например, будущий основной сервер
> сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый
> сервер и "поднять" новый slave до мастера?
> Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое
> железо с минимальным простоем?50Гб ? Фигня.
Через rsync копируешь файлы БД наживую. Это будет "первичный прогон".
Затем гасишь БД, повторяешь rsync. Он пройдет гораздо быстрее, перегоняться будут только изменившиеся данные, но все 50 Гб конечно должны будут быть вычитаны с диска.
Запускаешь БД на втором сервере. Всё.
Время простоя можешь оценить повторным "грязным прогоном".
> Через rsync копируешь файлы БД наживую. Это будет "первичный прогон".Профит будет только при включенном innodb_file_per_table, имхо. А если у него все данные в ibdata1. Хотя в любом случае, rsync будет побыстрее полного восстановления.
Ну и как уже говорили, вариант с добавлением временного слейва вполне рабочий.
> А если у него все данные в ibdata1.То это будет просто праздник, поскольку можно тупо скопировать сами файлики.
А это сильно быстрее чем все дампы, репликации и синхронизации. Будет простой, но это минуты какие-то.
> Доброго времени суток, aLL.
> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
> необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и
> новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются
> дампы mysqldump'ом. Вертится на сервере ПО на PHP.Percona XtraBackup
>> Доброго времени суток, aLL.
>> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
>> необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и
>> новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются
>> дампы mysqldump'ом. Вертится на сервере ПО на PHP.
> Percona XtraBackupа она научилась вытягивать отдельную базу? Раньше не умела, т.е. если у тебя 10 баз, каждая по 20-50 Гб, то тянуть придется все
Всем спасибо за ответы, картина стала более-менее ясна.
Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с rsync'ом, честно говоря, с самого начала пришел на ум, да только таки все действительно в одном файле ibdata1 плюс есть сомнения в таком копировании - все ли потом будет ок?
> Всем спасибо за ответы, картина стала более-менее ясна.
> Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с
> rsync'ом, честно говоря, с самого начала пришел на ум, да только
> таки все действительно в одном файле ibdata1 плюс есть сомнения в
> таком копировании - все ли потом будет ок?чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.Проблем после копирования не будет. (Если вы конечно архитектуру и битность при переносе между хостами не меняете, за такие ситуации я не уверен).
При обновлении версии MySQL происходит то же самое:
-гасим СУБД
-устанавливаем бинарники/библиотеки новой версии
-запускаем СУБД.Она возьмет файлы, созданные предыдущей версией и будет с ними работать.
Какая разница СУБД, на каком хосте их открыть?По такой схеме делают также бэкапы с LVM-снепшотами.
Ну и кроме того, вы всегда можете попробовать. Погасили основной инстанс, сделали рсинк копию, подняли основной инстанс и работаете с ним, а также тестируете второй инстанс.
> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
> То, что всё в одном файле - не важно, rsync умеет перегонять
> только изменившиеся блоки.Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно давать ему ключи --inplace и --backup. Обычного [для меня, да] -av --progress не достаточно.
> То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.вы уверены? Я вот попробовал
$ cd /src/
$ dd if=/dev/urandom of=1gb.bin bs=1M count=1024
$ cp 1gb.bin /dst/Меняю пару байт в /dst/1gb.bin и запускаю rsync
$ rsync -v -z -r --inplace --progress /src/ /dst/
sending incremental file list
1gb.bin
1,073,741,824 100% 22.69MB/s 0:00:45 (xfr#1, to-chk=0/2)sent 1,074,353,354 bytes received 35 bytes 23,612,162.40 bytes/sec
total size is 1,073,741,824 speedup is 1.00
Я что то упускаю?
>>> То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.
> вы уверены?Нет не уверен и не пробовал, поэтому м написал:
#>> полистал man
#>>Видимо, умеет,
> Нет не уверен и не пробовал, поэтому м написал:
> #>> полистал man
> #>>Видимо, умеет,вообще то я отвечал PavelR ;)
>> То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.
> вы уверены? Я вот попробовал
> Меняю пару байт в /dst/1gb.bin и запускаю rsync
> Я что то упускаю?Вероятно сказывается, что с обеих сторон - файловая система.
У меня в таком случае тоже происходит полное копирование файла.Однако с использованием SSH всё иначе.
Результат прогрева процессора:
Создаем
root@localhost:~/tst# dd if=/dev/zero of=src/1gb.bin bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 13.3356 s, 80.5 MB/sКопируем
root@localhost:~/tst# time rsync -av -e "ssh -c blowfish" root@localhost:/root/tst/src/ dst/
root@localhost's password:
receiving incremental file list
1gb.binsent 36 bytes received 1073872988 bytes 11128217.87 bytes/sec
total size is 1073741824 speedup is 1.00real 1m35.158s
user 0m18.905s
sys 0m16.417sМодифицируем
root@localhost:~/tst# dd if=/dev/urandom of=src/1gb.bin bs=512 count=1 oflag=append conv=notrunc
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000118674 s, 4.3 MB/s
Копируем еще раз:root@localhost:~/tst# time rsync --inplace -av -e "ssh -c blowfish" root@localhost:/root/tst/src/ dst/
root@localhost's password:
receiving incremental file list
./
1gb.binsent 229409 bytes received 131683 bytes 9141.57 bytes/sec
total size is 1073742336 speedup is 2973.60real 0m38.477s
user 0m5.692s
sys 0m3.812sКонтрольный:
root@localhost:~/tst# time rsync --inplace -av -e "ssh -c blowfish" root@localhost:/root/tst/src/ dst/
root@localhost's password:
receiving incremental file listsent 11 bytes received 53 bytes 18.29 bytes/sec
total size is 1073742336 speedup is 16777224.00real 0m2.544s
user 0m0.000s
sys 0m0.012sroot@localhost:~/tst# dd if=/dev/urandom of=src/1gb.bin bs=512 count=1 oflag=append conv=notrunc
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00931802 s, 54.9 kB/s
root@localhost:~/tst# time rsync --inplace -av -e "ssh -c blowfish" root@localhost:/root/tst/src/ dst/
root@localhost's password:
receiving incremental file list
1gb.binsent 229413 bytes received 132192 bytes 9154.56 bytes/sec
total size is 1073742848 speedup is 2969.38real 0m38.678s
user 0m5.632s
sys 0m3.748s
root@localhost:~/tst#
Во время копирования (даже модифицированного файла) нет записи на диск, только чтение.
> Вероятно сказывается, что с обеих сторон - файловая система.
> У меня в таком случае тоже происходит полное копирование файла.интересно, это by design или бага? Или это не бага, а фича? :)
>> Вероятно сказывается, что с обеих сторон - файловая система.
>> У меня в таком случае тоже происходит полное копирование файла.
> интересно, это by design или бага? Или это не бага, а фича?
> :)delta-transmission disabled for local transfer
нужно использовать --no-whole-file чтобы локально дельта передавалась
>>> Вероятно сказывается, что с обеих сторон - файловая система.
>>> У меня в таком случае тоже происходит полное копирование файла.
>> интересно, это by design или бага? Или это не бага, а фича?
>> :)
> delta-transmission disabled for local transfer
> нужно использовать --no-whole-file чтобы локально дельта передаваласьманы рулят.
>>>> Вероятно сказывается, что с обеих сторон - файловая система.
>>>> У меня в таком случае тоже происходит полное копирование файла.
>>> интересно, это by design или бага? Или это не бага, а фича?
>>> :)
>> delta-transmission disabled for local transfer
>> нужно использовать --no-whole-file чтобы локально дельта передавалась
> маны рулят.никто ж не спорит, но иногда бывает сложно заметить такие нюансы.
>> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
>> То, что всё в одном файле - не важно, rsync умеет перегонять
>> только изменившиеся блоки.
> Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно
> давать ему ключи --inplace и --backup. Обычного [для меня, да] -av
> --progress не достаточно.По моему опыту rsync avz при копировании баз не подходит. Что то там ломается, и в результате база становится неалё.... Это при копировании rsync-ом поверх существующих файлов, с остановленной базой mysql. Если в dest файлы удалить и запустить rsync avz - то всё будет ок. Правда в этом случае копируется всё, а не изменения...
>[оверквотинг удален]
>>> То, что всё в одном файле - не важно, rsync умеет перегонять
>>> только изменившиеся блоки.
>> Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно
>> давать ему ключи --inplace и --backup. Обычного [для меня, да] -av
>> --progress не достаточно.
> По моему опыту rsync avz при копировании баз не подходит. Что то
> там ломается, и в результате база становится неалё.... Это при копировании
> rsync-ом поверх существующих файлов, с остановленной базой mysql. Если в dest
> файлы удалить и запустить rsync avz - то всё будет ок.
> Правда в этом случае копируется всё, а не изменения...У вас плохой rsync, видимо.
>>[оверквотинг удален]
> У вас плохой rsync, видимо.обычный, как у всех. база правда больше 50G... Я не стал разбираться в причинах, просто констатирую факт что таблички ломаются при avz. Если удалить dest и сделать в чистую папку - всё ок.
$ rsync --version
rsync version 3.0.9 protocol version 30
Copyright (C) 1996-2011 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes
>>> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
>>> То, что всё в одном файле - не важно, rsync умеет перегонять
>>> только изменившиеся блоки.
>> Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужноЕщё раз: я только с удивлением пролистал man (убедился, что он также запутан, как мануал для DBA-сверхразумов по ссыле ниже -- пока десять раз всё сам не сделаешь, не поймёшь). Нет "блочного" копирования баз я не пробовал, не то что не бенчил в сравнении с. Но люди говорят. Удивительно!--
>> давать ему ключи --inplace и --backup. Обычного [для меня, да] -av
>> --progress не достаточно.
> По моему опыту rsync avz при копировании баз не подходит. Что то
> там ломается, и в результате база становится неалё.... Это при копированииПопробуй https://www.postgresql.org/docs/current/static/continuous-ar... по инструкции!
> rsync-ом поверх существующих файлов, с остановленной базой mysql. Если в dest
А... Ну, да... Тогда, да. Rsync не той системы.
> файлы удалить и запустить rsync avz - то всё будет ок.
> Правда в этом случае копируется всё, а не изменения...
> Ещё раз: я только с удивлением пролистал man (убедился, что он также
> запутан, как мануал для DBA-сверхразумов по ссыле ниже -- пока десять
> раз всё сам не сделаешь, не поймёшь)Программисты не особо любят писать документацию.
А некоторые еще и упираются, когда....
На, зацени: https://github.com/vstakhov/rspamd/issues/992
> Ещё раз: я только с удивлением пролистал man (убедился, что он также
> запутан, как мануал для DBA-сверхразумов по ссыле ниже -- пока десять
> раз всё сам не сделаешь, не поймёшь). Нет "блочного" копирования баз
> я не пробовал, не то что не бенчил в сравнении с.
> Но люди говорят. Удивительно!--delta-transmission disabled for local transfer
Этого нет в мане. Это написано если запустить rsync с -vvvv
нужно использовать --no-whole-file чтобы локально дельта передавалась
Этого тоже нет в мане. Это благодаря секретному оружию сисадмина...
> все действительно в одном файле ibdata1Ну так и радуйтесь - просто копируете файлы базы на новый сервер.
Это быстрейший вариант.
>> все действительно в одном файле ibdata1
> Ну так и радуйтесь - просто копируете файлы базы на новый сервер.
> Это быстрейший вариант.Спасибо, впредь буду знать.
Все решилось прозаично и банально: добро на "игры" со слейвом не получил (равно как и на другие варианты), прогеры "что-то-там-подкрутили" в базе ввиду чего ее объем значительно сократился. В итоге сделал обычный перенос дампа за час с небольшим простоя. Остальное, предложенное здесь, "на досуге" для себя попробую.