منصة البيانات · MySQL replication

النسخ المتماثل لقاعدة MySQL للتقارير والتعافي والترحيل، دون أن يُمس التطبيق

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

الملخص

نظرة سريعة

ما يشمله مشروع النسخ المتماثل لقاعدة MySQL، قبل التفاصيل.

المصدر
MySQL، ويُؤكَّد الإصدار ومكان الاستضافة عند تحديد النطاق
الأهداف
نسخة للتقارير أو نسخة احتياطية جاهزة، أو PostgreSQL أو قاعدة أخرى، أو Apache Kafka، أو أنظمة NoSQL والبحث، أو التخزين السحابي
طريقة قراءة التغييرات
من السجل الثنائي (binary log) في MySQL، وهو سجل التغييرات المعتمدة، باتفاق مع مديري قواعد البيانات
أثره في التطبيق
لا أثر: لا أعمدة جديدة ولا مشغّلات ولا تعديل في الشيفرة
حماية الإنتاج
ضبط المعدل، وطابور يحفظ التغييرات حين يغيب الهدف
طريقة الشراء
عرض سعر للمشروع، ويُسعَّر iblync بحسب نظام المصدر ونظام الهدف وحجم البيانات

الخلاصة لأصحاب القرار

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

ما الذي يجب أن يغطيه نسخ بيانات MySQL

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

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

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

أين يُستخدم النسخ المتماثل لقاعدة MySQL، وما يطلبه كل استخدام

الالتقاط من MySQL متقارب في كل الاستخدامات. أما ما يختلف فهو ما يجب أن يتعامل معه الهدف، وعمر البث.

الاستخدامات الشائعة للنسخ المتماثل لقاعدة MySQL وما يتطلبه كل منها
الاستخدامالهدف المعتادمتى ينتهيما يُحسم أولًا
التقارير والتحليلاتقاعدة منفصلة أو تخزين سحابيلا ينتهي، ويستمر ما دامت التقارير تحتاجهكم يُسمح للنسخة أن تتأخر، وكيف يظهر الحذف فيها
نسخة احتياطية للتعافي من الكوارثنسخة MySQL في موقع آخر أو في السحابةلا ينتهي، فهو جزء من خطة استمرارية الأعمالهدفا نقطة الاستعادة ووقتها، وطريقة اختبار الانتقال عند التعطل
جسر أثناء الترحيلPostgreSQL أو قاعدة أخرىعند اكتمال التحويل وإيقاف MySQLمطابقة الأنواع وترميز الأحرف، والتحقق، وطريق الرجوع
بث الأحداثApache Kafkaلا ينتهي، بل يصبح جزءًا من التشغيلتقسيم المواضيع (topics)، ومفاتيح الرسائل، والترتيب، ومن يملك كل مستهلك
البحث أو تطبيق جديدنظام NoSQL أو نظام بحثغالبًا لا ينتهيكيف تصبح الصفوف مستندات، وكيف يُطبَّق الحذف

إذا لم يكن للبث تاريخ انتهاء فعاملوه بوصفه تكاملًا له مالك ومراقبة وإدارة تغيير، لا مهمة في مشروع. وتُؤكَّد الأزواج التي تدخل في نطاقكم عند تحديد النطاق، وفق قائمة الموصلات المنشورة لـiblync.

التقاط تغييرات MySQL: القراءة من السجل الثنائي

لمعرفة ما تغيّر في قاعدة البيانات ثلاث طرق شائعة. فالاستطلاع الدوري لعمود «آخر تعديل» لا يرى الصفوف المحذوفة نهائيًا، ويثقل كلما كبرت الجداول. والمشغّلات (triggers) ترى كل تغيير، لكنها تضيف عملًا إلى كل عملية كتابة وتصبح جزءًا من الهيكل. أما التقاط تغييرات MySQL، أو MySQL CDC، فيقرأ عادةً السجل الثنائي، وهو السجل الذي تحفظ فيه MySQL التغييرات المعتمدة، وهو نفسه ما يعتمد عليه النسخ المتماثل المدمج فيها. ولا يُضاف شيء إلى التطبيق أو جداوله، ولهذا تُعد القراءة من السجل الخيار المعتاد لأنظمة الإنتاج.

اقرأ المزيد

والقراءة من السجل الثنائي تطلب أمورًا قليلة من الفريق الذي يدير MySQL، ونتفق عليها أولًا:

  • تفعيل السجل الثنائي بصيغة الصفوف (row-based)، فيحمل كل تغيير قيم الصف نفسها لا الجملة التي أنتجته.
  • مدة الاحتفاظ. تبقى السجلات مدة تكفي للحاق بعد أي توقف، بما يتسق مع النسخ الاحتياطي ومساحة القرص.
  • حساب للالتقاط بصلاحيات النسخ المتماثل التي تحتاجها الطريقة، وقراءة الجداول المشمولة وحدها.
  • مفتاح أساسي في كل جدول. فبدونه لا يمكن تطبيق التحديث أو الحذف على صف واحد بعينه في الهدف، وتُحدَّد هذه الجداول عند تحديد النطاق.
  • معرّفات المعاملات العامة (GTID) حيث تكون مفعّلة، فيبقى الموضع في السجل معروفًا حتى بعد انتقال المصدر إلى خادم آخر.
  • تغييرات الهيكل. من يُبلغ فريق النسخ المتماثل حين يتغير جدول أو عمود، وكيف يلحق الهدف بالتغيير.

وفي خدمات MySQL المُدارة تقع بعض هذه الإعدادات لدى مزوّد الخدمة، فنراجعها مبكرًا.

من MySQL إلى Kafka: نشر التغييرات على هيئة أحداث

بثّ تغييرات MySQL إلى Kafka يتيح للخدمات الجديدة أن تتفاعل مع طلب أو دفعة أو تغيّر حالة دون أن تستعلم من قاعدة الإنتاج. وApache Kafka من الأنظمة التي يذكرها موقع iblync، ويُؤكَّد الزوج المناسب لإصداراتكم عند تحديد النطاق. ونقاط التصميم التي تحدد هل يمكن الوثوق بالبث هي:

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

كيف ينسخ iblync بيانات MySQL

iblync منصة إنتركي لترحيل البيانات ونسخها المتماثل، وMySQL ضمن المصادر في قائمة موصلاتها المنشورة. وتقدم في النسخ من MySQL:

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

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

ومتى قد لا تحتاجون إلى iblync. إذا كنتم تحتاجون نسخة احتياطية واحدة من خادم MySQL إلى خادم MySQL آخر دون أي تشكيل للبيانات، فالنسخ المتماثل المدمج في MySQL هو أول ما يُقيَّم، وهو في الغالب أقل كلفة، وسنخبركم بذلك. وإذا كان الهدف لا يحتاج إلا إلى أرقام الأمس، فالتحميل الدفعي المجدول أبسط في التشغيل. ولا تغني أي نسخة متماثلة عن النسخ الاحتياطية.

التقارير والتعافي من الكوارث والترحيل: ما الذي يختلف بينها

  • التقارير. تنتقل الاستعلامات الثقيلة إلى نسخة مهيأة لها، فيبقى المتجر أو البوابة سريعًا في نهاية الشهر. وقد تتأخر النسخة قليلًا، ويتفق العمل على المقدار المقبول.
  • التعافي من الكوارث. تُبقي النسخة الاحتياطية في موقع آخر نقطة الاستعادة قريبة من آخر تغيير معتمد. لكن النسخة المتماثلة ليست نسخة احتياطية: الجدول المحذوف خطأً يُحذف فيها أيضًا، فتبقى النسخ الاحتياطية في مكانها. وتتناول صفحة التعافي من الكوارث الخطة الأوسع.
  • الترحيل. تُحمَّل القاعدة الجديدة مرة واحدة، وتبقى متطابقة مع MySQL حتى تثبت جدارتها، ثم تنتقل الكتابة في تحويل قصير جرى التمرن عليه. وللانتقال إلى PostgreSQL تشرح صفحة ترحيل MySQL إلى PostgreSQL مطابقة الأنواع والنص العربي.

وإن كانت بيئتكم تضم محركات أخرى فالمنهج نفسه ينطبق على النسخ المتماثل لـPostgreSQL والنسخ المتماثل لـSQL Server.

كيف يسير مشروع النسخ المتماثل لقاعدة MySQL

  1. تحديد النطاق.

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

  2. الاتفاق مع فريق MySQL.

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

  3. التحميل الأولي.

    تُنسخ البيانات الموجودة مرة واحدة من موضع مسجّل في السجل، بمعدل مقيّد يبقى داخل الحمل المتفق عليه.

  4. النسخ المستمر.

    تُطبَّق التغييرات منذ ذلك الموضع بترتيب اعتمادها، مع الطابور إذا غاب الهدف.

  5. التحقق والمراقبة.

    مقارنة الأعداد والمجاميع الاختبارية، وقياس التأخر، وإرسال التنبيهات إلى مسؤول محدد بالاسم.

  6. التسليم أو التشغيل.

    دليل تشغيل وتسليم لفريقكم، أو تشغيل إنتركي وفق نطاق مكتوب.

ما تقدمه إنتركي في السعودية

فريق واحد لتحديد النطاق والالتقاط والتحميل والنسخ والمراقبة، مع دعم من الرياض بالعربية والإنجليزية، ومهندسين يتحدثون العربية ويعملون إلى جانب مديري قواعد البيانات لديكم. ويُسلَّم iblync مع الفريق الذي يشغّله.

وبث النسخ المتماثل نسخة من بيانات الإنتاج وهي تتحرك، فسؤال إقامة البيانات ينطبق عليه كما ينطبق على القاعدة نفسها. وتلتزم جهات سعودية كثيرة بإبقاء بيانات معينة داخل المملكة، وفق ضوابط الهيئة الوطنية للأمن السيبراني (nca.gov.sa) ونظام حماية البيانات الشخصية الذي تشرف عليه سدايا (sdaia.gov.sa). ويُحسم مكان تشغيل عملية الالتقاط والطابور والهدف، وهل تخرج أي بيانات من بيئتكم، قبل نقل أول صف.

ما الذي يحدد الكلفة والمدة

لا ننشر سعرًا أو مدة للنسخ المتماثل لقاعدة MySQL، لأن البيئة هي التي تحددهما. والعوامل هي:

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

ويحوّل تحديد النطاق هذه العوامل إلى جدول زمني بمدى تقريبي وعرض سعر.

أسئلة شائعة

هل يلزمنا تعديل تطبيقنا حتى يعمل النسخ المتماثل لقاعدة MySQL؟

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

هل يُبطئ النسخ المتماثل خادم MySQL في الإنتاج؟

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

هل يمكن بثّ تغييرات MySQL إلى Apache Kafka؟

MySQL ضمن قائمة الموصلات المنشورة لـiblync، وApache Kafka من الأنظمة التي يذكرها موقعه. ويُؤكَّد الزوج المناسب لإصداراتكم عند تحديد النطاق، مع تقسيم المواضيع ومفاتيح الرسائل.

هل تكفي نسخة MySQL متماثلة للتعافي من الكوارث؟

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

كيف يُسعَّر النسخ المتماثل لقاعدة MySQL في السعودية؟

بعرض سعر بعد تحديد النطاق: يُسعَّر iblync بحسب نظام المصدر ونظام الهدف وحجم البيانات، ويُسعَّر المشروع بحسب العمل المحيط به، مثل تعديل إعدادات السجل والمطابقة والتحقق.

هل يمكن أن تبقى النسخة المتماثلة وجسر النسخ داخل المملكة؟

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

الخطوة التالية

حدّدوا نطاق النسخ المتماثل لـMySQL

أخبرونا بإصدارات MySQL ومكان استضافتها، والجداول المشمولة، ومقدار ما يتغير من البيانات كل يوم، والهدف الذي تريدون تغذيته، وكم يُسمح له أن يتأخر.

خانة إلزامية

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

أو مباشرةً

+966-11-2180999 [email protected]

أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية

أو أين يُستخدم

نشرته إنتركي. آخر تحديث . إنتركي مسجلة في الرياض بالسجل التجاري رقم 1010156897.