Які практики ви дотримуєтесь, щоб уникнути неправильних оновлень даних у великих базах даних?

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

Однак це може працювати добре, поки розмір БД не складе кількох ГБ. Коли розмір БД величезний, резервне копіювання триватиме тривалий час. Назвіть кілька найкращих практик, яких слід дотримуватися в таких ситуаціях, щоб уникнути пошкодження логічних даних через логічні проблеми при розгортанні коду?

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

Якщо ви можете внести зміни до всіх записів, а не конкретних записів, бажано.

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

Якщо ви можете вставити, то краще.

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

Якщо ви можете уникнути видалення, бажано.

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

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

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

1. Ваш запис не існує.
2. Ваш запис існує, але він уже змінений.
3. Ваш запис існує і потребує змін.

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

Резервні копії

Це жодним чином не виправдає вас зробити резервну копію перед виконанням будь-якого оновлення у виробничому середовищі! Хоча навіть із резервною копією, я вважаю, що не потрібно використовувати резервну копію. Втрата даних не може бути можливою навіть у гіршому випадку .

Висновок

Ви не завжди зможете мати це по-своєму. Таблиця схем, ймовірно, не визначається вами, і як така це означає, що типи оновлень, які ви можете розраховувати виконати, будуть і складними, і ризикованими. Хоча, якщо у вас є якісь відповіді щодо цього питання, це допомагає пам’ятати про ці моменти, оскільки вони роблять будь-які оновлення простими та без істотного ризику.

Удачі!

У цей момент ви повинні використовувати комерційну систему БД комерційної підтримки, яка підтримує знімки (Oracles називає це Flashback ) - це саме та річ, для якої вони потрібні.

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

Це масивна область, тому очікуйте, що це питання буде закрито в досить короткі терміни, але, вгорі голови (як колишня DBA в базах даних yuge):

Март / сховище

Ви можете зменшити певний ризик, якщо у вас є окрема база даних для оновлень та окрема база даних, яку використовують усі. Тоді це лише випадок копіювання даних з однієї БД в іншу після того, як відбулися різні перевірки. Mart / сховище - це, як це іноді описується, але у вас може бути первинний / вторинний, master / slave etc.

Вихідний код

Для всього, що може змінитися, майте вихідний код, який стосується способу оновлення даних. Скільки з них у вас залежить від БД до БД, але у вас може бути один для кожного користувача, роль, канал даних, модуль коду тощо.

Створення / оновлення дати

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

ETL

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

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

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

Поточний час відновлення

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

Аудит

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

Історія

Для деяких критичних таблиць під час оновлення береться копія відповідного рядка, щоб дані могли бути відновлені за потреби.

Перевірка даних

Переконайтеся, що основні перевірки перевірки даних здійснюються перед їх збереженням - вище і вище основних перевірок типу даних.

Референтна цілісність

Цілісність посилань не є срібною кулею, але вона може допомогти забезпечити чітку структурованість даних.

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

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

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