Фізичні та логічні резервні копії - це два основні типи резервних копій із чіткими відмінностями та випадками використання, особливо при роботі з базами даних MySQL на службі реляційних баз даних Amazon (AWS) (RDS). Нижче наведено поглиблене пояснення та порівняння фізичних та логічних резервних копій для MySQL на AWS RDS.
Фізичні резервні копії
Фізичні резервні копії складаються з точних копій файлів та каталогів баз даних, які зберігають необроблені дані. Ці резервні копії схожі на знімок фактичної бази даних на рівні файлової системи. У фізичній резервній копії виготовляються копії файлів, таких як файли даних бази даних, таблиці, файли журналів та файли конфігурації. Зазвичай це робиться шляхом копіювання файлів безпосередньо з місця зберігання бази даних. Резервне копіювання - це, по суті, дзеркало фізичного стану бази даних на момент резервного копіювання.
Характеристики фізичних резервних копій:
- повнота та швидкість: Фізичні резервні копії дуже швидкі, оскільки вони передбачають копіювання файлів як-небудь без перетворення чи інтерпретації. Це робить їх придатними для великих баз даних, де швидке резервне копіювання та відновлення є критичними.
-Компактність: Оскільки це копію байтів для байтів, фізичні резервні копії зазвичай є більш компактними, ніж логічні резервні копії, які перетворюють дані в оператори SQL або текстовий формат.
- Гранильність відновлення: Фізичні резервні копії часто забезпечують відновлення на всій базі даних або просторі таблиць. Гранильність відновлення може відрізнятися залежно від використання двигуна зберігання.
- Відновлення: Відновлення фізичного резервного копіювання передбачає копіювання резервних файлів назад у вихідні місця. Це може бути простим, але вимагає, щоб весь набір файлів був недоторканим, оскільки відсутні файли можуть запобігти повному відновленню.
-Специфічне для середовища: Фізичні резервні копії включають інформацію, пов'язану з екземпляром, таку як шляхи файлів та дані, що стосуються системи, тому вони, як правило, відновлюються в середовищі, подібному до того, де було взято резервне копіювання.
- Офлайн або тивисті резервні копії: як правило, фізичні резервні копії вимагають, щоб база даних була в режимі офлайн або в послідовному стані (як знімка), щоб уникнути зйомки файлів, які є серединою, що може пошкодити резервну копію. Однак існують інструменти, які можуть зробити онлайн -фізичні резервні копії, координуючи з базою даних, наприклад, Percona Xtrabackup.
Обмеження фізичних резервних копій з AWS RDS для MySQL:
- AWS RDS не дозволяє традиційним фізичним резервним копіям (копії прямого рівня файлової системи), оскільки базова інфраструктура керується і не забезпечує доступ до файлової системи.
- Такі інструменти, як Percona Xtrabackup, які полегшують фізичні резервні копії для встановлення MySQL ON-PREM або Amazon EC2, не можуть використовуватися безпосередньо в екземплярах RDS.
- Натомість AWS RDS пропонує можливості знімків, які також є формою фізичної резервної копії, але керуються по -різному. Знімки фіксують весь екземпляр бази даних в момент часу і зберігаються та керуються AWS.
- Існує метод відновлення даних про фізичні резервні копії до RDS від Amazon S3, але це керується як відновлення від S3, а не резервного копіювання файлової системи RAW.
Логічні резервні копії
Логічні резервні копії витягують структуру бази даних та її вміст у логічні твердження, як правило, команди SQL, такі як створення таблиці та вставляють твердження, які можуть відтворити об'єкти та дані бази даних, коли резервна копія відновлюється. Ці резервні копії часто знаходяться у вигляді текстових файлів або двійкових логічних файлів дампів.
Характеристики логічних резервних копій:
-Формат: Логічні резервні копії незалежні від платформи і містять лише схему та дані бази даних, без деталей зберігання низького рівня, таких як файли даних або журнали.
- Використання та портативність: Оскільки логічні резервні копії містять команди для відтворення об'єктів бази даних та вставки даних, їх можна відновити в різних апаратних архітектурах, версіях MySQL або хмарних середовищах, що робить їх дуже портативними.
- Друкованість: Логічні резервні копії можна приймати на різних зернистих рівнях, таких як усіма базами даних, специфічними схемами або окремими таблицями.
- Онлайн -резервне копіювання: Логічні резервні копії можна виконати під час роботи в базі даних без простою, запитуючи базу даних для її структури та даних.
- Розмір і швидкість: Логічні резервні копії, як правило, повільніше і створюють більші файли, ніж фізичні резервні копії, оскільки дані перетворюються в логічний формат і повинні бути експортовані через двигун бази даних.
- Інструменти: Загальні інструменти для логічного резервного копіювання MySQL включають MySQLDUMP, MyDumper та SELECT ... в оператор Outfile SQL.
- Відновлення: Відновлення логічних резервних копій передбачає запуску сценаріїв або команд SQL на екземплярі MySQL, ефективно відновлюючи структуру бази даних та репопуляцію даних.
- Редагувати: Логічні резервні копії дозволяють модифікація перед реставрацією, такими як зміна значень даних або коригування структур таблиці, корисні для міграцій або перетворень.
AWS RDS та логічні резервні копії
- На AWS RDS для MySQL логічні резервні копії зазвичай проводяться за допомогою MySQLDUMP або подібних інструментів, що працюють із зовнішнього клієнта або екземпляра EC2, оскільки ви не можете отримати доступ до базової файлової системи.
- Логічні резервні копії підходять для менших наборів даних або для ситуацій, що вимагають портативності даних та схеми в різних середовищах.
- Автоматизовані резервні копії та знімки з логічних резервних копій AWS Complement, але логічні резервні копії дають більшу гнучкість у відновленні часткових даних або мігруючих.
Порівняння в контексті AWS RDS
- Фізичні резервні копії RDS здебільшого обробляються як автоматизовані знімки, які фіксують весь стан екземпляра бази даних та керуються AWS. AWS не дозволяє традиційним фізичним резервним копіям, безпосередньо копіюючи файли бази даних.
- Логічні резервні копії надають користувачам контроль та гнучкість для експорту та міграції вмісту бази даних, але вони мають обмеження у швидкості та потребують більше часу для відновлення великих наборів даних.
- Для відновлення аварій та швидкого відновлення цілих екземплярів автоматизовані знімки AWS та фізичні функції резервного копіювання є більш ефективними.
- Для міграції, трансформації даних або часткових відновлених, логічні резервні копії є кращими.
- Розмір резервного копіювання, як правило, менший і швидкість резервного копіювання для фізичних резервних копій, але логічні резервні копії мають кращу портативність та модифікацію.
- Логічні резервні копії дозволяють селективні резервні копії та часткові відновлення, тоді як фізичні резервні копії обробляють повне відновлення бази даних.
Підсумовуючи, фізичні резервні копії на MySQL на AWS RDS стосуються насамперед автоматизованої системи знімків, наданої AWS, яка копіює файли даних бази даних на рівні зберігання для швидкого, повного відновлення екземпляра. Логічні резервні копії передбачають експорт схеми та даних бази даних через оператори SQL, що дозволяє гнучкий рух та трансформацію даних, але зазвичай вартістю більш тривалого резервного копіювання та відновлення. Через обмеження управління AWS RDS, прямі фізичні резервні копії на рівні файлів неможливі для екземплярів RDS, спрямовуючи користувачів до знімків для фізичної резервної копії та MySqldump або подібних інструментів для логічних резервних копій. Обидва типи резервних копій виконують різні ролі і можуть поєднуватися в комплексних стратегіях резервного копіювання залежно від потреб бізнесу. Ця відмінність допомагає орієнтуватися на те, як створюються, зберігаються, зберігаються та відновлюються на середовищі MySQL AWS RDS.
Ці поняття ґрунтуються на методах резервного копіювання MySQL в цілому та адаптуються до обмежень та функцій, що керуються AWS RDS.