forum.opennet.ru - "Миграция MySQL сервера" (39)

форумы

помощь

поиск

регистрация

вход/выход

слежка

"Миграция MySQL сервера"

Форум Открытые системы на сервере (Системное и пользовательское ПО / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Миграция MySQL сервера"	–2 +/–
Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 20:51
Доброго времени суток, aLL. Если можно, "на пальцах" расскажите, как грамотно реализовать следующее: необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются дампы mysqldump'ом. Вертится на сервере ПО на PHP. Простой перенос mysqldump'ом не подходит, ибо разворачивается новая база более 8 часов. Данный простой неприемлем. В связи с этим возникла мысль: можно ли, например, будущий основной сервер сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый сервер и "поднять" новый slave до мастера? Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое железо с минимальным простоем?
Ответить \| Правка \| Cообщить модератору

Оглавление

Миграция MySQL сервера, asavah, 21:42 , 18-Сен-16, (1) +1

Миграция MySQL сервера, l8saerexhn1, 21:59 , 18-Сен-16, (2) –2

Миграция MySQL сервера, asavah, 22:28 , 18-Сен-16, (3) +1

Миграция MySQL сервера, universite, 22:38 , 18-Сен-16, (5) –1

Миграция MySQL сервера, fail, 22:41 , 18-Сен-16, (7) –1
Миграция MySQL сервера, l8saerexhn1, 22:53 , 18-Сен-16, (9) –1

Миграция MySQL сервера, keir, 15:10 , 20-Сен-16, (19)

Миграция MySQL сервера, l8saerexhn1, 22:18 , 20-Сен-16, (20)

Миграция MySQL сервера, fail, 22:37 , 18-Сен-16, (4) –1

Миграция MySQL сервера, universite, 22:40 , 18-Сен-16, (6) –1

Миграция MySQL сервера, fail, 22:43 , 18-Сен-16, (8) –2
Миграция MySQL сервера, l8saerexhn1, 23:00 , 18-Сен-16, (12) –1

Миграция MySQL сервера, l8saerexhn1, 22:57 , 18-Сен-16, (10) –1

Миграция MySQL сервера, SupportIT, 22:59 , 18-Сен-16, (11) +1

Миграция MySQL сервера, l8saerexhn1, 23:04 , 18-Сен-16, (13) –1

Миграция MySQL сервера, PavelR, 09:05 , 19-Сен-16, (14) –1

Миграция MySQL сервера, ALex_hha, 11:25 , 19-Сен-16, (15) –1

Миграция MySQL сервера, xm, 13:24 , 06-Окт-16, (36)

Миграция MySQL сервера, ыы, 13:25 , 19-Сен-16, (16) –2

Миграция MySQL сервера, ALex_hha, 16:00 , 19-Сен-16, (17) –1

Миграция MySQL сервера, l8saerexhn1, 21:55 , 19-Сен-16, (18) –1

Миграция MySQL сервера, PavelR, 07:06 , 21-Сен-16, (21)

Миграция MySQL сервера, Andrey Mitrofanov, 09:34 , 21-Сен-16, (22)

Миграция MySQL сервера, ALex_hha, 12:28 , 22-Сен-16, (23)

Миграция MySQL сервера, Andrey Mitrofanov, 14:26 , 22-Сен-16, (24)

Миграция MySQL сервера, ALex_hha, 18:29 , 22-Сен-16, (25)

Миграция MySQL сервера, PavelR, 19:27 , 22-Сен-16, (26)

Миграция MySQL сервера, ALex_hha, 22:26 , 22-Сен-16, (27)

Миграция MySQL сервера, ыы, 12:38 , 23-Сен-16, (28)

Миграция MySQL сервера, PavelR, 17:49 , 23-Сен-16, (29)

Миграция MySQL сервера, ALex_hha, 19:17 , 26-Сен-16, (30)

Миграция MySQL сервера, skvernobot, 12:30 , 04-Окт-16, (31)

Миграция MySQL сервера, PavelR, 12:33 , 04-Окт-16, (32)

Миграция MySQL сервера, skvernobot, 12:48 , 04-Окт-16, (33)

Миграция MySQL сервера, Andrey Mitrofanov, 12:51 , 04-Окт-16, (34)

Миграция MySQL сервера, PavelR, 14:34 , 04-Окт-16, (35)
Миграция MySQL сервера, Square1, 22:53 , 07-Окт-16, (39)

Миграция MySQL сервера, xm, 13:26 , 06-Окт-16, (37)

Миграция MySQL сервера, l8saerexhn1, 13:57 , 06-Окт-16, (38)

Сообщения по теме [Сортировка по времени | RSS]

1. "Миграция MySQL сервера" +1 +/–

Сообщение от asavah (ok) on 18-Сен-16, 21:42

> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
рассказываю, наймите одмина, за деньги,
или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то мигрировать будет?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Миграция MySQL сервера" –2 +/–

Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 21:59

> рассказываю, наймите одмина, за деньги,
> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
> мигрировать будет?
Откуда столько агрессии, уважаемый?
Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. Для этого форумы и созданы - делиться знаниями.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Миграция MySQL сервера" +1 +/–

Сообщение от asavah (ok) on 18-Сен-16, 22:28

>> рассказываю, наймите одмина, за деньги,
>> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
>> мигрировать будет?
> Откуда столько агрессии, уважаемый?
> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
> Для этого форумы и созданы - делиться знаниями.
Для этого деньги и созданы - получать необходимые услуги с требуемым качеством.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

5. "Миграция MySQL сервера" –1 +/–

Сообщение от universite (ok) on 18-Сен-16, 22:38

>>> рассказываю, наймите одмина, за деньги,
>>> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то
>>> мигрировать будет?
>> Откуда столько агрессии, уважаемый?
>> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
>> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
>> Для этого форумы и созданы - делиться знаниями.
> Для этого деньги и созданы - получать необходимые услуги с требуемым качеством.
Если у вас 50ГБ разворачивается 8 часов, то:
1) не хватает CPU
2) мало ОЗУ
3) не SSD диски
4) отсутствует тюнинг Mysql и системы
5) не пробовали альтернативные форки Mysql.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Миграция MySQL сервера" –1 +/–

Сообщение от fail on 18-Сен-16, 22:41

> Если у вас 50ГБ разворачивается 8 часов, то:
> 1) не хватает CPU
> 2) мало ОЗУ
> 3) не SSD диски
> 4) отсутствует тюнинг Mysql и системы
> 5) не пробовали альтернативные форки Mysql.
N+1) возможнo бюджетный V{D,P}S хостинг ?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Миграция MySQL сервера" –1 +/–

Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 22:53

Спасибо за ответ.
> Если у вас 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.
Не пробовали. Но тут разработчики "правят бал".

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

19. "Миграция MySQL сервера" +/–

Сообщение от keir (ok) on 20-Сен-16, 15:10

Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера.
> hp dl180g6 (2 x Xeon 5645 2.4 Ггц , 48 Gb RAM,
> raid 60 из 10 дисков 15к sas). Сейчас это все в
> proxmox окружении, 90% ресурсов которого выделено именно под контейнер с базой.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "Миграция MySQL сервера" +/–

Сообщение от l8saerexhn1 (ok) on 20-Сен-16, 22:18

> Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера.
Спасибо за ответ.
Как раз хочу "соскочить" с proxmox в контексте БД, по крайней мере для мастер-сервера. Почему:
- странные, абсолютно бессистемные просадки производительности БД. Порой довольно ощутимые. Это не влияние загрузки БД, не влияние соседних контейнеров, не железо хоста, не дисковые операции, не софт. Не выявил никакой последовательности. Нечасто возникают, но таки есть. Причем такие одинаковые "просадки" возникают на двух разных серверах proxmox, в которых разные БД, с разным размером и разной загрузкой. Так что подозрение на openvz контейнеры (и там и там версия proxmox'a, а, равно, openvz одинаковая).
- openvz не поддерживает audit, а сие нужно.
- в новых версиях proxmox таки уже lxc. Не тестировал данную виртуализацию и как-то начинать знакомство с критически важных задач не хочется...

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

4. "Миграция MySQL сервера" –1 +/–

Сообщение от fail on 18-Сен-16, 22:37

...
> Откуда столько агрессии, уважаемый?
> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
> Для этого форумы и созданы - делиться знаниями.
- поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
- делается snapshot VM
- проигрываются различные сценарии переноса/миграции/etc
- выбирается лучший и т.д.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Миграция MySQL сервера" –1 +/–

Сообщение от universite (ok) on 18-Сен-16, 22:40

> ...
>> Откуда столько агрессии, уважаемый?
>> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"?
>> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать.
>> Для этого форумы и созданы - делиться знаниями.
> - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
> - делается snapshot VM
> - проигрываются различные сценарии переноса/миграции/etc
> - выбирается лучший и т.д.
Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может привести к деградации работы соседних VM. В итоге приведет к suspend проблемной VM :)

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

8. "Миграция MySQL сервера" –2 +/–

Сообщение от fail on 18-Сен-16, 22:43

> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может
> привести к деградации работы соседних VM. В итоге приведет к suspend
> проблемной VM :)
угу, см. 5 выше

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

12. "Миграция MySQL сервера" –1 +/–

Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 23:00

> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может
> привести к деградации работы соседних VM. В итоге приведет к suspend
> проблемной VM :)
Есть такой момент, иногда простреливает. Оно, конечно, на данном хосте еще пара "легких" контейнеров работает, почти все ресурсы под контейнер с базой отданы, но тем не менее...
И, да, долгие очень игры получаются.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Миграция MySQL сервера" –1 +/–

Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 22:57

Спасибо за ответ.
> - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian)
> - делается snapshot VM
> - проигрываются различные сценарии переноса/миграции/etc
> - выбирается лучший и т.д.
Чтобы все это сделать нужно понимать что и как вообще. Это все - БДшные дела - все висит на мне. А я никогда до этого администрированием БД не занимался. Опыта совсем 0. Вообще.
И, как всегда, нет времени на разобраться нормально, "поиграться и поизучать".
Предложенный мной вариант в принципе реализуем? Или же я неправ? Проблемы со стороны софта могут какие-либо быть?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

11. "Миграция MySQL сервера" +1 +/–

Сообщение от SupportIT on 18-Сен-16, 22:59

> В связи с этим возникла мысль: можно ли, например, будущий основной сервер
> сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый
> сервер и "поднять" новый slave до мастера?
> Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое
> железо с минимальным простоем?
Да, можно.
Именно так и делается.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Миграция MySQL сервера" –1 +/–

Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 23:04

> Да, можно.
> Именно так и делается.
Спасибо за ответ.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

14. "Миграция MySQL сервера" –1 +/–

Сообщение от PavelR (??) on 19-Сен-16, 09:05

> В связи с этим возникла мысль: можно ли, например, будущий основной сервер
> сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый
> сервер и "поднять" новый slave до мастера?
> Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое
> железо с минимальным простоем?
50Гб ? Фигня.
Через rsync копируешь файлы БД наживую. Это будет "первичный прогон".
Затем гасишь БД, повторяешь rsync. Он пройдет гораздо быстрее, перегоняться будут только изменившиеся данные, но все 50 Гб конечно должны будут быть вычитаны с диска.
Запускаешь БД на втором сервере. Всё.
Время простоя можешь оценить повторным "грязным прогоном".

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Миграция MySQL сервера" –1 +/–

Сообщение от ALex_hha (ok) on 19-Сен-16, 11:25

> Через rsync копируешь файлы БД наживую. Это будет "первичный прогон".
Профит будет только при включенном innodb_file_per_table, имхо. А если у него все данные в ibdata1. Хотя в любом случае, rsync будет побыстрее полного восстановления.
Ну и как уже говорили, вариант с добавлением временного слейва вполне рабочий.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

36. "Миграция MySQL сервера" +/–

Сообщение от xm (ok) on 06-Окт-16, 13:24

> А если у него все данные в ibdata1.
То это будет просто праздник, поскольку можно тупо скопировать сами файлики.
А это сильно быстрее чем все дампы, репликации и синхронизации. Будет простой, но это минуты какие-то.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Миграция MySQL сервера" –2 +/–

Сообщение от ыы on 19-Сен-16, 13:25

> Доброго времени суток, aLL.
> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
> необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и
> новую версию (mysql-5.6.28, debian).  База одна, нет реплик. Регулярно снимаются
> дампы mysqldump'ом. Вертится на сервере ПО на PHP.
Percona XtraBackup

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Миграция MySQL сервера" –1 +/–

Сообщение от ALex_hha (ok) on 19-Сен-16, 16:00

>> Доброго времени суток, aLL.
>> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее:
>> необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и
>> новую версию (mysql-5.6.28, debian).  База одна, нет реплик. Регулярно снимаются
>> дампы mysqldump'ом. Вертится на сервере ПО на PHP.
>  Percona XtraBackup
а она научилась вытягивать отдельную базу? Раньше не умела, т.е. если у тебя 10 баз, каждая по 20-50 Гб, то тянуть придется все

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

18. "Миграция MySQL сервера" –1 +/–

Сообщение от l8saerexhn1 (ok) on 19-Сен-16, 21:55

Всем спасибо за ответы, картина стала более-менее ясна.
Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с rsync'ом, честно говоря, с самого начала пришел на ум, да только таки все действительно в одном файле ibdata1 плюс есть сомнения в таком копировании - все ли потом будет ок?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Миграция MySQL сервера" +/–

Сообщение от PavelR (??) on 21-Сен-16, 07:06

> Всем спасибо за ответы, картина стала более-менее ясна.
> Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с
> rsync'ом, честно говоря, с самого начала пришел на ум, да только
> таки все действительно в одном файле ibdata1 плюс есть сомнения в
> таком копировании - все ли потом будет ок?
чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.
Проблем после копирования не будет. (Если вы конечно архитектуру и битность при переносе между хостами не меняете, за такие ситуации я не уверен).
При обновлении версии MySQL происходит то же самое:
-гасим СУБД
-устанавливаем бинарники/библиотеки новой версии
-запускаем СУБД.
Она возьмет файлы, созданные предыдущей версией и будет с ними работать.
Какая разница СУБД, на каком хосте их открыть?
По такой схеме делают также бэкапы с LVM-снепшотами.
Ну и кроме того, вы всегда можете попробовать. Погасили основной инстанс, сделали рсинк копию, подняли основной инстанс и работаете с ним, а также тестируете второй инстанс.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Миграция MySQL сервера" +/–

Сообщение от Andrey Mitrofanov on 21-Сен-16, 09:34

> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
> То, что всё в одном файле - не важно, rsync умеет перегонять
> только изменившиеся блоки.
Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно давать ему ключи --inplace и --backup. Обычного [для меня, да] -av --progress не достаточно.

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

23. "Миграция MySQL сервера" +/–

Сообщение от ALex_hha (ok) on 22-Сен-16, 12:28

> То, что всё в одном файле - не важно, 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

Я что то упускаю?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

24. "Миграция MySQL сервера" +/–

Сообщение от Andrey Mitrofanov on 22-Сен-16, 14:26

>>> То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки.
> вы уверены?
Нет не уверен и не пробовал, поэтому м написал:
#>> полистал man
#>>Видимо, умеет,

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

25. "Миграция MySQL сервера" +/–

Сообщение от ALex_hha (ok) on 22-Сен-16, 18:29

> Нет не уверен и не пробовал, поэтому м написал:
> #>> полистал man
> #>>Видимо, умеет,
вообще то я отвечал PavelR ;)

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

26. "Миграция MySQL сервера" +/–

Сообщение от PavelR (??) on 22-Сен-16, 19:27

>> То, что всё в одном файле - не важно, 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.bin
sent 36 bytes  received 1073872988 bytes  11128217.87 bytes/sec
total size is 1073741824  speedup is 1.00
real    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.bin
sent 229409 bytes  received 131683 bytes  9141.57 bytes/sec
total size is 1073742336  speedup is 2973.60
real    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 list
sent 11 bytes  received 53 bytes  18.29 bytes/sec
total size is 1073742336  speedup is 16777224.00
real    0m2.544s
user    0m0.000s
sys     0m0.012s
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.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.bin
sent 229413 bytes  received 132192 bytes  9154.56 bytes/sec
total size is 1073742848  speedup is 2969.38
real    0m38.678s
user    0m5.632s
sys     0m3.748s
root@localhost:~/tst#

Во время копирования (даже модифицированного файла) нет записи на диск, только чтение.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Миграция MySQL сервера" +/–

Сообщение от ALex_hha (ok) on 22-Сен-16, 22:26

> Вероятно сказывается, что с обеих сторон - файловая система.
> У меня в таком случае тоже происходит полное копирование файла.
интересно, это by design или бага? Или это не бага, а фича? :)

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Миграция MySQL сервера" +/–

Сообщение от ыы on 23-Сен-16, 12:38

>> Вероятно сказывается, что с обеих сторон - файловая система.
>> У меня в таком случае тоже происходит полное копирование файла.
> интересно, это by design или бага? Или это не бага, а фича?
> :)
delta-transmission disabled for local transfer
нужно использовать --no-whole-file чтобы локально дельта передавалась

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

29. "Миграция MySQL сервера" +/–

Сообщение от PavelR (??) on 23-Сен-16, 17:49

>>> Вероятно сказывается, что с обеих сторон - файловая система.
>>> У меня в таком случае тоже происходит полное копирование файла.
>> интересно, это by design или бага? Или это не бага, а фича?
>> :)
> delta-transmission disabled for local transfer
> нужно использовать --no-whole-file чтобы локально дельта передавалась
маны рулят.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

30. "Миграция MySQL сервера" +/–

Сообщение от ALex_hha (ok) on 26-Сен-16, 19:17

>>>> Вероятно сказывается, что с обеих сторон - файловая система.
>>>> У меня в таком случае тоже происходит полное копирование файла.
>>> интересно, это by design или бага? Или это не бага, а фича?
>>> :)
>> delta-transmission disabled for local transfer
>> нужно использовать --no-whole-file чтобы локально дельта передавалась
> маны рулят.
никто ж не спорит, но иногда бывает сложно заметить такие нюансы.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

31. "Миграция MySQL сервера" +/–

Сообщение от skvernobot (ok) on 04-Окт-16, 12:30

>> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
>> То, что всё в одном файле - не важно, rsync умеет перегонять
>> только изменившиеся блоки.
> Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно
> давать ему ключи --inplace и --backup. Обычного [для меня, да] -av
> --progress не достаточно.
По моему опыту rsync avz при копировании баз не подходит. Что то там ломается, и в результате база становится неалё.... Это при копировании rsync-ом поверх существующих файлов, с остановленной базой mysql. Если в dest файлы удалить и запустить rsync avz - то всё будет ок. Правда в этом случае копируется всё, а не изменения...

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

32. "Миграция MySQL сервера" +/–

Сообщение от PavelR (??) on 04-Окт-16, 12:33

>[оверквотинг удален]
>>> То, что всё в одном файле - не важно, rsync умеет перегонять
>>> только изменившиеся блоки.
>> Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно
>> давать ему ключи --inplace и --backup. Обычного [для меня, да] -av
>> --progress не достаточно.
> По моему опыту rsync avz при копировании баз не подходит. Что то
> там ломается, и в результате база становится неалё.... Это при копировании
> rsync-ом поверх существующих файлов, с остановленной базой mysql. Если в dest
> файлы удалить и запустить rsync avz - то всё будет ок.
> Правда в этом случае копируется всё, а не изменения...
У вас плохой rsync, видимо.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Миграция MySQL сервера" +/–

Сообщение от skvernobot (ok) on 04-Окт-16, 12:48

>>[оверквотинг удален]
> У вас плохой 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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

34. "Миграция MySQL сервера" +/–

Сообщение от Andrey Mitrofanov on 04-Окт-16, 12:51

>>> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны.
>>> То, что всё в одном файле - не важно, 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 - то всё будет ок.
> Правда в этом случае копируется всё, а не изменения...

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

35. "Миграция MySQL сервера" +/–

Сообщение от PavelR (??) on 04-Окт-16, 14:34

> Ещё раз: я только с удивлением пролистал man (убедился, что он также
> запутан, как мануал для DBA-сверхразумов по ссыле ниже -- пока десять
> раз всё сам не сделаешь, не поймёшь)
Программисты не особо любят писать документацию.
А некоторые еще и упираются, когда....
На, зацени: https://github.com/vstakhov/rspamd/issues/992

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Миграция MySQL сервера" +/–

Сообщение от Square1 on 07-Окт-16, 22:53

> Ещё раз: я только с удивлением пролистал man (убедился, что он также
> запутан, как мануал для DBA-сверхразумов по ссыле ниже -- пока десять
> раз всё сам не сделаешь, не поймёшь). Нет "блочного" копирования баз
> я не пробовал, не то что не бенчил в сравнении с.
> Но люди говорят. Удивительно!--
delta-transmission disabled for local transfer
Этого нет в мане. Это написано если запустить rsync с -vvvv
нужно использовать --no-whole-file чтобы локально дельта передавалась
Этого тоже нет в мане. Это благодаря секретному оружию сисадмина...

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

37. "Миграция MySQL сервера" +/–

Сообщение от xm (ok) on 06-Окт-16, 13:26

> все действительно в одном файле ibdata1
Ну так и радуйтесь - просто копируете файлы базы на новый сервер.
Это быстрейший вариант.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

38. "Миграция MySQL сервера" +/–

Сообщение от l8saerexhn1 (ok) on 06-Окт-16, 13:57

>> все действительно в одном файле ibdata1
> Ну так и радуйтесь - просто копируете файлы базы на новый сервер.
> Это быстрейший вариант.
Спасибо, впредь буду знать.
Все решилось прозаично и банально: добро на "игры" со слейвом не получил (равно как и на другие варианты), прогеры "что-то-там-подкрутили" в базе ввиду чего ее объем значительно сократился. В итоге сделал обычный перенос дампа за час с небольшим простоя. Остальное, предложенное здесь, "на досуге" для себя попробую.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Миграция MySQL сервера"	+1 +/–
Сообщение от asavah (ok) on 18-Сен-16, 21:42
> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее: рассказываю, наймите одмина, за деньги, или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то мигрировать будет?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Миграция MySQL сервера"	–2 +/–
	Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 21:59
	> рассказываю, наймите одмина, за деньги, > или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то > мигрировать будет? Откуда столько агрессии, уважаемый? Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"? Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. Для этого форумы и созданы - делиться знаниями.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Миграция MySQL сервера"	+1 +/–
	Сообщение от asavah (ok) on 18-Сен-16, 22:28
	>> рассказываю, наймите одмина, за деньги, >> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то >> мигрировать будет? > Откуда столько агрессии, уважаемый? > Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"? > Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. > Для этого форумы и созданы - делиться знаниями. Для этого деньги и созданы - получать необходимые услуги с требуемым качеством.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	5. "Миграция MySQL сервера"	–1 +/–
	Сообщение от universite (ok) on 18-Сен-16, 22:38
	>>> рассказываю, наймите одмина, за деньги, >>> или вы думаете вам тут продакшн-базу на 50 гектаров нахаляву пошагово кто-то >>> мигрировать будет? >> Откуда столько агрессии, уважаемый? >> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"? >> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. >> Для этого форумы и созданы - делиться знаниями. > Для этого деньги и созданы - получать необходимые услуги с требуемым качеством. Если у вас 50ГБ разворачивается 8 часов, то: 1) не хватает CPU 2) мало ОЗУ 3) не SSD диски 4) отсутствует тюнинг Mysql и системы 5) не пробовали альтернативные форки Mysql.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	7. "Миграция MySQL сервера"	–1 +/–
	Сообщение от fail on 18-Сен-16, 22:41
	> Если у вас 50ГБ разворачивается 8 часов, то: > 1) не хватает CPU > 2) мало ОЗУ > 3) не SSD диски > 4) отсутствует тюнинг Mysql и системы > 5) не пробовали альтернативные форки Mysql. N+1) возможнo бюджетный V{D,P}S хостинг ?
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	9. "Миграция MySQL сервера"	–1 +/–
	Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 22:53
	Спасибо за ответ. > Если у вас 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. Не пробовали. Но тут разработчики "правят бал".
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	19. "Миграция MySQL сервера"	+/–
	Сообщение от keir (ok) on 20-Сен-16, 15:10
	Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера. > hp dl180g6 (2 x Xeon 5645 2.4 Ггц , 48 Gb RAM, > raid 60 из 10 дисков 15к sas). Сейчас это все в > proxmox окружении, 90% ресурсов которого выделено именно под контейнер с базой.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	20. "Миграция MySQL сервера"	+/–
	Сообщение от l8saerexhn1 (ok) on 20-Сен-16, 22:18
	> Поднимаете второй сервер на proxmox, кластеризуете их, и делаете миграцию контейнера. Спасибо за ответ. Как раз хочу "соскочить" с proxmox в контексте БД, по крайней мере для мастер-сервера. Почему: - странные, абсолютно бессистемные просадки производительности БД. Порой довольно ощутимые. Это не влияние загрузки БД, не влияние соседних контейнеров, не железо хоста, не дисковые операции, не софт. Не выявил никакой последовательности. Нечасто возникают, но таки есть. Причем такие одинаковые "просадки" возникают на двух разных серверах proxmox, в которых разные БД, с разным размером и разной загрузкой. Так что подозрение на openvz контейнеры (и там и там версия proxmox'a, а, равно, openvz одинаковая). - openvz не поддерживает audit, а сие нужно. - в новых версиях proxmox таки уже lxc. Не тестировал данную виртуализацию и как-то начинать знакомство с критически важных задач не хочется...
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	4. "Миграция MySQL сервера"	–1 +/–
	Сообщение от fail on 18-Сен-16, 22:37
	... > Откуда столько агрессии, уважаемый? > Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"? > Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. > Для этого форумы и созданы - делиться знаниями. - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian) - делается snapshot VM - проигрываются различные сценарии переноса/миграции/etc - выбирается лучший и т.д.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "Миграция MySQL сервера"	–1 +/–
	Сообщение от universite (ok) on 18-Сен-16, 22:40
	> ... >> Откуда столько агрессии, уважаемый? >> Я где-то говорил про "халяву", "пошагово" и "сделать все за меня"? >> Я лишь прошу поделиться опытом знающих людей. Подсказать, куда смотреть, что почитать. >> Для этого форумы и созданы - делиться знаниями. > - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian) > - делается snapshot VM > - проигрываются различные сценарии переноса/миграции/etc > - выбирается лучший и т.д. Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может привести к деградации работы соседних VM. В итоге приведет к suspend проблемной VM :)
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	8. "Миграция MySQL сервера"	–2 +/–
	Сообщение от fail on 18-Сен-16, 22:43
	> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может > привести к деградации работы соседних VM. В итоге приведет к suspend > проблемной VM :) угу, см. 5 выше
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	12. "Миграция MySQL сервера"	–1 +/–
	Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 23:00
	> Это слишком долго. К тому же частые чтение-запись 50ГБ на диск может > привести к деградации работы соседних VM. В итоге приведет к suspend > проблемной VM :) Есть такой момент, иногда простреливает. Оно, конечно, на данном хосте еще пара "легких" контейнеров работает, почти все ресурсы под контейнер с базой отданы, но тем не менее... И, да, долгие очень игры получаются.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	10. "Миграция MySQL сервера"	–1 +/–
	Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 22:57
	Спасибо за ответ. > - поднимается и настраивается VM с целевым хостом (mysql-5.6.28, debian) > - делается snapshot VM > - проигрываются различные сценарии переноса/миграции/etc > - выбирается лучший и т.д. Чтобы все это сделать нужно понимать что и как вообще. Это все - БДшные дела - все висит на мне. А я никогда до этого администрированием БД не занимался. Опыта совсем 0. Вообще. И, как всегда, нет времени на разобраться нормально, "поиграться и поизучать". Предложенный мной вариант в принципе реализуем? Или же я неправ? Проблемы со стороны софта могут какие-либо быть?
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору

11. "Миграция MySQL сервера"	+1 +/–
Сообщение от SupportIT on 18-Сен-16, 22:59
> В связи с этим возникла мысль: можно ли, например, будущий основной сервер > сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый > сервер и "поднять" новый slave до мастера? > Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое > железо с минимальным простоем? Да, можно. Именно так и делается.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	13. "Миграция MySQL сервера"	–1 +/–
	Сообщение от l8saerexhn1 (ok) on 18-Сен-16, 23:04
	> Да, можно. > Именно так и делается. Спасибо за ответ.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору

14. "Миграция MySQL сервера"	–1 +/–
Сообщение от PavelR (??) on 19-Сен-16, 09:05
> В связи с этим возникла мысль: можно ли, например, будущий основной сервер > сделать slave'ом к существующей базе, дождаться синхронизации данных, выключить старый > сервер и "поднять" новый slave до мастера? > Или, если мысль неверная, как тогда делать грамотную миграцию БД на новое > железо с минимальным простоем? 50Гб ? Фигня. Через rsync копируешь файлы БД наживую. Это будет "первичный прогон". Затем гасишь БД, повторяешь rsync. Он пройдет гораздо быстрее, перегоняться будут только изменившиеся данные, но все 50 Гб конечно должны будут быть вычитаны с диска. Запускаешь БД на втором сервере. Всё. Время простоя можешь оценить повторным "грязным прогоном".
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	15. "Миграция MySQL сервера"	–1 +/–
	Сообщение от ALex_hha (ok) on 19-Сен-16, 11:25
	> Через rsync копируешь файлы БД наживую. Это будет "первичный прогон". Профит будет только при включенном innodb_file_per_table, имхо. А если у него все данные в ibdata1. Хотя в любом случае, rsync будет побыстрее полного восстановления. Ну и как уже говорили, вариант с добавлением временного слейва вполне рабочий.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	36. "Миграция MySQL сервера"	+/–
	Сообщение от xm (ok) on 06-Окт-16, 13:24
	> А если у него все данные в ibdata1. То это будет просто праздник, поскольку можно тупо скопировать сами файлики. А это сильно быстрее чем все дампы, репликации и синхронизации. Будет простой, но это минуты какие-то.
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору

16. "Миграция MySQL сервера"	–2 +/–
Сообщение от ыы on 19-Сен-16, 13:25
> Доброго времени суток, aLL. > Если можно, "на пальцах" расскажите, как грамотно реализовать следующее: > необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и > новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются > дампы mysqldump'ом. Вертится на сервере ПО на PHP. Percona XtraBackup
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	17. "Миграция MySQL сервера"	–1 +/–
	Сообщение от ALex_hha (ok) on 19-Сен-16, 16:00
	>> Доброго времени суток, aLL. >> Если можно, "на пальцах" расскажите, как грамотно реализовать следующее: >> необходимо имеющуюся БД (~50 Гб, mysql-5.5.43, openvz) мигрировать на новое железо и >> новую версию (mysql-5.6.28, debian). База одна, нет реплик. Регулярно снимаются >> дампы mysqldump'ом. Вертится на сервере ПО на PHP. > Percona XtraBackup а она научилась вытягивать отдельную базу? Раньше не умела, т.е. если у тебя 10 баз, каждая по 20-50 Гб, то тянуть придется все
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору

18. "Миграция MySQL сервера"	–1 +/–
Сообщение от l8saerexhn1 (ok) on 19-Сен-16, 21:55
Всем спасибо за ответы, картина стала более-менее ясна. Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с rsync'ом, честно говоря, с самого начала пришел на ум, да только таки все действительно в одном файле ibdata1 плюс есть сомнения в таком копировании - все ли потом будет ок?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	21. "Миграция MySQL сервера"	+/–
	Сообщение от PavelR (??) on 21-Сен-16, 07:06
	> Всем спасибо за ответы, картина стала более-менее ясна. > Попробую таки вариант со слэйвом. Также посмотрю поближе на xtrabackup. Вариант с > rsync'ом, честно говоря, с самого начала пришел на ум, да только > таки все действительно в одном файле ibdata1 плюс есть сомнения в > таком копировании - все ли потом будет ок? чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны. То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки. Проблем после копирования не будет. (Если вы конечно архитектуру и битность при переносе между хостами не меняете, за такие ситуации я не уверен). При обновлении версии MySQL происходит то же самое: -гасим СУБД -устанавливаем бинарники/библиотеки новой версии -запускаем СУБД. Она возьмет файлы, созданные предыдущей версией и будет с ними работать. Какая разница СУБД, на каком хосте их открыть? По такой схеме делают также бэкапы с LVM-снепшотами. Ну и кроме того, вы всегда можете попробовать. Погасили основной инстанс, сделали рсинк копию, подняли основной инстанс и работаете с ним, а также тестируете второй инстанс.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	22. "Миграция MySQL сервера"	+/–
	Сообщение от Andrey Mitrofanov on 21-Сен-16, 09:34
	> чистовой рсинк проходит на неизменяющихся файлах. Файлы на обеих хостах будут идентичны. > То, что всё в одном файле - не важно, rsync умеет перегонять > только изменившиеся блоки. Гм, полистал man rsync на предмет "block". Видимо, умеет, но похоже нужно давать ему ключи --inplace и --backup. Обычного [для меня, да] -av --progress не достаточно.
	Ответить \| Правка \| ^ к родителю #21 \| Наверх \| Cообщить модератору


	23. "Миграция MySQL сервера"	+/–
	Сообщение от ALex_hha (ok) on 22-Сен-16, 12:28
	> То, что всё в одном файле - не важно, 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 Я что то упускаю?
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	24. "Миграция MySQL сервера"	+/–
	Сообщение от Andrey Mitrofanov on 22-Сен-16, 14:26
	>>> То, что всё в одном файле - не важно, rsync умеет перегонять только изменившиеся блоки. > вы уверены? Нет не уверен и не пробовал, поэтому м написал: #>> полистал man #>>Видимо, умеет,
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору


	25. "Миграция MySQL сервера"	+/–
	Сообщение от ALex_hha (ok) on 22-Сен-16, 18:29
	> Нет не уверен и не пробовал, поэтому м написал: > #>> полистал man > #>>Видимо, умеет, вообще то я отвечал PavelR ;)
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	26. "Миграция MySQL сервера"	+/–
	Сообщение от PavelR (??) on 22-Сен-16, 19:27
	>> То, что всё в одном файле - не важно, 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.bin sent 36 bytes received 1073872988 bytes 11128217.87 bytes/sec total size is 1073741824 speedup is 1.00 real 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.bin sent 229409 bytes received 131683 bytes 9141.57 bytes/sec total size is 1073742336 speedup is 2973.60 real 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 list sent 11 bytes received 53 bytes 18.29 bytes/sec total size is 1073742336 speedup is 16777224.00 real 0m2.544s user 0m0.000s sys 0m0.012s 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.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.bin sent 229413 bytes received 132192 bytes 9154.56 bytes/sec total size is 1073742848 speedup is 2969.38 real 0m38.678s user 0m5.632s sys 0m3.748s root@localhost:~/tst# Во время копирования (даже модифицированного файла) нет записи на диск, только чтение.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору


	27. "Миграция MySQL сервера"	+/–
	Сообщение от ALex_hha (ok) on 22-Сен-16, 22:26
	> Вероятно сказывается, что с обеих сторон - файловая система. > У меня в таком случае тоже происходит полное копирование файла. интересно, это by design или бага? Или это не бага, а фича? :)
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	28. "Миграция MySQL сервера"	+/–
	Сообщение от ыы on 23-Сен-16, 12:38
	>> Вероятно сказывается, что с обеих сторон - файловая система. >> У меня в таком случае тоже происходит полное копирование файла. > интересно, это by design или бага? Или это не бага, а фича? > :) delta-transmission disabled for local transfer нужно использовать --no-whole-file чтобы локально дельта передавалась
	Ответить \| Правка \| ^ к родителю #27 \| Наверх \| Cообщить модератору


	29. "Миграция MySQL сервера"	+/–
	Сообщение от PavelR (??) on 23-Сен-16, 17:49
	>>> Вероятно сказывается, что с обеих сторон - файловая система. >>> У меня в таком случае тоже происходит полное копирование файла. >> интересно, это by design или бага? Или это не бага, а фича? >> :) > delta-transmission disabled for local transfer > нужно использовать --no-whole-file чтобы локально дельта передавалась маны рулят.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору