يتناول هذا القسم بصورة عامة النسخ الاحتياطية وعمليات الاستعادة في ClickHouse. للحصول على وصف أكثر تفصيلًا لكل طريقة من طرق النسخ الاحتياطي، راجع الصفحات المخصصة للطرق المختلفة في الشريط الجانبي.
المقدمة
MergeTree وتحتوي على أكثر من
50 غيغابايت من البيانات. ومع ذلك، لا تغطي وسائل الحماية هذه جميع الحالات الممكنة، وقد
تظل المشكلات واردة.
للحد بفعالية من الأخطاء البشرية المحتملة، ينبغي لك أن تُعد بعناية
استراتيجية للنسخ الاحتياطي لبياناتك واستعادتها مسبقًا.
تختلف الموارد المتاحة ومتطلبات الأعمال من شركة إلى أخرى، لذلك
لا يوجد حل شامل واحد للنسخ الاحتياطي والاستعادة في ClickHouse يناسب
كل الحالات. فما يصلح لغيغابايت واحد من البيانات على الأرجح لن يصلح لعشرات
البيتابايتات من البيانات. وهناك مجموعة متنوعة من الأساليب الممكنة، لكل منها مزاياها
وعيوبها، وهي معروضة في هذا القسم من الوثائق. ومن الجيد
استخدام عدة أساليب بدلًا من الاكتفاء بأسلوب واحد، لتعويض أوجه القصور
المختلفة في كل منها.
ضع في اعتبارك أنه إذا أنشأت نسخة احتياطية لشيء ما ولم تحاول استعادته مطلقًا،
فمن المحتمل ألا تعمل الاستعادة على النحو الصحيح عندما تحتاج إليها فعلًا (أو على
الأقل ستستغرق وقتًا أطول مما يمكن للأعمال تحمله). لذا، أيًّا كانت آلية النسخ الاحتياطي
التي تختارها، احرص على أتمتة عملية الاستعادة أيضًا، والتدرّب
عليها بانتظام على عنقود ClickHouse احتياطي.
| الصفحة | الوصف |
|---|---|
| النسخ الاحتياطي/الاستعادة باستخدام قرص محلي أو S3 disk | يوضح النسخ الاحتياطي/الاستعادة إلى قرص محلي أو S3 disk أو منهما |
| النسخ الاحتياطي/الاستعادة باستخدام S3 endpoint | يوضح النسخ الاحتياطي/الاستعادة إلى S3 endpoint أو منه |
| النسخ الاحتياطي/الاستعادة باستخدام AzureBlobStorage | يوضح النسخ الاحتياطي/الاستعادة إلى Azure blob storage أو منه |
| طرق بديلة | يناقش طرق النسخ الاحتياطي البديلة |
| Snapshot backup | لقطات خفيفة لجداول SharedMergeTree باستخدام Cloud Object Storage |
- كاملة أو تزايدية
- متزامنة أو غير متزامنة
- متوازية أو غير متوازية
- مضغوطة أو غير مضغوطة
- تستخدم مجموعات مسمى
- محمية بكلمة مرور
- مأخوذة من جداول النظام أو جداول السجل أو جداول إدارة الوصول
أنواع النسخ الاحتياطية
- النسخ الاحتياطية الكاملة لقواعد البيانات الأصغر أو للبيانات المهمة.
- النسخ الاحتياطية التزايدية لقواعد البيانات الأكبر أو عندما تكون هناك حاجة إلى إجراء النسخ الاحتياطية بشكل متكرر وبأقل تكلفة.
- كليهما، مثلًا نسخ احتياطية كاملة أسبوعية ونسخ احتياطية تزايدية يومية.
النسخ الاحتياطية المتزامنة مقابل غير المتزامنة
BACKUP وRESTORE بـ ASYNC. في هذه الحالة، يعيد
أمر النسخ الاحتياطي النتيجة فورًا، وتعمل عملية النسخ الاحتياطي في الخلفية.
إذا لم يُعلَّم الأمران بـ ASYNC، فستكون عملية النسخ الاحتياطي متزامنة،
ويبقى الأمر قيد الانتظار حتى يكتمل النسخ الاحتياطي.
النسخ الاحتياطية المتوازية وغير المتوازية
النسخ الاحتياطية المضغوطة مقابل غير المضغوطة
compression_method وcompression_level.
عند إنشاء نسخة احتياطية، يمكنك تحديد ما يلي:
استخدام المجموعات المسماة
- إخفاء بيانات الاعتماد عن المستخدمين الذين لا يملكون امتيازات المسؤول
- تبسيط الأوامر من خلال تخزين التهيئة المعقدة مركزيًا
- الحفاظ على الاتساق عبر العمليات
- تجنب كشف بيانات الاعتماد في سجلات الاستعلام
أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول
_log (على سبيل المثال،
query_log وpart_log)، واستعادتها مثل أي جدول آخر.
إذا كانت حالة الاستخدام لديك تعتمد على تحليل البيانات التاريخية - على سبيل المثال، استخدام query_log
لتتبّع أداء الاستعلامات أو استكشاف المشكلات وإصلاحها - فمن المستحسن تضمين هذه
الجداول في استراتيجية النسخ الاحتياطي. ومع ذلك، إذا لم تكن البيانات التاريخية في هذه الجداول
مطلوبة، فيمكن استبعادها لتوفير مساحة تخزين النسخ الاحتياطية.
تخضع جداول النظام المرتبطة بإدارة الوصول، مثل users وroles وrow_policies و
settings_profiles وquotas، لمعالجة خاصة أثناء عمليات النسخ الاحتياطي والاستعادة.
فعند تضمين هذه الجداول في نسخة احتياطية، يُصدَّر محتواها إلى ملف خاص
accessXX.txt، يتضمّن تعليمات SQL المكافئة لإنشاء
كيانات الوصول وتهيئتها. وعند الاستعادة، تقوم عملية الاستعادة
بتفسير هذه الملفات وإعادة تطبيق أوامر SQL لإعادة إنشاء المستخدمين،
والأدوار، والتهيئات الأخرى. وتضمن هذه الميزة إمكانية
أخذ نسخة احتياطية من تهيئة التحكم في الوصول
في عنقود ClickHouse واستعادتها كجزء من
الإعداد العام للعنقود.
لا تعمل هذه الوظيفة إلا مع التهيئات المُدارة من خلال أوامر SQL
(ويُشار إليها باسم “إدارة التحكم في الوصول والحسابات المعتمدة على SQL”).
أما تهيئات الوصول المعرّفة في ملفات تهيئة خادم ClickHouse (مثل users.xml)
فلا تُضمَّن في النسخ الاحتياطية ولا يمكن استعادتها بهذه الطريقة.
البنية العامة
ملخص الأوامر
| الأمر | الوصف | |
|---|---|---|
BACKUP | يُنشئ نسخة احتياطية للكائنات المحددة | |
RESTORE | يستعيد الكائنات من نسخة احتياطية | |
TABLE [db.]table_name [AS [db.]table_name_in_backup] | يُنشئ نسخة احتياطية لجدول محدد أو يستعيده (مع إمكانية إعادة تسميته) | |
[PARTITION[S] partition_expr [,...]] | يُنشئ نسخة احتياطية لأقسام محددة من الجدول أو يستعيدها فقط | |
DICTIONARY [db.]dictionary_name [AS [db.]name_in_backup] | يُنشئ نسخة احتياطية لكائن قاموس أو يستعيده | |
DATABASE database_name [AS database_name_in_backup] | يُنشئ نسخة احتياطية لقاعدة بيانات كاملة أو يستعيدها (مع إمكانية إعادة تسميتها) | |
TEMPORARY TABLE table_name [AS table_name_in_backup] | يُنشئ نسخة احتياطية لجدول مؤقت أو يستعيده (مع إمكانية إعادة تسميته) | |
VIEW view_name [AS view_name_in_backup] | يُنشئ نسخة احتياطية لطريقة عرض أو يستعيدها (مع إمكانية إعادة تسميتها) | |
[EXCEPT TABLES ...] | يستبعد جداول محددة عند إنشاء نسخة احتياطية لقاعدة بيانات | |
ALL | يُنشئ نسخة احتياطية لكل شيء أو يستعيده (جميع قواعد البيانات والجداول وما إلى ذلك). قبل الإصدار 23.4 من ClickHouse، كان ALL قابلاً للتطبيق فقط على الأمر RESTORE. | |
[EXCEPT {TABLES|DATABASES}...] | يستبعد جداول أو قواعد بيانات محددة عند استخدام ALL | |
[ON CLUSTER 'cluster_name'] | ينفّذ النسخ الاحتياطي أو الاستعادة على مستوى عنقود ClickHouse | |
TO|FROM | الاتجاه: TO لوجهة النسخ الاحتياطي، وFROM لمصدر الاستعادة | |
File('<path>/<filename>') | يخزّن في نظام الملفات المحلي أو يستعيد منه | |
Disk('<disk_name>', '<path>/') | يخزّن على قرص مُهيّأ أو يستعيد منه | |
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>') | يخزّن في Amazon S3 أو وحدة تخزين متوافقة مع S3، أو يستعيد منها | |
[SETTINGS ...] | انظر أدناه للاطلاع على القائمة الكاملة للإعدادات | |
[ASYNC] | يجعل العملية تعمل بشكل غير متزامن (وتُرجع فورًا معرّفًا يمكنك مراقبته) |
الإعدادات
| الإعداد | الوصف | القيمة الافتراضية |
|---|---|---|
id | معرّف عملية النسخ الاحتياطي أو الاستعادة. إذا لم يُحدَّد، فسيُستخدَم UUID مُولَّد عشوائيًا. وإذا كانت هناك عملية قيد التشغيل بالفعل بالمعرّف نفسه، فسيتم إطلاق استثناء. | |
compression_method | يحدّد أسلوب الضغط للنسخة الاحتياطية. راجع قسم “مرمّزات ضغط الأعمدة” | |
compression_level | يحدّد مستوى الضغط للنسخة الاحتياطية | |
password | كلمة مرور أرشيف النسخة الاحتياطية. لا يُدعم ذلك إلا لأرشيفات ZIP (.zip, .zipx). | |
base_backup | وجهة النسخة الاحتياطية الأساسية المستخدَمة للنسخ الاحتياطية التزايدية. مثال: Disk('backups', '1.zip') | |
use_same_password_for_base_backup | ما إذا كان ينبغي أن يرث أرشيف النسخة الاحتياطية الأساسية كلمة المرور من الاستعلام. | |
structure_only | إذا كان مُمكّنًا، فسيتم فقط إجراء نسخ احتياطي لعبارات CREATE أو استعادتها من دون بيانات الجدول الفعلية. | |
storage_policy | سياسة التخزين للجداول التي تتم استعادتها. راجع “استخدام عدة أجهزة تخزين كتلية لتخزين البيانات. ينطبق هذا فقط على الأمر RESTORE. ولا يسري إلا على الجداول التي تستخدم محركًا من عائلة MergeTree. | |
allow_non_empty_tables | يسمح RESTORE TABLE بإدراج البيانات في الجداول غير الفارغة. سيؤدي ذلك إلى دمج البيانات الموجودة مسبقًا في الجدول مع البيانات المستخرجة من النسخة الاحتياطية. لذلك قد يتسبب هذا الإعداد في تكرار البيانات داخل الجدول، لذا استخدمه بحذر. | 0 |
backup_restore_keeper_max_retries | الحد الأقصى لعدد إعادة المحاولة لعمليات [Zoo]Keeper أثناء تنفيذ عملية BACKUP أو RESTORE. يجب أن يكون كبيرًا بما يكفي حتى لا تفشل العملية بأكملها بسبب عطل مؤقت في [Zoo]Keeper. | 1000 |
backup_restore_keeper_retry_initial_backoff_ms | مهلة التراجع الأولية لعمليات [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | 100 |
backup_restore_keeper_retry_max_backoff_ms | الحد الأقصى لمهلة التراجع لعمليات [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | 5000 |
backup_restore_failure_after_host_disconnected_for_seconds | إذا لم يُعِد أي مضيف أثناء عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER إنشاء عقدة ephemeral الخاصة به المسماة ‘alive’ في ZooKeeper خلال هذه المدة، فستُعتبر عملية النسخ الاحتياطي أو الاستعادة بأكملها فاشلة. يجب أن تكون هذه القيمة أكبر من أي مدة معقولة قد يحتاجها المضيف لإعادة الاتصال بـ ZooKeeper بعد حدوث عطل. ويعني الصفر عدم وجود حد. | 3600 |
backup_restore_keeper_max_retries_while_initializing | الحد الأقصى لعدد مرات إعادة المحاولة لعمليات [Zoo]Keeper أثناء تهيئة عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER. | 20 |
backup_restore_keeper_max_retries_while_handling_error | الحد الأقصى لعدد مرات إعادة المحاولة لعمليات [Zoo]Keeper عند التعامل مع خطأ في عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER. | 20 |
backup_restore_finish_timeout_after_error_sec | المدة التي ينبغي أن تنتظرها العقدة البادئة حتى تستجيب العُقد الأخرى لعقدة ‘الخطأ’ وتتوقف عن العمل على عملية BACKUP ON CLUSTER أو RESTORE ON CLUSTER الحالية. | 180 |
backup_restore_keeper_value_max_size | الحد الأقصى لحجم بيانات عقدة [Zoo]Keeper أثناء النسخ الاحتياطي | 1048576 |
backup_restore_batch_size_for_keeper_multi | الحد الأقصى لحجم الدفعة للطلب المتعدد إلى [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | 1000 |
backup_restore_batch_size_for_keeper_multiread | الحد الأقصى لحجم الدفعة لطلب القراءة المتعددة إلى [Zoo]Keeper أثناء النسخ الاحتياطي أو الاستعادة | 10000 |
backup_restore_keeper_fault_injection_probability | الاحتمال التقريبي لفشل طلب إلى Keeper أثناء النسخ الاحتياطي أو الاستعادة. يجب أن تكون القيمة ضمن النطاق [0.0f, 1.0f] | 0 |
backup_restore_keeper_fault_injection_seed | 0 لاستخدام بذرة عشوائية، وإلا فتُستخدم قيمة الإعداد | 0 |
backup_restore_s3_retry_attempts | إعداد لـ Aws::Client::RetryStrategy؛ إذ يُجري Aws::Client محاولات إعادة بنفسه، وتعني القيمة 0 عدم إجراء أي محاولات إعادة. ينطبق ذلك فقط على النسخ الاحتياطي/الاستعادة. | 1000 |
max_backup_bandwidth | الحد الأقصى لسرعة القراءة، بالبايت في الثانية، لنسخة احتياطية معيّنة على الخادم. وتعني القيمة صفر عدم وجود حد. | 0 |
max_backups_io_thread_pool_size | يستخدم ClickHouse خيوط التنفيذ من مجموعة خيوط الإدخال/الإخراج الخاصة بالنسخ الاحتياطية لتنفيذ عمليات الإدخال/الإخراج لنسخ S3 الاحتياطية. ويحدّد max_backups_io_thread_pool_size الحد الأقصى لعدد خيوط التنفيذ في المجموعة. | 1000 |
max_backups_io_thread_pool_free_size | إذا تجاوز عدد مؤشرات الترابط الخاملة في مجمع مؤشرات ترابط الإدخال/الإخراج للنسخ الاحتياطية القيمة max_backup_io_thread_pool_free_size، فسيحرر ClickHouse الموارد التي تشغلها مؤشرات الترابط في حالة الخمول ويقلّص حجم المجمع. ويمكن إنشاء مؤشرات الترابط مرة أخرى عند الحاجة. | 0 |
backups_io_thread_pool_queue_size | الحد الأقصى لعدد المهام التي يمكن جدولتها على تجمّع مؤشرات ترابط الإدخال/الإخراج الخاص بالنسخ الاحتياطية. يُنصح بالإبقاء على قائمة الانتظار هذه غير محدودة بسبب المنطق الحالي للنسخ الاحتياطي في S3. ملاحظة: تعني القيمة 0 (الافتراضية) أنها غير محدودة. | 0 |
backup_threads | الحد الأقصى لعدد الخيوط لتنفيذ طلبات BACKUP. | |
max_backup_bandwidth_for_server | الحد الأقصى لسرعة القراءة، بالبايت في الثانية، لجميع النسخ الاحتياطية على الخادم. تعني القيمة صفر عدم وجود حد. | 0 |
shutdown_wait_backups_and_restores | إذا ضُبطت القيمة على true، فسوف ينتظر ClickHouse اكتمال النسخ الاحتياطية وعمليات الاستعادة الجارية قبل إيقاف التشغيل. | 1 |
| الإعداد | الوصف | القيمة الافتراضية |
|---|---|---|
use_same_s3_credentials_for_base_backup | ما إذا كان يجب أن ترث النسخة الاحتياطية الأساسية إلى S3 بيانات الاعتماد من الاستعلام. يعمل فقط مع S3. | |
s3_storage_class | فئة التخزين المستخدمة للنسخ الاحتياطي على S3. على سبيل المثال: STANDARD |
| الإعداد | الوصف | القيمة الافتراضية | ||
|---|---|---|---|---|
azure_attempt_to_create_container | عند استخدام Azure Blob Storage، ما إذا كانت ستتم محاولة إنشاء الحاوية المحددة إذا لم تكن موجودة. | true |
الإدارة واستكشاف الأخطاء وإصلاحها
id وstatus، ويمكن استخدام هذا الـid
للحصول على حالة النسخ الاحتياطي. ويُعد هذا مفيدًا جدًا للتحقق من تقدّم عمليات
النسخ الاحتياطي ASYNC الطويلة. يوضّح المثال أدناه فشلًا حدث عند محاولة
استبدال ملف نسخ احتياطي موجود:
system.backups، تُسجَّل أيضًا جميع عمليات النسخ الاحتياطي والاستعادة في جدول سجل النظام
system.backup_log: