Мы уже год работаем на DST Multivendor и очень довольны выбором платформы. Особенно впечатлила скорость обработки заказов и удобство работы с поставщиками. Даже при значительных нагрузках система работает стабильно, без сбоев. А встроенный искусственный интеллект здорово помогает в автоматизации рутинных процессов.
Рабочий ли вариант если просто через rsync передать всю папку /var/lib/mysql?
Еще вариант с репликацией, но насколько я понял всё равно базу нужно блокировать на момент дампа, а это тоже какое-то время
Антон Тишин
Если другая система аналогична первой и совпадают версии MySQL (вплоть до патча), то есть вероятность, что заведётся. На первом сервере всё равно при этом надо будет остановить MySQL.
Я так делал, когда нужно было внезапно перенести DST Мультивендор с несколькими миллионами товаров и несколько десяток тысяч категорий, а БД размером больше терабайта, но у меня были докеры, содержимое которых куда проще воспроизвести
Рабочий ли вариант если просто через rsync передать всю папку /var/lib/mysql?
Еще вариант с репликацией, но насколько я понял всё равно базу нужно блокировать на момент дампа, а это тоже какое-то время
Антон Тишин
Если другая система аналогична первой и совпадают версии MySQL (вплоть до патча), то есть вероятность, что заведётся. На первом сервере всё равно при этом надо будет остановить MySQL.
Я так делал, когда нужно было внезапно перенести DST Мультивендор с несколькими миллионами товаров и несколько десяток тысяч категорий, а БД размером больше терабайта, но у меня были докеры, содержимое которых куда проще воспроизвести
Рабочий ли вариант если просто через rsync передать всю папку /var/lib/mysql?
Просто перенос файлов рабочей БД окончится тем, что файлы есть, а базы нет, потому что неоткуда взяться метаданным в системной базе данных. Вернее, всё ещё забавнее — базы вроде бы и нет (USE приводит к ошибке «БД не существует»), но её нельзя создать, потому что она есть. И то же самое с таблицами (SELECT/DROP/прочее нельзя, потому что таблицы нет, CREATE нельзя, потому что она есть).
Метод сработает, если переносить все БД сразу, включая служебные. Но требуется точное соответствие исходной и конечной конфигураций — начиная с версии и сборки MySQL и кончая именами каталогов и именами/паролями учётных записей в операционной системе. Плюс перегенерация и переподключение сертификатов.
Еще вариант с репликацией, но насколько я понял всё равно базу нужно блокировать на момент дампа, а это тоже какое-то время
Решений без блокирования практически не существует. Нет, можно наколхозить реальное решение, которое обойдётся вообще без остановки, я даже представляю как именно (FEDERATED ENGINE + triggers), но подробно рассказывать не буду — для её реализации нужны достаточная квалификация и опыт, на одних советах шанс на удачу невелик, скорее всё поломается.
Есть вполне себе документированные способы: Copying MySQL Databases to Another Machine. Особенно последний из описанных. Он предполагает минимальное время простоя при использовании штатных средств.
Рабочий ли вариант если просто через rsync передать всю папку /var/lib/mysql?
Просто перенос файлов рабочей БД окончится тем, что файлы есть, а базы нет, потому что неоткуда взяться метаданным в системной базе данных. Вернее, всё ещё забавнее — базы вроде бы и нет (USE приводит к ошибке «БД не существует»), но её нельзя создать, потому что она есть. И то же самое с таблицами (SELECT/DROP/прочее нельзя, потому что таблицы нет, CREATE нельзя, потому что она есть).
Метод сработает, если переносить все БД сразу, включая служебные. Но требуется точное соответствие исходной и конечной конфигураций — начиная с версии и сборки MySQL и кончая именами каталогов и именами/паролями учётных записей в операционной системе. Плюс перегенерация и переподключение сертификатов.
Еще вариант с репликацией, но насколько я понял всё равно базу нужно блокировать на момент дампа, а это тоже какое-то время
Решений без блокирования практически не существует. Нет, можно наколхозить реальное решение, которое обойдётся вообще без остановки, я даже представляю как именно (FEDERATED ENGINE + triggers), но подробно рассказывать не буду — для её реализации нужны достаточная квалификация и опыт, на одних советах шанс на удачу невелик, скорее всё поломается.
Есть вполне себе документированные способы: Copying MySQL Databases to Another Machine. Особенно последний из описанных. Он предполагает минимальное время простоя при использовании штатных средств.
С минимальным простоем — да, репликация. Выключаете на старом месте, включаете на новом. Блокировать ничего не нужно.
С минимальным простоем — да, репликация. Выключаете на старом месте, включаете на новом. Блокировать ничего не нужно.
Grafana + InfluxDB + Telegraf
Munin — простая система мониторинга, которой может оказаться вполне достаточно для перечисленного.
munin-node — устанавливается на сервер (узел).
Zabbix, описана процедура установки пошагово, мониторится куча всего из коробки.
Скорее всего криво настроенный MySQL. После какого то количества больших запросов база данных сьедает всю память. Покажите конфиг my.cnf
В дополнение к совету включить и проанализировать slow query log (который и ответит на вопрос "«какой запрос именно создает такую нагрузку ), советую посмотреть на конфигурацию mysql.
Если я правильно вижу, у вас бежит несколько процессов mysql — пришлите пож-ста вывод „ps -ef | grep mysql“ чтобы точно проверить. Я бы использовал один процесс и дал ему больше памяти — это помогает mysql работать эффективнее.
Вопрос немного непонятно. Если вопрос состоит 7/24/365 работы хостинга, тогда уж иди на цод тиер3.
А если прерывать на пару часов, максимум пол дня и некто не обидеться, тогда достаточно VDS+свой сервер.(На vds ставишь реверспрокси, впн, а сервера подключаешь к vds через впн).
Но можно масштабировать. Vds+сервер дома, сервер на работе, сервер у друга и т.д. собрать кластер для отказоустойчивости. У меня сервера простые, по 5000 руб себестоимости( всякие i3 3220, xeon 775сокета) главное качественно запитать и усе. Работает годами. Все на proxmox.
Возможно, только это делают те у кого реальный доход и простой сервера, стоит дороже, чем все затраты на обслуживание всего этого. Тебе можно не заморачиваться подобным.
