Страница 2 из 2 ПерваяПервая 12
Показано с 11 по 20 из 20

Тема: Базы данных после отключения электроэнергии

  1. #11
    Senior Member
    Регистрация
    09.04.2013
    Адрес
    Москва
    Сообщений
    1,993

    По умолчанию

    Я перепутал)
    ID_процесса:ID запроса
    Но тут тоже есть ответ
    db ERROR query error: Table 'ispmgr.nginx_proxy_panners' doesn't exist (Нет таблицы)
    На этом панель крашит запрос
    Тоже
    db ERROR query error: Unknown column 'sslcert.info' in 'field list' (Нет столбца в таблице)

  2. #12
    Senior Member Аватар для Iliaxxx
    Регистрация
    25.05.2011
    Сообщений
    367

    По умолчанию

    Это запрос к какой базе? ispmgr или же к тем что лежат в sqlite?

  3. #13
    Senior Member
    Регистрация
    09.04.2013
    Адрес
    Москва
    Сообщений
    1,993

    По умолчанию

    MySQL ispmgr

  4. #14
    Senior Member Аватар для Iliaxxx
    Регистрация
    25.05.2011
    Сообщений
    367

    По умолчанию

    А это странно, я восстанавливал базу из бэкапа, они там точно должны находиться.
    Ладно, спасибо за подсказку, буду ковырять, возможно mysqldump как то неправильно отработал.
    Есть рекомендации по восстановлению этой базы?

  5. #15
    Senior Member
    Регистрация
    09.04.2013
    Адрес
    Москва
    Сообщений
    1,993

    По умолчанию

    Посмотреть лог mysql / папку с базой
    Вполне возможно что таблицы есть, но они просто крашнулись и не запустились
    Можно удалить их, и накатить заново

  6. #16
    Senior Member Аватар для Iliaxxx
    Регистрация
    25.05.2011
    Сообщений
    367

    По умолчанию

    Цитата Сообщение от Mobiaaa Посмотреть сообщение
    Посмотреть лог mysql / папку с базой
    Вполне возможно что таблицы есть, но они просто крашнулись и не запустились
    Можно удалить их, и накатить заново
    Это я сделал в первую очередь. Но он обрывается в 8 часов, как раз в это время я накатил дамп
    180518 8:04:00 [Warning] mysqld: Forcing close of thread 14 user: 'ispmgr'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 13 user: 'ispmgr'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 12 user: 'ispmgr'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 11 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 10 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 9 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 8 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 7 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 6 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 5 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 4 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 3 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 2 user: 'pdns'

    180518 8:04:00 [Warning] mysqld: Forcing close of thread 1 user: 'ispmgr'

    180518 8:04:00 InnoDB: Starting shutdown...
    180518 8:04:01 InnoDB: Shutdown completed; log sequence number 8314
    180518 8:04:01 [Note] mysqld: Shutdown complete
    И на этом конец

    Есть мысль а может быть такая проблема, если скажем я накатил бэкап месячной давности и у пользователя за это время сформировался новый сертефикат. Это может вызывать такю ошибку. В базе прописан один, а по факту стоит другой.

  7. #17
    Senior Member
    Регистрация
    09.04.2013
    Адрес
    Москва
    Сообщений
    1,993

    По умолчанию

    Это другой "побочный" эффект
    Но я кажется понял откуда ноги растут
    У Вас панель обновлялась за последний месяц (и база тоже, проксирование как раз в последнем stable апдейте было, а в SSL видимо тип сертификата Let's encrypt wildcard или обычный), а Вы теперь бекап старый накатили

  8. #18
    Senior Member
    Регистрация
    09.04.2013
    Адрес
    Москва
    Сообщений
    1,993

    По умолчанию

    Я посмотрел пару пакетов ISP на предмет POST скриптов, но там нет обновлений базы
    База скорей всего обновляется уже самой панелью а не менеджером пакетов
    Есть два варианта
    1) Поставить рядом ещё панель и сравнить таблицы
    2) Обратиться к ISP непосредственно, может дадут дамп базы, который сконвертит в текущую стабильную

  9. #19
    Senior Member Аватар для Iliaxxx
    Регистрация
    25.05.2011
    Сообщений
    367

    По умолчанию

    Цитата Сообщение от Mobiaaa Посмотреть сообщение
    Я посмотрел пару пакетов ISP на предмет POST скриптов, но там нет обновлений базы
    База скорей всего обновляется уже самой панелью а не менеджером пакетов
    Есть два варианта
    1) Поставить рядом ещё панель и сравнить таблицы
    2) Обратиться к ISP непосредственно, может дадут дамп базы, который сконвертит в текущую стабильную
    В общем, ларчик открылся просто, сейчас запилию инструкцию, для тех кто попал в такую же ситуацию.

  10. #20
    Senior Member Аватар для Iliaxxx
    Регистрация
    25.05.2011
    Сообщений
    367

    По умолчанию

    Сразу скажу, это для тех у кого есть резервный образ сервера, скажем так для тех у кого есть выделенные сервера с функцией создания снимков.

    У нас mysql по дефолту не стартует, база крашнулась.
    1) Делаем бэкап каталогов:
    /var/lib/mysql
    /var/lib/mysql-5.5
    /var/lib/mysql-5.6
    /var/lib/mysql-5.7
    /var/lib/mysql Этот каталог обязателен, остальных может и не быть у Вас на сервере, все зависит от установленных версий mysql
    В каталоге /var/lib/mysql копируем все, но обязательно нужно скопировать 3 файла ibdata1, ib_logfile0, ib_logfile1. Файл ibdata1 может быть большим, зависит от того, сколько у Вас баз.
    2) Запускаем сервер mysql в режиме восстановления
    Запускаем его так:
    mysqld --innodb_force_recovery=6
    Сразу оговорка. Это не рабочий режим, полноценно работать не получится, но нам этого хватит.
    3) Выгружаем базу
    mysqldump ispmgr > ispmgr_dump.sql
    Останавливаем сервер
    /etc/init.d/mysql stop
    4) Удаляем каталоги
    /var/lib/mysql
    /var/lib/mysql-5.5
    /var/lib/mysql-5.6
    /var/lib/mysql-5.7
    5) Заливаем каталоги с бэкапа
    6) Перезапускам Mysql в нормальном режиме
    /etc/init.d/mysql restart
    Должен загрузиться в нормальном режиме.
    Проверяем панель. Если все гуд то отлично, если как у меня, часть функционала недоступна, идем по списку дальше.
    7) Заходим на сервер по phpmyadmin и удаляем все таблицы в базе ispmgr
    8) Импортируем на этом же phpmyadmin наш дамп, который делали до этого.
    Вот и все, после этого у Вас актуальная рабочая база. Не забудьте восстановить из бэкапа все остальные базы.

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •