- В этой теме 7 ответов, 2 участника, последнее обновление 1 месяц, 2 недели назад сделано
.
- Сообщения
Дано:
Сервер 1С + MS SQL на одном сервере.
База данных – модель восстановления “Простая”
RAID1 на SSD – для базы + RAID1 на SSD – для лога транзакций. RAID программный.
Во время довольно интенсивной работы ВНЕЗАПНО (SSD на гарантии, состояние отличное) умирает один из дисков массива. Причем умирает так странно, что зеркало просто останавливается и перестает отзываться (за 20 лет работы с зеркалами такое впервые!)
То есть прекращаются любые запись – чтение.
После перезагрузки сервера RAID не виден.
Убираем умерший диск, со второго диска зеркала все читается-пишется без проблем. НО Потеряно 15 минут документов интенсивной работы (лог транзакции поврежден, при помощи DBCC CHECKDB восстановить получилось лишь частично).
Диски заменены, базу запустили
ТРЕБУЕТСЯ
Идеи по предотвращению подобных ситуаций в будущем.
Бэкапы – да, хорошо. Но не будешь же делать бэкап после проведения каждого документа.
Какие возможны варианты для защиты от таких вылетов?Здравствуйте, helpdima
Пишите здесь https://t.me/odineski, чтоб быстрее получить ответ, там у нас бот 1С ник работает )
Написал. Бот ответил полную ерунду – как я и предполагал. Ну это ожидаемо 🙂 Не всякая задача по плечу ИИ
Для предотвращения подобных ситуаций в будущем можно рассмотреть несколько подходов и технологий, которые помогут улучшить надежность системы и минимизировать риск потери данных:
1. Использование RAID 10: Вместо RAID 1, рассмотрите возможность использования RAID 10 (или RAID 1+0). Это обеспечит как избыточность, так и производительность, что может помочь в случае выхода из строя одного из дисков.
2. Аппаратный RAID-контроллер: Если вы используете программный RAID, возможно, стоит рассмотреть переход на аппаратный RAID-контроллер. Аппаратные контроллеры часто более надежны и могут предложить дополнительные функции, такие как кэширование записи.
3. Мониторинг состояния дисков: Настройте систему мониторинга для отслеживания состояния дисков. Используйте S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) для раннего выявления потенциальных проблем с дисками.
4. Регулярные бэкапы: Хотя вы упомянули, что не хотите делать бэкапы после каждого документа, стоит рассмотреть возможность настройки автоматических бэкапов на уровне базы данных. Например, можно настроить бэкапы каждые 15 минут или по окончании определенных операций.
5. Логирование транзакций: Рассмотрите возможность использования более надежной модели восстановления, такой как “Полная” (Full Recovery Model). Это позволит вам делать бэкапы логов транзакций, что поможет восстановить данные до последней успешной транзакции.
6. Использование репликации: Настройте репликацию базы данных на другой сервер. Это обеспечит дополнительный уровень защиты и позволит быстро восстановить работу в случае сбоя.
7. Тестирование восстановления: Регулярно проводите тестирование восстановления из резервных копий, чтобы убедиться, что ваши бэкапы работают и могут быть использованы в случае необходимости.
8. Обновление оборудования: Убедитесь, что ваше оборудование (диски, контроллеры и т.д.) соответствует современным стандартам и требованиям. Иногда старое оборудование может быть причиной неожиданных сбоев.
9. Использование UPS: Установите источник бесперебойного питания (UPS) для защиты от сбоев питания, которые могут привести к повреждению данных.
10. Обучение персонала: Обучите сотрудников правильным методам работы с системой, чтобы минимизировать риск ошибок, которые могут привести к потере данных.
Эти меры помогут значительно снизить риск потери данных и улучшить общую надежность вашей системы.
Всё, что он предложил – давно сделано. Некоторые из его предложений (в частности RAID10 и аппаратный RAID – бессмысленны – ибо дело не в контроллере)
Разумеется, бэкапы есть. Но суточные.
Но даже если бы были суточные + дифференциальные каждый час – от этой проблемы бы не застраховали.Про какую “репликацию” пишет бот – опять же неясно. Репликацию баз MS SQL? РИБ?
Что-то еще?
Бэкап логов транзакций? С какой частотой? Ежесекундно?Повторюсь.
Задача стоит застраховаться от ситуации когда на ровном месте при интенсивной работе отваливается дисковый массив с логом транзакций.
Из-за этого потерялось 15 минут работы.
Второй – третий – пятый серверы тоже возможны. Но все равно будет какой-то временной разрыв между основной базой и ее репликой.
Как это нивелировать? Ответа не нашел.
- Для ответа в этой теме необходимо авторизоваться.