النسخ الاحتياطي والاستعادة في ClickHouse

يتناول هذا القسم بصورة عامة النسخ الاحتياطية وعمليات الاستعادة في ClickHouse. للحصول على وصف أكثر تفصيلًا لكل طريقة من طرق النسخ الاحتياطي، راجع الصفحات المخصصة للطرق المختلفة في الشريط الجانبي.

المقدمة

في حين أن النسخ المتماثل يوفر حماية من أعطال الأجهزة، فإنه لا يوفر حماية من الأخطاء البشرية: الحذف غير المقصود للبيانات، أو حذف الجدول الخطأ أو جدول في العنقود الخطأ، وأخطاء البرمجيات التي تؤدي إلى معالجة غير صحيحة للبيانات أو تلفها. في كثير من الحالات، ستؤثر أخطاء كهذه في جميع النسخ المتماثلة. يتضمن ClickHouse وسائل حماية مدمجة لمنع بعض أنواع الأخطاء، فعلى سبيل المثال، افتراضيًا لا يمكنك ببساطة حذف الجداول التي تستخدم محركًا من عائلة MergeTree وتحتوي على أكثر من 50 غيغابايت من البيانات. ومع ذلك، لا تغطي وسائل الحماية هذه جميع الحالات الممكنة، وقد تظل المشكلات واردة. للحد بفعالية من الأخطاء البشرية المحتملة، ينبغي لك أن تُعد بعناية استراتيجية للنسخ الاحتياطي لبياناتك واستعادتها مسبقًا. تختلف الموارد المتاحة ومتطلبات الأعمال من شركة إلى أخرى، لذلك لا يوجد حل شامل واحد للنسخ الاحتياطي والاستعادة في ClickHouse يناسب كل الحالات. فما يصلح لغيغابايت واحد من البيانات على الأرجح لن يصلح لعشرات البيتابايتات من البيانات. وهناك مجموعة متنوعة من الأساليب الممكنة، لكل منها مزاياها وعيوبها، وهي معروضة في هذا القسم من الوثائق. ومن الجيد استخدام عدة أساليب بدلًا من الاكتفاء بأسلوب واحد، لتعويض أوجه القصور المختلفة في كل منها.

ضع في اعتبارك أنه إذا أنشأت نسخة احتياطية لشيء ما ولم تحاول استعادته مطلقًا، فمن المحتمل ألا تعمل الاستعادة على النحو الصحيح عندما تحتاج إليها فعلًا (أو على الأقل ستستغرق وقتًا أطول مما يمكن للأعمال تحمله). لذا، أيًّا كانت آلية النسخ الاحتياطي التي تختارها، احرص على أتمتة عملية الاستعادة أيضًا، والتدرّب عليها بانتظام على عنقود ClickHouse احتياطي.

توضح الصفحات التالية بالتفصيل مختلف طرق النسخ الاحتياطي والاستعادة المتاحة في ClickHouse:

الصفحة	الوصف
النسخ الاحتياطي/الاستعادة باستخدام قرص محلي أو S3 disk	يوضح النسخ الاحتياطي/الاستعادة إلى قرص محلي أو S3 disk أو منهما
النسخ الاحتياطي/الاستعادة باستخدام S3 endpoint	يوضح النسخ الاحتياطي/الاستعادة إلى S3 endpoint أو منه
النسخ الاحتياطي/الاستعادة باستخدام AzureBlobStorage	يوضح النسخ الاحتياطي/الاستعادة إلى Azure blob storage أو منه
طرق بديلة	يناقش طرق النسخ الاحتياطي البديلة
Snapshot backup	لقطات خفيفة لجداول SharedMergeTree باستخدام Cloud Object Storage

يمكن للنسخ الاحتياطية أن تكون:

كاملة أو تزايدية
متزامنة أو غير متزامنة
متوازية أو غير متوازية
مضغوطة أو غير مضغوطة
تستخدم المجموعات المسماة
محمية بكلمة مرور
مأخوذة من جداول النظام أو جداول السجل أو جداول إدارة الوصول

أنواع النسخ الاحتياطية

يمكن أن تكون النسخ الاحتياطية إما كاملة أو تزايدية. فالنسخ الاحتياطية الكاملة تكون نسخة كاملة من البيانات، بينما تتضمن النسخ الاحتياطية التزايدية فقط التغييرات التي طرأت على البيانات منذ آخر نسخة احتياطية كاملة. تمتاز النسخ الاحتياطية الكاملة بأنها وسيلة استرداد بسيطة ومستقلة (عن النسخ الاحتياطية الأخرى) وموثوقة. ومع ذلك، قد يستغرق إكمالها وقتًا طويلًا، وقد تستهلك مساحة كبيرة. أما النسخ الاحتياطية التزايدية، فهي أكثر كفاءة من حيث الوقت والمساحة، لكن استعادة البيانات تتطلب توفر جميع النسخ الاحتياطية. اعتمادًا على احتياجاتك، قد ترغب في استخدام:

النسخ الاحتياطية الكاملة لقواعد البيانات الأصغر أو للبيانات المهمة.
النسخ الاحتياطية التزايدية لقواعد البيانات الأكبر أو عندما تكون هناك حاجة إلى إجراء النسخ الاحتياطية بشكل متكرر وبأقل تكلفة.
كليهما، مثلًا نسخ احتياطية كاملة أسبوعية ونسخ احتياطية تزايدية يومية.

النسخ الاحتياطية المتزامنة مقابل غير المتزامنة

يمكن أيضًا تعليم الأمرين BACKUP وRESTORE بـ ASYNC. في هذه الحالة، يعيد أمر النسخ الاحتياطي النتيجة فورًا، وتعمل عملية النسخ الاحتياطي في الخلفية. إذا لم يُعلَّم الأمران بـ ASYNC، فستكون عملية النسخ الاحتياطي متزامنة، ويبقى الأمر قيد الانتظار حتى يكتمل النسخ الاحتياطي.

النسخ الاحتياطية المتوازية وغير المتوازية

يتيح ClickHouse افتراضيًا إجراء النسخ الاحتياطية وعمليات الاستعادة بشكل متوازٍ. وهذا يعني أنه يمكنك بدء عدة عمليات نسخ احتياطي أو استعادة في الوقت نفسه. ومع ذلك، توجد إعدادات على مستوى الخادم تتيح لك تعطيل هذا السلوك. إذا ضبطت هذه الإعدادات على false، فلن يُسمح إلا بتشغيل عملية نسخ احتياطي أو استعادة واحدة فقط على العنقود في كل مرة. ويمكن أن يساعد ذلك في تجنب التنافس على الموارد أو التعارضات المحتملة بين العمليات. لمنع النسخ الاحتياطي/الاستعادة المتوازيين، يمكنك استخدام هذه الإعدادات على التوالي:

<clickhouse>
    <backups>
        <allow_concurrent_backups>false</allow_concurrent_backups>
        <allow_concurrent_restores>false</allow_concurrent_restores>
    </backups>
</clickhouse>

القيمة الافتراضية لكليهما هي true، لذا يُسمح افتراضيًا بإجراء عمليات النسخ الاحتياطي/الاستعادة المتوازية. عندما تكون هذه الإعدادات false على عنقود، لا يُسمح إلا بتشغيل عملية نسخ احتياطي/استعادة واحدة فقط على عنقود في كل مرة.

النسخ الاحتياطية المضغوطة مقابل غير المضغوطة

تدعم النسخ الاحتياطية في ClickHouse الضغط من خلال الإعدادين compression_method وcompression_level. عند إنشاء نسخة احتياطية، يمكنك تحديد ما يلي:

BACKUP TABLE test.table
  TO Disk('backups', 'filename.zip')
  SETTINGS compression_method='lzma', compression_level=3

استخدام المجموعات المسماة

تتيح لك المجموعات المسماة تخزين أزواج المفتاح والقيمة (مثل بيانات اعتماد S3، ونقاط النهاية، والإعدادات) بحيث يمكن إعادة استخدامها في عمليات النسخ الاحتياطي والاستعادة. وهي تساعد على:

إخفاء بيانات الاعتماد عن المستخدمين الذين لا يملكون امتيازات المسؤول
تبسيط الأوامر من خلال تخزين التهيئة المعقدة مركزيًا
الحفاظ على الاتساق عبر العمليات
تجنب كشف بيانات الاعتماد في سجلات الاستعلام

راجع “المجموعات المسماة” لمزيد من التفاصيل.

أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول

يمكن أيضًا تضمين جداول النظام في سير عمل النسخ الاحتياطي والاستعادة، لكن يعتمد تضمينها على حالة الاستخدام الخاصة بك. يمكن أخذ نسخ احتياطية من جداول النظام التي تخزّن بيانات تاريخية، مثل تلك التي تحمل اللاحقة _log (على سبيل المثال، query_log وpart_log)، واستعادتها مثل أي جدول آخر. إذا كانت حالة الاستخدام لديك تعتمد على تحليل البيانات التاريخية - على سبيل المثال، استخدام query_log لتتبّع أداء الاستعلامات أو استكشاف المشكلات وإصلاحها - فمن المستحسن تضمين هذه الجداول في استراتيجية النسخ الاحتياطي. ومع ذلك، إذا لم تكن البيانات التاريخية في هذه الجداول مطلوبة، فيمكن استبعادها لتوفير مساحة تخزين النسخ الاحتياطية. تخضع جداول النظام المرتبطة بإدارة الوصول، مثل users وroles وrow_policies و settings_profiles وquotas، لمعالجة خاصة أثناء عمليات النسخ الاحتياطي والاستعادة. فعند تضمين هذه الجداول في نسخة احتياطية، يُصدَّر محتواها إلى ملف خاص accessXX.txt، يتضمّن تعليمات SQL المكافئة لإنشاء كيانات الوصول وتهيئتها. وعند الاستعادة، تقوم عملية الاستعادة بتفسير هذه الملفات وإعادة تطبيق أوامر SQL لإعادة إنشاء المستخدمين، والأدوار، والتهيئات الأخرى. وتضمن هذه الميزة إمكانية أخذ نسخة احتياطية من تهيئة التحكم في الوصول في عنقود ClickHouse واستعادتها كجزء من الإعداد العام للعنقود. لا تعمل هذه الوظيفة إلا مع التهيئات المُدارة من خلال أوامر SQL (ويُشار إليها باسم “إدارة التحكم في الوصول والحسابات المعتمدة على SQL”). أما تهيئات الوصول المعرّفة في ملفات تهيئة خادم ClickHouse (مثل users.xml) فلا تُضمَّن في النسخ الاحتياطية ولا يمكن استعادتها بهذه الطريقة.

البنية العامة

-- core commands
BACKUP | RESTORE 
--- what to backup/restore (or exclude)
TABLE [db.]table_name           [AS [db.]table_name_in_backup] |
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 ...] |
[EXCEPT DATA FROM {TABLE|TABLES} ...] | -- BACKUP only, rejected on RESTORE
ALL [EXCEPT {TABLES|DATABASES}...] } [,...]
--- 
[ON CLUSTER 'cluster_name']
--- where to backup or restore to or from
TO|FROM 
File('<path>/<filename>') | 
Disk('<disk_name>', '<path>/') | 
S3('<S3 endpoint>/<path>', '<Access key ID>', '<Secret access key>', '<extra_credentials>') |
AzureBlobStorage('<connection string>/<url>', '<container>', '<path>', '<account name>', '<account key>')
--- additional settings
[SETTINGS ...]
[ASYNC]

راجع “ملخص الأوامر” لمزيد من التفاصيل عن كل أمر.

ملخص الأوامر

يُفصَّل أدناه كل أمر من الأوامر المذكورة أعلاه:

الأمر	الوصف
`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 ...]`	يستبعد جداول محددة عند إنشاء نسخة احتياطية لقاعدة بيانات
`[EXCEPT DATA FROM {TABLE\|TABLES} ...]`	(للأمر 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]`	يجعل العملية تعمل بشكل غير متزامن (وتُرجع فورًا معرّفًا يمكنك مراقبته)

نسخ جدول احتياطيًا دون بياناته

تُدرج EXCEPT DATA FROM {TABLE|TABLES} تعريف الجدول في النسخة الاحتياطية دون صفوفه. وتفيد مع الجداول التي يمكن إعادة توليد محتوياتها بعد الاستعادة، مثل جداول الهدف للعروض المُجسَّدة. تحدّد العبارة ما تكتبه BACKUP، لكنها لا تغيّر ما تستطيع RESTORE فعله بالنسخة الناتجة. فإذا كان بإمكان RESTORE إعادة إنشاء جدول، فإن استعادة تعريفه دون صفوف تُنشئ جدولًا فارغًا. ولا تجعل العبارة جدولًا قابلًا للاستعادة إذا لم يكن كذلك أصلًا؛ فإمكان تحويل تعريفه في النسخة الاحتياطية إلى جدول مجددًا يتوقف على المحرك، وبعض المحركات لا تدعم ذلك إطلاقًا: راجع المحركات التي لا تستطيع RESTORE إعادة إنشائها. يقتصر نطاق العبارة على العنصر الذي تُكتب عليه:

إذا استُخدمت مع عنصر DATABASE أو ALL، فيمكنها تحديد أي جدول يشمله ذلك العنصر في النسخة الاحتياطية:

BACKUP DATABASE mydb EXCEPT DATA FROM TABLES events, metrics TO Disk('backups', 'mydb/')

في هذه القائمة، ضع علامات الاقتباس العكسية (back-quote) حول اسم أي جدول أو قاعدة بيانات يُسمّى table أو dictionary أو view أو database أو all: إذ يُقرأ الاسم غير المقتبس بعد الفاصلة على أنه بداية العنصر التالي.

في العنصر الذي يخص كائنًا واحدًا (TABLE، DICTIONARY، VIEW، TEMPORARY TABLE)، لا يقع ضمن نطاقه سوى كائن ذلك العنصر، لذا يجب أن تذكره العبارة وحده. خصّص لكل جدول عنصرًا وعبارةً خاصين به:

-- Backs up both tables, without the data of `t1`
BACKUP TABLE mydb.t1 EXCEPT DATA FROM TABLE mydb.t1, TABLE mydb.t2 TO Disk('backups', 'tables/')

-- Rejected: the clause of the `mydb.t2` element names a different table
BACKUP TABLE mydb.t1, TABLE mydb.t2 EXCEPT DATA FROM TABLE mydb.t1 TO Disk('backups', 'tables/')

إذا ذُكر جدول باسمه في عنصر مستقل، وشملته أيضًا عبارة EXCEPT DATA FROM في عنصر أوسع، فإن بياناته تُنسخ احتياطيًا: فطلب الجدول في عنصر مستقل يشمل طلب بياناته. وهذا يتفق مع سلوك EXCEPT TABLES، إذ يُنسخ الجدول المذكور صراحةً احتياطيًا حتى لو استثناه عنصر أوسع. تُستثنى بيانات الجدول الداخلي لعرض مُجسَّد (أو الجداول الداخلية لجدول TimeSeries) باستخدام اسم الكائن الخارجي؛ فالعبارة لا تقبل أسماء الجداول الداخلية. لا تُستخدم EXCEPT DATA FROM {TABLE|TABLES} إلا مع BACKUP. أما RESTORE فيرفضها، بدلًا من قبولها بوصفها عملية بلا أثر.

المحركات التي لا يستطيع `RESTORE` إعادة إنشائها

لا يستطيع RESTORE إعادة إنشاء بعض المحركات إطلاقًا، سواء استُخدمت عبارة EXCEPT DATA FROM {TABLE|TABLES} أم لا. وفي هذه الحالات، تظل العبارة تحدد حجم النسخة الاحتياطية، لكنها لا تعني استعادة جدول فارغ؛ فلا يُستعاد الجدول أصلًا، لأن RESTORE يرفض إنشاءه. ومن أبرز هذه الحالات جدول MaterializedPostgreSQL المستقل. فبمجرد إنشائه، سيبدأ نسخ البيانات من مصدر PostgreSQL النشط، ما يؤدي إلى خلط لقطة النسخة الاحتياطية بالحالة الحالية للمصدر البعيد. لذلك يرفض RESTORE إنشاءه في مصنع التخزين، قبل إنشاء الجدول، مع الخطأ NOT_IMPLEMENTED. وهذه خاصية للمحرك تنطبق أيضًا على النسخ الاحتياطي الكامل المعتاد. الطريقة المدعومة هي الاستعادة باسم مختلف إلى جدول يستخدم محرك ReplacingMergeTree، تكون قد أنشأته مسبقًا ببنية الجدول المتداخل (بما في ذلك العمودان _sign و_version):

-- Back up the definition without the rows: they are replicated from PostgreSQL and can be replicated again
BACKUP DATABASE mydb EXCEPT DATA FROM TABLE mydb.pg_table TO Disk('backups', 'mydb/')

CREATE TABLE mydb.plain_target
(
    key Int32,
    value Int32,
    _sign Int8 MATERIALIZED 1,
    _version UInt64 MATERIALIZED 1
)
ENGINE = ReplacingMergeTree(_version) ORDER BY key

-- Succeeds, and leaves `mydb.plain_target` empty because the backup carries no rows for `mydb.pg_table`
RESTORE TABLE mydb.pg_table AS mydb.plain_target FROM Disk('backups', 'mydb/')
SETTINGS allow_different_table_def = 1

يلزم استخدام allow_different_table_def لأن التعريف المخزَّن في النسخة الاحتياطية يستخدم المحرك MaterializedPostgreSQL، بينما تجري استعادته عمدًا إلى جدول ReplacingMergeTree عادي. أما من دون EXCEPT DATA FROM TABLE، فإن أمر RESTORE نفسه ينقل الصفوف أيضًا بدلًا من ذلك.

الإعدادات

إعدادات النسخ الاحتياطي والاستعادة العامة

الإعداد	الوصف	القيمة الافتراضية
`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 أو استعادتها من دون بيانات الجدول الفعلية.
`restore_table_data`	ما إذا كان ينبغي استعادة بيانات الجداول. ينطبق هذا فقط على الأمر `RESTORE`. عند عدم ضبطه، تكون قيمته الافتراضية `NOT structure_only`؛ ويؤدي ضبطه صراحةً إلى تجاوز `structure_only`. راجع “إعدادات الاستعادة”.
`restore_access_entities`	ما إذا كان ينبغي استعادة كيانات الوصول (المستخدمون، الأدوار، ملفات تعريف الإعدادات، سياسات الصفوف، الحصص). ينطبق هذا فقط على الأمر `RESTORE`. عند عدم ضبطه، تكون قيمته الافتراضية `NOT structure_only`؛ ويؤدي ضبطه صراحةً إلى تجاوز `structure_only`. راجع “إعدادات الاستعادة”.
`restore_functions`	ما إذا كان ينبغي استعادة الدوال المعرفة من قبل المستخدم. ينطبق هذا فقط على الأمر `RESTORE`. عند عدم ضبطه، تكون قيمته الافتراضية `NOT structure_only`؛ ويؤدي ضبطه صراحةً إلى تجاوز `structure_only`. راجع “إعدادات الاستعادة”.
`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`

إعدادات خاصة بـ S3

الإعداد	الوصف	القيمة الافتراضية
`use_same_s3_credentials_for_base_backup`	ما إذا كان يجب أن ترث النسخة الاحتياطية الأساسية إلى S3 بيانات الاعتماد من الاستعلام. يعمل فقط مع `S3`.
`s3_storage_class`	فئة التخزين المستخدمة للنسخ الاحتياطي على S3. على سبيل المثال: `STANDARD`

إعدادات خاصة بـ Azure

الإعداد	الوصف	القيمة الافتراضية
`azure_attempt_to_create_container`	عند استخدام Azure Blob Storage، ما إذا كانت ستتم محاولة إنشاء الحاوية المحددة إذا لم تكن موجودة.	`true`

الإدارة واستكشاف الأخطاء وإصلاحها

يعيد أمر النسخ الاحتياطي id وstatus، ويمكن استخدام هذا الـid للحصول على حالة النسخ الاحتياطي. ويُعد هذا مفيدًا جدًا للتحقق من تقدّم عمليات النسخ الاحتياطي ASYNC الطويلة. يوضّح المثال أدناه فشلًا حدث عند محاولة استبدال ملف نسخ احتياطي موجود:

BACKUP TABLE helloworld.my_first_table TO Disk('backups', '1.zip') ASYNC

┌─id───────────────────────────────────┬─status──────────┐
│ 7678b0b3-f519-4e6e-811f-5a0781a4eb52 │ CREATING_BACKUP │
└──────────────────────────────────────┴─────────────────┘

1 row in set. Elapsed: 0.001 sec.

SELECT
*
FROM system.backups
WHERE id='7678b0b3-f519-4e6e-811f-5a0781a4eb52'
FORMAT Vertical

Row 1:
──────
id:                7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:              Disk('backups', '1.zip')
status:            BACKUP_FAILED
num_files:         0
uncompressed_size: 0
compressed_size:   0
error:             Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 22.8.2.11 (official build))
start_time:        2022-08-30 09:21:46
end_time:          2022-08-30 09:21:46

1 row in set. Elapsed: 0.002 sec.

إلى جانب جدول system.backups، تُسجَّل أيضًا جميع عمليات النسخ الاحتياطي والاستعادة في جدول سجل النظام system.backup_log:

SELECT *
FROM system.backup_log
WHERE id = '7678b0b3-f519-4e6e-811f-5a0781a4eb52'
ORDER BY event_time_microseconds ASC
FORMAT Vertical

Row 1:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.097414
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  CREATING_BACKUP
error:
start_time:              2023-08-18 11:13:43
end_time:                1970-01-01 03:00:00
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

Row 2:
──────
event_date:              2023-08-18
event_time_microseconds: 2023-08-18 11:13:43.174782
id:                      7678b0b3-f519-4e6e-811f-5a0781a4eb52
name:                    Disk('backups', '1.zip')
status:                  BACKUP_FAILED
error:                   Code: 598. DB::Exception: Backup Disk('backups', '1.zip') already exists. (BACKUP_ALREADY_EXISTS) (version 23.8.1.1)
start_time:              2023-08-18 11:13:43
end_time:                2023-08-18 11:13:43
num_files:               0
total_size:              0
num_entries:             0
uncompressed_size:       0
compressed_size:         0
files_read:              0
bytes_read:              0

2 rows in set. Elapsed: 0.075 sec.

الأساسيات

مفاهيم ClickHouse

أفضل الممارسات

النسخ الاحتياطي والاستعادة في ClickHouse

المقدمة

أنواع النسخ الاحتياطية

النسخ الاحتياطية المتزامنة مقابل غير المتزامنة

النسخ الاحتياطية المتوازية وغير المتوازية

النسخ الاحتياطية المضغوطة مقابل غير المضغوطة

استخدام المجموعات المسماة

أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول

البنية العامة

ملخص الأوامر

نسخ جدول احتياطيًا دون بياناته

المحركات التي لا يستطيع `RESTORE` إعادة إنشائها

الإعدادات

الإدارة واستكشاف الأخطاء وإصلاحها

​المقدمة

​أنواع النسخ الاحتياطية

​النسخ الاحتياطية المتزامنة مقابل غير المتزامنة

​النسخ الاحتياطية المتوازية وغير المتوازية

​النسخ الاحتياطية المضغوطة مقابل غير المضغوطة

​استخدام المجموعات المسماة

​أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول

​البنية العامة

​ملخص الأوامر

​نسخ جدول احتياطيًا دون بياناته

​المحركات التي لا يستطيع RESTORE إعادة إنشائها

​الإعدادات

​الإدارة واستكشاف الأخطاء وإصلاحها

المقدمة

أنواع النسخ الاحتياطية

النسخ الاحتياطية المتزامنة مقابل غير المتزامنة

النسخ الاحتياطية المتوازية وغير المتوازية

النسخ الاحتياطية المضغوطة مقابل غير المضغوطة

استخدام المجموعات المسماة

أخذ نسخ احتياطية من جداول النظام أو السجل أو إدارة الوصول

البنية العامة

ملخص الأوامر

نسخ جدول احتياطيًا دون بياناته

المحركات التي لا يستطيع `RESTORE` إعادة إنشائها

الإعدادات

الإدارة واستكشاف الأخطاء وإصلاحها