دليل لنسخ قاعدة البيانات

كرر ، لكن في كل مرة بطريقة جديدة - أليس هذا فنًا؟



ستانيسلاف جيرزي ليك ، من كتاب "أفكار غير مجمعة"

يعرّف القاموس النسخ المتماثل بأنه عملية الاحتفاظ بمجموعتين (أو أكثر) من البيانات في حالة متسقة. ما هي "الحالة المتسقة لمجموعات البيانات" هو سؤال كبير منفصل ، لذلك دعونا نعيد صياغة التعريف بطريقة أبسط: عملية تغيير مجموعة بيانات واحدة ، تسمى نسخة طبق الأصل ، استجابة للتغييرات في مجموعة بيانات أخرى ، تسمى الرئيسية. المجموعات ليست هي نفسها بالضرورة.







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



تتضمن مهام النسخ المتماثل على الأقل

• دعم قاعدة البيانات الاحتياطية في حالة فقد قاعدة البيانات الرئيسية ؛
• تقليل الحمل على القاعدة بسبب نقل جزء من الطلبات إلى النسخ المتماثلة ؛
• نقل البيانات إلى أنظمة أرشيفية أو تحليلية.

في هذه المقالة سأتحدث عن أنواع النسخ المتماثل والمهام التي يحلها كل نوع من أنواع النسخ المتماثل.



هناك ثلاث طرق للنسخ المتماثل:

• نسخ الكتل على مستوى نظام التخزين ؛
• النسخ المتماثل المادي على مستوى نظم إدارة قواعد البيانات ؛
• النسخ المنطقي على مستوى DBMS.

نسخ الكتلة

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







تشمل مزايا هذا النسخ سهولة الإعداد والموثوقية. يمكن لمصفوفة قرص أو شيء ما (جهاز أو برنامج) بين المضيف والقرص كتابة البيانات إلى قرص بعيد.



يمكن تكميل صفائف القرص بخيارات لتمكين النسخ المتماثل. يعتمد اسم الخيار على الشركة المصنعة للمصفوفة:





إذا كانت مصفوفة القرص غير قادرة على نسخ البيانات ، فيمكن تثبيت عامل بين المضيف والمصفوفة ، والتي تكتب على صفيفتين في وقت واحد. يمكن أن يكون الوكيل إما جهازًا مستقلاً (EMC VPLEX) أو مكون برنامج (HPE PeerPersistance ، نسخة متماثلة لتخزين Windows Server ، DRBD). على عكس مجموعة الأقراص ، التي يمكن أن تعمل فقط مع نفس المصفوفة ، أو على الأقل مع مصفوفة من نفس الشركة المصنعة ، يمكن للوكيل العمل مع أجهزة قرص مختلفة تمامًا.



الغرض الرئيسي من نسخ الكتلة هو توفير التسامح مع الخطأ. إذا فقدت قاعدة البيانات ، يمكنك إعادة تشغيلها باستخدام وحدة التخزين المتطابقة.



يعد النسخ المتماثل للكتل أمرًا رائعًا لتعدد استخداماته ، ولكن التنوع يأتي بسعر.



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



في حالة استخدام وكيل ، سيتم تنفيذ جميع هذه الإجراءات بواسطة الوكيل ، مما يبسط التكوين ، ولكنه لا يقلل من وقت التبديل.



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



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



لا يمكن استخدام النسخ المتماثل للكتل لموازنة التحميل ، ويتم استخدام مخطط مماثل لترقية مخزن البيانات مع وحدة التخزين المنسوخة على نفس الصفيف الأساسي. تسمي EMC و HP هذا المخطط BCV ، فقط EMC تعني حجم استمرارية الأعمال ، و HP تعني حجم نسخ الأعمال. لا تمتلك شركة IBM علامة تجارية خاصة لهذه الحالة ، ويطلق على هذا المخطط اسم "الحجم المتطابق".







يتم إنشاء مجلدين في المصفوفة ويتم إجراء عمليات الكتابة بشكل متزامن على كلاهما (A). في وقت معين ، تنكسر المرآة (B) ، أي تصبح الأحجام مستقلة. يتم تحميل وحدة التخزين المنسوخة إلى خادم مخصص لترقيات التخزين ويتم رفع مثيل قاعدة البيانات على ذلك الخادم. سيستغرق المثيل وقتًا طويلاً ليتم تشغيله مع استعادة النسخ المتماثل للكتلة ، ولكن يمكن تقليل هذه المرة بشكل كبير عن طريق كسر المرآة خلال فترات خارج الذروة. النقطة المهمة هي أن كسر المرآة في عواقبه يعادل إنهاء غير طبيعي لنظام إدارة قواعد البيانات ، ووقت الاسترداد في حالة الإنهاء غير الطبيعي يعتمد بشكل كبير على عدد المعاملات النشطة في وقت الانهيار. قاعدة البيانات المخصصة للتفريغ متاحة للقراءة والكتابة. جميع معرفات الكتلة ،تم تغيير المرايا بعد الاستراحة ، سواء على المستوى الرئيسي أو على وحدة التخزين المتطابقة ، ويتم حفظها في منطقة خاصة من Block Change Tracking - BCT.



بعد انتهاء التفريغ ، يتم فك وحدة التخزين المتطابقة (C) ، ويتم استعادة المرآة ، وبعد فترة يلحق الحجم المرآة مرة أخرى بالحجم الرئيسي ويصبح نسخته.

التكرار المادي

تحتوي السجلات (سجل الإعادة أو سجل الكتابة المسبقة) على كافة التغييرات التي تم إجراؤها على ملفات قاعدة البيانات. تكمن الفكرة وراء النسخ المتماثل المادي في إعادة الالتزام بالتغييرات من السجلات إلى قاعدة بيانات أخرى (نسخة متماثلة) ، وبالتالي فإن البيانات الموجودة في النسخة المتماثلة تنسخ البيانات الموجودة في قاعدة البيانات الرئيسية بايت بايت.



ظهرت القدرة على استخدام سجلات قاعدة البيانات لتحديث نسخة متماثلة في إصدار Oracle 7.3 ، الذي تم إصداره في عام 1996 ، وفي إصدار Oracle 8i بالفعل ، تم تسليم السجلات من قاعدة البيانات الرئيسية إلى النسخة المتماثلة تلقائيًا وتم تسميته DataGuard. اتضح أن هذه التقنية مطلوبة للغاية لدرجة أن آلية النسخ الفعلي موجودة اليوم في جميع أنظمة إدارة قواعد البيانات الحديثة تقريبًا.





تُظهر التجربة أنه إذا تم استخدام الخادم فقط للحفاظ على النسخة المتماثلة محدثة ، فإن حوالي 10٪ من طاقة المعالجة للخادم الذي تعمل عليه القاعدة الرئيسية كافية لذلك.



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



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



يسمح لك Oracle DataGuard بحذف بعض الملفات من قاعدة البيانات المتماثلة - في هذه الحالة ، سيتم تجاهل التغييرات في السجلات المتعلقة بهذه الملفات.



يتميز النسخ المتماثل لقاعدة البيانات المادية بالعديد من المزايا مقارنةً بنسخ التخزين:

• كمية البيانات المنقولة أقل بسبب حقيقة أنه يتم نقل السجلات فقط ، وليس ملفات البيانات ؛ أظهرت التجارب انخفاضًا في حركة المرور بمقدار 5-7 مرات ؛
• : - , ; , ;
• , . , .

تم تقديم القدرة على قراءة البيانات من نسخة متماثلة في عام 2007 مع إصدار Oracle 11g ، كما يتضح من العنوان "نشط" المضافة إلى اسم تقنية DataGuard. تتمتع أنظمة DBMS الأخرى أيضًا بالقدرة على القراءة من نسخة متماثلة ، ولكن هذا لا ينعكس في الاسم.



تعد كتابة البيانات إلى نسخة متماثلة أمرًا مستحيلًا ، نظرًا لأن التغييرات تأتي عليها بايتًا بايت ، ولا يمكن للنسخة المتماثلة توفير التنفيذ المتزامن لطلباتها. يسمح Oracle Active DataGuard في الإصدارات الأخيرة بالكتابة إلى النسخة المتماثلة ، ولكن هذا ليس أكثر من "سكر": في الواقع ، يتم إجراء التغييرات على القاعدة الرئيسية ، وينتظر العميل حتى يتم الانتقال إلى النسخة المتماثلة.



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



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



في PostgreSQL ، من الممكن تكوين النسخ المتماثل بحيث يكتمل الالتزام فقط بعد تطبيق التغييرات على بيانات النسخة المتماثلة (الخيار synchronous_commit = remote_apply) ، بينما في Oracle ، يمكنك تكوين النسخة المتماثلة بأكملها أو الجلسات الفردية بحيث يتم تنفيذ الاستعلامات فقط إذا كانت النسخة المتماثلة لا تتخلف عن قاعدة البيانات الرئيسية ( STANDBY_MAX_DATA_DELAY=0). ومع ذلك ، لا يزال من الأفضل تصميم التطبيق بحيث تتم الكتابة إلى قاعدة البيانات الرئيسية والقراءة من النسخ المتماثلة في وحدات نمطية مختلفة.



عند البحث عن إجابة للسؤال عن الوضع الذي يجب اختياره ، المتزامن أو غير المتزامن ، يقوم مسوقو Oracle بمساعدتنا. يوفر DataGuard ثلاثة أوضاع ، يعمل كل منها على زيادة أحد المعلمات إلى الحد الأقصى - أمان البيانات والأداء والتوافر - على حساب الآخرين:

• الأداء الأقصى: النسخ المتماثل دائمًا غير متزامن ؛
• Maximum protection: ; , commit ;
• Maximum availability: ; , , , .

على الرغم من المزايا التي لا يمكن إنكارها لنسخ قاعدة البيانات على النسخ المتماثل للكتل ، فإن المسؤولين في العديد من الشركات ، وخاصة تلك التي لديها تقاليد موثوقية قديمة ، لا يزالون مترددين في التخلي عن نسخ الكتلة. هناك سببان لهذا.



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



ثانيًا ، أصبح النسخ المتزامن عن طريق DBMS موثوقًا به مؤخرًا نسبيًا. في Oracle ، حدث الاختراق في إصدار 11g ، الذي ظهر في عام 2007 ، وفي نظم إدارة قواعد البيانات الأخرى ، ظهر النسخ المتزامن حتى في وقت لاحق. بالطبع ، 10 سنوات وفقًا لمعايير مجال تكنولوجيا المعلومات ليست قصيرة ، ولكن عندما يتعلق الأمر بأمن البيانات ، لا يزال بعض المسؤولين يسترشدون بمبدأ "مهما حدث" ...

النسخ المنطقي

تحدث جميع التغييرات في قاعدة البيانات نتيجة لاستدعاءات API الخاصة بها - على سبيل المثال ، كنتيجة لتنفيذ استعلامات SQL. تبدو فكرة تشغيل نفس تسلسل الاستعلامات على قاعدتين مختلفتين مغرية للغاية. للنسخ ، يجب الالتزام بقاعدتين:

1. , , . D, A B.
2. , , . B , , C.

يتم تنفيذ تكرار الأوامر (النسخ المتماثل المستند إلى العبارات) ، على سبيل المثال ، في MySQL. لسوء الحظ ، لا ينتج عن هذا المخطط البسيط مجموعات بيانات متطابقة لسببين.



أولاً ، ليست كل واجهات برمجة التطبيقات حتمية. على سبيل المثال ، إذا احتوى استعلام SQL على الدالة now () أو sysdate () التي تُرجع الوقت الحالي ، فسيعرض نتائج مختلفة على خوادم مختلفة لأن الاستعلامات لا يتم تنفيذها في وقت واحد. بالإضافة إلى ذلك ، يمكن أن تؤدي حالات مختلفة من المشغلات والوظائف المخزنة ، وأماكن مختلفة تؤثر على ترتيب الفرز ، وأكثر من ذلك بكثير إلى اختلافات.



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







إذا تم إيقاف النسخ المتماثل في الوقت T1 ، فيجب إحباط المعاملة B والتراجع عنها. عند إعادة تشغيل النسخ المتماثل ، يمكن أن يؤدي تنفيذ المعاملة B إلى إحضار النسخة المتماثلة إلى حالة مختلفة عن حالة قاعدة البيانات المصدر: في المصدر ، بدأت المعاملة B قبل انتهاء المعاملة A ، مما يعني أنها لم تشاهد التغييرات التي تم إجراؤها بواسطة المعاملة A.

يمكن إيقاف النسخ المتماثل للطلبات و إعادة التشغيل فقط في الوقت T2 ، عندما لا توجد معاملات نشطة في قاعدة البيانات. بالطبع ، لا توجد مثل هذه اللحظات في قاعدة صناعية محملة بشدة.



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

• يقوم الاستعلام بتحديث (أو إدراج ، أو حذف) سجل واحد ، وتحديده بواسطة مفتاحه الأساسي (أو الفريد) ؛
• يتم تعيين جميع معلمات الطلب بشكل صريح في الطلب نفسه.

على عكس النسخ المتماثل القائم على البيان ، يُطلق على هذا النهج النسخ المتماثل المستند إلى الصف.



لنفترض أن لدينا جدول موظف بالبيانات التالية:





تم إجراء العملية التالية على هذا الجدول:

update employee set salary = salary*1.2 where dept=36;

من أجل نسخ البيانات بشكل صحيح ، سيتم تنفيذ الاستعلامات التالية في النسخة المتماثلة:

update employee set salary = 2160 where id=3817;
update employee set salary = 1920 where id=2274;

تنتج الاستعلامات نفس النتيجة الموجودة في الأساس الأصلي ، ولكنها لا تعادل الاستعلامات المنفذة.



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



من المهم أن نفهم أن النسخة المتماثلة المنطقية ستكون مكافئة للقاعدة الأصلية فقط إذا لم يتم إجراء تغييرات إضافية عليها. على سبيل المثال ، في المثال أعلاه ، في النسخة المتماثلة ، تمت إضافة قسم سيدوروف إلى 36 ، فلن يتلقى ترقية ، وإذا تم نقل إيفانوف من القسم 36 ، فسيحصل على ترقية ، بغض النظر عن السبب.



يوفر النسخ المنطقي عددًا من الإمكانات غير الموجودة في أنواع النسخ الأخرى:

• إعداد مجموعة من البيانات المنسوخة على مستوى الجدول (للنسخ المادي - على مستوى مساحة الملف والجدول ، لنسخ الكتلة - على مستوى الحجم) ؛
• بناء طبولوجيا النسخ المتماثل المعقدة - على سبيل المثال ، دمج العديد من قواعد البيانات في تكرار واحد أو تكرار ثنائي الاتجاه ؛
• انخفاض في كمية البيانات المرسلة ؛
• النسخ المتماثل بين الإصدارات المختلفة من DBMS أو حتى بين DBMSs من مختلف الشركات المصنعة ؛
• معالجة البيانات أثناء النسخ المتماثل ، بما في ذلك إعادة الهيكلة والإثراء وحفظ التاريخ.

هناك أيضًا عيوب تمنع النسخ المنطقي من أن يحل محل النسخ المادي:

• يجب أن تحتوي جميع البيانات المنسوخة على مفاتيح أساسية ؛
• لا يدعم النسخ المنطقي كافة أنواع البيانات - على سبيل المثال ، قد تكون هناك مشاكل مع BLOBs.
• : , ;
• ;
• , , – , .

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



هناك عدة طرق لتنفيذ النسخ المنطقي ، وكل طريقة من هذه الطرق تنفذ جزءًا من القدرات ولا تنفذ الأخرى:

• النسخ المتماثل بواسطة المشغلات.
• باستخدام سجلات DBMS ؛
• استخدام برنامج CDC (تغيير التقاط البيانات) ؛
• النسخ المطبق.

الزناد النسخ المتماثل

Trigger هو إجراء مخزن يتم تنفيذه تلقائيًا عند أي إجراء لتعديل البيانات. المشغل ، الذي يتم استدعاؤه عند تغيير كل سجل ، لديه حق الوصول إلى مفتاح ذلك السجل ، بالإضافة إلى قيم الحقل القديمة والجديدة. إذا لزم الأمر ، يمكن للمشغل حفظ قيم الصف الجديدة في جدول خاص ، حيث ستقرأها عملية خاصة على جانب النسخة المتماثلة. كمية الشفرة في المشغلات كبيرة ، لذلك هناك برنامج خاص يولد مثل هذه المشغلات ، على سبيل المثال ، "دمج النسخ المتماثل" - أحد مكونات Microsoft SQL Server أو Slony-I - منتج منفصل للنسخ المتماثل PostgreSQL.



قدرات النسخ المتماثل الزناد:

• الاستقلال عن إصدارات القاعدة الرئيسية والنسخة المتماثلة ؛
• قدرات تحويل البيانات واسعة النطاق.

سلبيات:

• تحميل على القاعدة الرئيسية
• ارتفاع زمن انتقال النسخ المتماثل.

استخدام سجلات DBMS

يمكن أن يوفر نظام DBMS نفسه أيضًا إمكانات نسخ منطقية. السجلات هي مصدر البيانات ، تمامًا مثل النسخ الفعلي. تتم أيضًا إضافة المعلومات حول تغيير البايت مع معلومات حول الحقول التي تم تغييرها (التسجيل الإضافي في Oracle ، wal_level = logicalفي PostgreSQL) ، بالإضافة إلى قيمة المفتاح الفريد ، حتى لو لم يتغير. نتيجة لذلك ، يتزايد حجم سجلات قاعدة البيانات - وفقًا لتقديرات مختلفة ، من 10 إلى 15٪.



تعتمد قدرات النسخ المتماثل على التنفيذ في نظام DBMS معين - إذا كان بإمكانك إنشاء وضع احتياطي منطقي في Oracle ، فيمكنك في PostgreSQL أو Microsoft SQL Server نشر نظام معقد للاشتراكات المتبادلة والمنشورات باستخدام أدوات النظام الأساسي المدمجة. بالإضافة إلى ذلك ، يوفر نظام DBMS مراقبة وتحكمًا مدمجين في النسخ المتماثل.



تشمل عيوب هذا الأسلوب زيادة حجم السجلات وزيادة محتملة في حركة المرور بين العقد.

باستخدام CDC

هناك فئة كاملة من البرامج المصممة لتنظيم النسخ المنطقي. هذا البرنامج يسمى CDC ، تغيير التقاط البيانات. فيما يلي قائمة بأكثر المنصات شهرة في هذه الفئة:

• Oracle GoldenGate (حصل عليها GoldenGate في عام 2009) ؛
• IBM InfoSphere Data Replication (المعروف سابقًا باسم InfoSphere CDC ؛ وحتى قبل ذلك ، DataMirror Transformation Server ، التي حصلت عليها DataMirror في عام 2007) ؛
• VisionSolutions DoubleTake / MIMIX (سابقًا Vision Replicate1) ؛
• منصة Qlik لتكامل البيانات (Attunity سابقًا) ؛
• Informatica PowerExchange CDC ؛
• ديبيزيوم.
• مجمع البيانات StreamSets ...

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



نقاط القوة:

• القدرة على النسخ المتماثل بين نظم إدارة قواعد البيانات المختلفة ، بما في ذلك تحميل البيانات في أنظمة التقارير ؛
• أوسع إمكانيات معالجة البيانات وتحويلها ؛
• الحد الأدنى من حركة المرور بين العقد - تقطع المنصة البيانات غير الضرورية ويمكن أن تضغط على حركة المرور ؛
• قدرات مدمجة لمراقبة حالة النسخ المتماثل.

لا توجد عيوب كثيرة:

• زيادة حجم السجلات ، كما هو الحال مع النسخ المنطقي عن طريق نظام إدارة قواعد البيانات ؛
• يصعب تكوين برامج جديدة و / أو بتراخيص باهظة الثمن.

تُستخدم منصات CDC تقليديًا لتحديث مستودعات بيانات الشركة في الوقت الفعلي تقريبًا.

النسخ المطبق

أخيرًا ، هناك طريقة أخرى للنسخ المتماثل وهي تشكيل نواقل التغيير مباشرة على جانب العميل. يجب على العميل إصدار استعلامات حتمية تؤثر على سجل واحد. يمكن تحقيق ذلك باستخدام مكتبة قاعدة بيانات خاصة ، على سبيل المثال ، Borland Database Engine (BDE) أو Hibernate ORM.







عندما يكمل التطبيق المعاملة ، يكتب المكون الإضافي Hibernate ORM متجه التغيير إلى قائمة الانتظار وينفذ المعاملة في قاعدة البيانات. تطرح عملية النسخ المتماثل الخاصة المتجهات من قائمة الانتظار وتنفذ المعاملات في قاعدة النسخة المتماثلة.

هذه الآلية جيدة لتحديث أنظمة التقارير. يمكن استخدامه أيضًا لتوفير التسامح مع الخطأ ، ولكن في هذه الحالة ، يجب أن يقوم التطبيق بتنفيذ التحكم في حالة النسخ المتماثل.



تقليديا - نقاط القوة والضعف في هذا النهج:

• القدرة على النسخ المتماثل بين نظم إدارة قواعد البيانات المختلفة ، بما في ذلك تحميل البيانات في أنظمة التقارير ؛
• القدرة على معالجة البيانات وتحويلها ، ومراقبة الحالة ، وما إلى ذلك ؛
• الحد الأدنى من حركة المرور بين العقد - تقطع المنصة البيانات غير الضرورية ويمكن أن تضغط على حركة المرور ؛
• الاستقلال التام عن قاعدة البيانات - سواء عن الشكل أو عن الآليات الداخلية.

مزايا هذه الطريقة لا يمكن إنكارها ، ولكن هناك عيبان خطيران للغاية:

• قيود على بنية التطبيق ؛
• كمية هائلة من كود النسخ الأصلي.

إذن أيهما أفضل؟

لا توجد إجابة لا لبس فيها على هذا السؤال ، وكذلك على العديد من الأسئلة الأخرى. لكنني آمل أن يساعدك الجدول أدناه في اتخاذ القرار الصحيح لكل مهمة محددة:

• , ; .
• , .
• , .
• .
• , , .
• CDC , / .
• .