Возможен ли «мистический» откат базы данных на digitalocean.com?
Подскажите , есть сайт магазин , его "нутро" некто не трогал , редактировалась цена и категории товаров , через некоторое время сайт сбросил все обновления , в ПУ хостингом нечего не происходило , на самом сервере тоже , как узнать как такое произошло?
mrusklon: затрудняюсь ответить что там произошло на самом деле, но ваш случай не единичный - все что заполняеться удаленно имеет свойсто не сохраняться, поэтому нужно чаще "сейвиться" и проверят засохранилось ли но это геморой, посему советую на локальной системе наполнять а на сервер уже просто базу данных отдавать
mrusklon: заполняйте снова с удобством тогда удаленно (а что локально вы подругому заполняете?) :) я вам говорю основываясь на практике не одной сотни проектов :)
mrusklon: ну по сути так же :) то есть у вас на локальной машине должно быть словно зеркало установлен софт для используемой базы даных, ваш магазин (который будет работать только для заполнения) и идеально механизм синхронизации (который может быть исполене Н способами) вы локально подключаетесь к локально установленому магазину и делаете изменения, проверяете все ли ок, и запускаете процес обновления удаленой базы - клиенты работают с вашим магазином с хостинга видят обновления... ну как то так.
mrusklon: при работе удаленно не скармливайте большие объемы данных без проверок, скажем занесли 10 вещей - отключитесь проверте работает ли... геморойно но зато надежно (кто писал рефераты в студенчестве на ворде - CTRL + S нажимают инстинктивно после каждого enter :))
в истории откатов , последний откат более одного месяца назад (я его делал сам) , уже не знаю что думать , доступ есть только у меня , log консоли не изменился с последнего моего визита
Пума Тайланд: да как бэ нет.
Там есть /etc/init.d/killprocs , который бодренько убивает mysql (и всё остальное), если у него init-скрипт не уложился в таймаут (таймаут уже не помню). А mysql он, гад эдакий, живучий - может флашить на диск несколько минут при init.d/mysql stop.
Поэтому DBA всегда стопают mysql руками перед ребутом сервера.
Это помимо того, что из панели можно сделать банальный reset по питанию.
Ой не смешите несколько минут на тестовой базе где обновили только цены.
ну посмотрите что там с бд, даже если бы не все скинул на диск мускул там были бы не консистентные данные, мускул чек такое сразу выявит.
ну так если тушишь корректно на малой базе с малыми изменениями оно флашнется меньше чем за секунду
скорее всего сам что то человек сделал и затер, или кто то ему помог
Пума Тайланд: там всё не так просто. Если mysql залочили хитровы*м запросом, который не позволяет ему вырубиться - то он сначала будет ждать, когда этот запрос умрет (таймаут там есть из коробки, но он большой). Потом mysql перестанет принимать новые запросы, и только потом начнет флашить всё без разбору. Это если в упрощенном виде. Так там в уровнях блокировок голову сломать можно, если сесть фантазировать. Ну самое простое - кто-то взял write lock на кучу таблиц и ушел спать в транзакции на полчаса.
Но повторюсь, я скорее про то, что сделали ребут "по питанию" из панели. Или хостер ребутнул виртуалку "по питанию" (у DO такое случается частенько по меркам "default kvm hoster").
