Як відновити помилку накопичувача в конфігурації RAID 5?

Цього ранку диск не вдався на нашому сервері баз даних. Масив накопичувачів (3 диски) встановлюється в конфігурації RAID 5.

Поки ми чекаємо заміни накопичувача, ми готуємося до стратегії відновлення. Користувачі продовжують працювати над системою, хоча і дуже повільно (не знаю, чому ??).

Як встановити новий накопичувач - чи будуть дані цього накопичувача автоматично перебудовуватися з паритету чи є ще один процес, який слід слідкувати?

Редагувати: Це апаратний RAID-контролер. (Дякую за відповіді поки що, вдячні)

Система працює дуже повільно, оскільки вона має реконструювати відсутні дані, що передбачає додатковий процесор та введення / виведення.

Якщо у вас відсутній диск у конфігурації RAID-5, у вас немає стратегії відновлення . Якщо інший диск зійде, ви втратите свої дані . Бігайте, не ходіть, до найближчого постачальника, від якого ви можете отримати сумісну частину, покриту гарантією виробника, що доставляється терміновим кур'єром у той же день. Якщо постачальник, у якого ви придбали масив, вже знаходиться в процесі отримання деталі, дістаньте обидві частини, а іншу схойте як запасну.

Якщо у вас використовується RAID-5 для виробничої системи, слід розглянути можливість залишити запасний диск у масиві як гарячий запас.

Додано - Якщо ваші журнали не знаходяться на окремому томі (фізично окремі диски), перемістіть їх до окремого набору дисків, навіть лише до однієї дзеркальної пари. Це також буде виграшів від продуктивності, якщо ваша база даних має будь-яке значне навантаження, оскільки суперечка щодо обсягів журналу непропорційно погано впливає на продуктивність.

Якщо це можливо, ви також можете зробити вашу базу даних більш надійною, виконавши наступні дії:

1. Вимкніть базу даних.
2. Резервне копіювання бази даних.
3. Перемістіть журнали до фізично окремого набору дисків (переконайтеся, що ви переконфігурували базу даних, щоб вона знала, куди журнали переміщені).
4. Перезавантажте базу даних та додаток.

Якщо у вас є журнали на окремому томі, ви можете відновити і прокрутити назад із резервної копії, якщо і лише тоді, коли несправність диска не загрожує журналам. Журнали бази даних повинні бути на окремому томі диска з (серед інших) наступних причин:

• Шаблони використання журналів переважно послідовні, додаючи записи журналу до кінця файлу (файл фактично є буферним дзвоном). Це означає, що велика кількість записів журналу може бути швидко записана, оскільки в ній мало активності пошуку диска.

• Якщо вони обмінюються фізичними дисками з великим навантаженням з випадковим доступом (наприклад, таблиці транзакцій та індекси), вони будуть сповільнені непропорційно, оскільки діяльність, яка шукає голову, порушує послідовне записування.

• Наявність журналів на окремому томі майже завжди є виграшним показником і потрібна лише одна дзеркальна пара для журналів, щоб підтримувати досить велике навантаження. Це означає, що апаратне забезпечення для цього коштує досить дешево, тому для великої продуктивності та виграшу надійності є невеликі витрати.

• Якщо масив даних знизиться, журнали не втрачаються. Якщо у вас є правильна стратегія резервного копіювання, ви можете відновити її з резервної копії та скотити вперед з журналів. Це означає, що цілий масив може спуститися на сервер, не будучи жодної точки відмови. І журнал, і масиви даних повинні одночасно виходити з ладу, щоб викликати втрату даних.

1) Резервне копіювання.

Зараз жодних даних не втрачено. Якщо ваші резервні копії зараз не оновлюються.

2) Прочитайте посібник, зателефонуйте до продавця тощо.

У різних системах RAID є різні кроки щодо заміни диска, і якщо ви зробите неправильно, ви ризикуєте знищити весь масив. Не знаючи, яке саме апаратне / програмне забезпечення RAID у вас є, ми можемо лише здогадуватися про необхідні кроки.

Крім того, повільна продуктивність пояснюється тим, що RAID 5 у деградованому стані (тобто: один диск мертвий) має жахливу ефективність читання. Наскільки жахливо залежить від того, як зберігається паритет і який диск загинув, але "гарна" новина - повільна продуктивність з одним диском, що вийшов, - відома проблема і не викликає паніки.

Спочатку я прочитав би посібник для апаратного / програмного забезпечення, яке ви використовуєте - розділ для відновлення несправностей :)

Потрібно бути простим питанням заміни диска та відновлення масиву.

Найважливішим моментом у таких випадках є те, що диск слід замінити якомога швидше, оскільки якщо інший диск вийде з ладу, ви, ймовірно, втратите дані. Також слід вирішити причину збою - це було через те, що диск старів? Чи слід замінювати інші? Або це було через сплеск електроенергії, тепла чи вібрації?

Наскільки я розумію RAID5, коли ваш замінник вийшов з ладу, він автоматично перебудовується з інформації, що зберігається на двох інших. Від того, чи зможете ви «замінити» новий диск на місце, залежить від вашої системи - можливо, вам доведеться спочатку вимкнути живлення. Так чи інакше, враховуючи відносно низьку вартість накопичувачів та важливість ваших даних (відображається в першу чергу рішенням про використання RAID5), ви дійсно повинні мати запасний привід, сісти в ящик, готовий до такої події .

Нещодавно я створив для себе новий ПК для розробки та налаштував основні диски даних під RAID5. Я замовив ще один привід, ніж потрібно, так що я приготував запас до цього надзвичайного моменту (що, сподіваюся, не станеться)

Тепер ви задали це питання, я вважаю, що краще прочитати ще кілька питань.

Повністю залежить від системи. Що говорять посібники? Чи повністю підтримує ваше обладнання гаряче підключення нових дисків від контролера до відсіку? У вас є останні резервні копії?

Повідомлення NXC це добре підсумовує. На випадок, якщо ви не заміните несправний диск до другої помилки, все ж є шанс відновити майже все (іноді все) спеціалізованою службою відновлення. Дані все ще є на дисках, і несправний диск, як правило, може бути відновлений до життя в спеціалізованій лабораторії з належним обладнанням. Однак ціна на цю послугу досить висока. Наявність запасного диска та належне резервне копіювання (згідно з пропозицією NXC) - це, безумовно, шлях у майбутньому.