Налаштування

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

Тепер. Я добре знаю, що це не дуже добре:

1. знищити -9 процес (погано)
2. мимовільно витягніть шнур живлення на працюючий комп'ютер або сервер (гірше)

Однак іноді просто потрібно. Іноді процес просто не відповідає, незалежно від того, що ви робите, а іноді комп'ютер просто не реагує, незалежно від того, що ви робите.

Припустимо, що система працює з Apache 2, MySQL 5, PHP 5 та Python 2.6.5 через mod_wsgi.

Примітка: Мене найбільше цікавить Mac OS X, але відповідь, що стосується будь-якої системи UNIX, допоможе мені.

Моя стурбованість

Кожен раз, коли мені доводиться робити будь-яке з них, особливо друге, я протягом певного періоду часу дуже переживаю, щоб щось було порушено. Деякий файл десь може бути пошкодженим - хто знає, який файл? На комп'ютері є понад 1 000 000 файлів.

Я часто використовую OS X, тому запускаю операцію "Перевірити диск" через Disk Utility. Він не повідомить про проблеми, але мене все ще турбує це.

Що робити, якщо якийсь файл конфігурації десь накрутив. Або ще гірше, що якщо двійковий файл десь пошкоджений. Або файл сценарію десь пошкоджений. Що робити, якщо деяке обладнання пошкоджено?

Що робити, якщо я не дізнаюся про це до наступного місяця, за критичного сценарію, коли корупція чи збитки спричиняють катастрофу?

Або що робити, якщо цінні дані вже втрачені?

Моя надія

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

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

Мої питання

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

Моє запитання полягає в тому, що для обох цих сценаріїв, що саме може піти не так, і які кроки потрібно вжити, щоб виправити це?

У мене складається враження, що одне, що може піти не так - деякі програми, можливо, не передали свої дані на диск, тому будь-які дуже недавні дані, які повинні були бути записані на диск (скажімо, за кілька секунд до вимкнення живлення ) може бути загублено. А як щодо цього? І чи може ця проблема 5-секундної втрати даних накрутити систему?

А як щодо корупції випадкових файлів, що ховаються десь у величезному лісі файлів на моїх жорстких дисках?

Як щодо пошкодження обладнання?

Що б мені найбільше допомогло

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

2. Пояснення всіх речей, які можуть піти не так у цих сценаріях, а також (приблизно, звичайно) ймовірностей (тобто це дуже малоймовірно, але це, ймовірно) ...

3. Опис заходів, що застосовуються в сучасному апаратному забезпеченні, операційних системах та програмному забезпеченні, щоб запобігти пошкодженню або пошкодженню при виникненні цих сценаріїв. (щоб потішити мене)

4. Інструкції, що робити після вбивства -9 або відключення живлення, крім "перевірки диска", щоб справді переконатися, що десь на диску не пошкоджено чи не пошкоджено.

5. Заходи, які можна вжити для зміцнення налаштувань комп’ютера, щоб, якщо щось потрібно було вбити або витягнути живлення, будь-який потенційний збиток зменшиться.

6. Деяка інформація про двійкові файли - чи не правда, що бінарний файл apache або бібліотека може мати випадковий байт або два пошкоджені в середині, які не з’являться і не спричинить проблему пізніше? Як я можу запевнити себе, що цього не сталося внаслідок підтягування сили або вбивства?

Дуже дякую!

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

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

Тимчасові файли в / tmp автоматично відміняються, якщо вони знаходяться у форматі tmpfs, але у вас все одно можуть бути закладені файли блокування для видалення, як-от замок та .parentlock для firefox.

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

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

Тепер, якщо у вас є RAID-масив, він має всі види буферів пам'яті для підвищення продуктивності та забезпечення надійності при збої живлення. Швидше за все, ваша файлова система не буде знати про кеші в пристрої та їхній стан, тому вона вважає, що на диску зроблено зміна, але вона все ще знаходиться десь у кеші RAID. То що відбувається, коли влада вмирає? Сподіваємось, у вас у корпусі RAID є функціональний акумулятор, який ви стежите за ним. В іншому випадку у вас є пошкоджена файлова система для fsck.

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

При несподіваному відключенні файли, які мають бути пошкоджені, - це файли, відкриті для запису. У більшості систем у будь-який момент часу ви, ймовірно, не пишете у файл. Ймовірно.

1 вбивство -9

є POSIX SIGKILL і залежить від реалізації. Процес, який отримує цей сигнал, не дасть можливість впоратися з ним.

1 Вимкнено живлення

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

Від wdc.com (google: site: wdc.com Захисна стоянка для голови)

Втрачається живлення: жорсткий диск скидається. Голова припаркована в зоні посадки, використовуючи енергію веретена. Шпиндельний мотор зупинився.

2 - що може піти не так

файли, залишені відкритими, видаються неповно. Якщо файл буде відкритий для запису, відбудеться пошкодження даних. Запис файлів у сучасному апаратному забезпеченні швидкий, а сучасні ПК, як правило, не піддаються навантаженню. Це як ходити з зав'язаними очима тихою сільською дорогою. Більшу частину часу у вас буде добре.

3 - контрзаходи

дивіться вище, що роблять диски.

Подивіться файлові системи, що перебувають у перекладі, зараз вони нормальні: http://en.wikipedia.org/wiki/Journaling_file_system

Програмне забезпечення, наприклад MS Word або vi, запише у тимчасовий файл, а не в оригінал. Мета - ніколи не залишати систему в стані, коли на диску немає послідовної копії.

Windows зберігає копії реєстру (це занадто важливо) Win2k, тому я не впевнений, які нові механізми MS)

4 - що робити

У порядку складності (легко-важко)

• Зберігайте резервні копії
• Перевірте, над чим ви востаннє працювали
• Завантажтеся з окремого диска та шукайте останні змінені дати / часи, щоб з’ясувати, що може робити система під час аварії
• Завантажте з окремого диска і порівняйте md5суми всіх ваших файлів з офлайновою копією.

Зберігати резервні копії - це найбільш відповідна відповідь, хороші резервні копії повинні перейти до попередньо модифікованої версії.

5

Надмірна потужність? Освіта кінцевих користувачів? покласти стрічку та картон над кнопкою живлення?

6

Немає апаратних несправностей, пошкоджені драйвери диска, зламане ядро ​​ОС, відсутність контрольних сум або збої під час оновлення, бінарні файли та бібліотеки не відкриваються для читання-запису, щоб вони не пошкоджувалися. Буває, але це рідко.

Що стосується вбивства -9, то це посилає сигнал процесу, щоб він "помер" прямо на місці. Процес гине (якщо тільки він не перебуває у безперервному сні; в цьому випадку він стає зомбі). Жодні файли не закриті, дані не списуються, і програма не може вловлювати цей сигнал і робити щось інше. Ні прибирання, ні нічого: воно просто гине.

Файлові системи сьогодні дуже надійні; такі речі, як XFS, JFS, ext3 та ext4, мають журнали та інші речі, щоб зберегти недоторканими метадані файлової системи.

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

У мене Mac Mini люди, схоже, люблять вимикати холод (незалежно від того, скільки разів я їм кажу .....), і це просто продовжує тривати.

Здебільшого ,, доки ви не покладаєтесь на вбивство -9 або відключення живлення регулярно, я б не хвилювався надто сильно. У минулому все було набагато гірше; Я б більше хвилювався (наприклад) Solaris 2.6, ніж я б про Solaris 10 (і так далі).

Функція "kill -9" не синхронізує очікувана операція вводу-виводу. Це часто не є проблемою, але якщо система перебуває під великим навантаженням вводу-виводу, ви можете втратити дані.

Його проблема більше стосується серверів, де контролер RAID (без кешованого кеша) може кешувати записи та втрачати ваші дані.

Редагування : Ще одне ... якщо ви залежите від мережевих накопичувачів і маєте відкриті ручки файлів, велика ймовірність залишити файл непослідовним або пошкодженим. У Windows класичний приклад цього, коли ви бачите це, коли користувачі встановлюють файли Outlook PST на спільний доступ і втрачають живлення або мережеву підключення.