Skip to main content

هل يدعم MySQL ClickPipe ‏MariaDB؟

نعم، يدعم MySQL ClickPipe ‏MariaDB 10.0 وما بعده. وإعداده مشابه جدًا لـ MySQL، إذ يستخدم GTID النسخ المتماثل افتراضيًا.

لماذا فشل الـ pipe الخاص بي بسبب حدث صف جزئي غير مدعوم من MariaDB؟

يمكن لـ MariaDB 12.3 والإصدارات الأحدث إصدار حدث صفوف جزئية في binlog، وهو غير مدعوم لدينا حتى الآن. للتعافي، أعد مزامنة الـ pipe. ولتقليل احتمال حدوث ذلك مجددًا، يمكنك أيضًا رفع قيمة الإعداد binlog_row_event_fragment_threshold في المصدر لتقليل تجزئة تغييرات الصفوف — احرص على أن تبقيه أقل من max_allowed_packet، لأن حدث binlog واحدًا غير مُجزّأ يتجاوز max_allowed_packet سيؤدي بدلًا من ذلك إلى فشل تدفق النسخ المتماثل (راجع لماذا يفشل الـ pipe الخاص بي بسبب خطأ binlog متعلق بـ max_allowed_packet؟).

لماذا فشل الـ pipe الخاص بي بسبب عمود COMPRESSED غير مدعوم في MariaDB؟

إذا فشل الـ pipe الخاص بك مع ظهور خطأ مشابه لما يلي:
هذا يعني أن الجدول يحتوي على عمود واحد أو أكثر يستخدم ضغط الأعمدة في MariaDB (COLUMN_FORMAT COMPRESSED). لا يمكننا فك ضغط هذه القيم من binlog، لذلك لا يمكن نسخ الجدول المتأثر عبر CDC. لحل ذلك:
  • حوّل الأعمدة المضغوطة إلى نوع غير مضغوط في المصدر (أو أزل جدولًا من pipe):
  • أعد مزامنة الجدول أو pipe

هل يدعم MySQL ClickPipe أيًا من PlanetScale أو Vitess أو TiDB؟

لا، فهذه الخدمات لا تدعم واجهة برمجة تطبيقات binlog الخاصة بـ MySQL.

كيف تُدار عملية النسخ المتماثل؟

ندعم كلاً من النسخ المتماثل GTID وFilePos. وعلى عكس Postgres، لا توجد slot لإدارة الإزاحة. وبدلاً من ذلك، يجب تهيئة خادم MySQL لديك بحيث تكون فترة الاحتفاظ بـ binlog كافية. إذا أصبحت إزاحتنا داخل binlog غير صالحة (على سبيل المثال، إذا ظل الـ mirror متوقفًا مؤقتًا لفترة طويلة، أو حدث failover لقاعدة البيانات أثناء استخدام النسخ المتماثل FilePos)، فستحتاج إلى إعادة مزامنة الـ pipe. واحرص على تحسين materialized views التي تعتمد على جداول الوجهة، لأن الاستعلامات غير الفعّالة قد تُبطئ عملية الإدخال وتتسبب في تراجعها إلى ما بعد فترة الاحتفاظ. ومن الممكن أيضًا أن تقوم قاعدة بيانات غير نشطة بتدوير log file من دون أن تتيح لـ ClickPipes التقدّم إلى إزاحة أحدث. وقد تحتاج إلى إعداد جدول heartbeat مع تحديثات مجدولة بانتظام. في بداية التحميل الأولي، نسجّل إزاحة binlog التي سنبدأ منها. ويجب أن تظل هذه الإزاحة صالحة عند اكتمال التحميل الأولي حتى يتمكن CDC من التقدّم. إذا كنت تُدخل كمية كبيرة من البيانات، فتأكد من تهيئة فترة احتفاظ مناسبة لـ binlog. وأثناء إعداد الجداول، يمكنك تسريع التحميل الأولي عبر تهيئة استخدام مفتاح partitioning مخصص للتحميل الأولي للجداول الكبيرة ضمن الإعدادات المتقدمة، حتى نتمكن من تحميل جدول واحد بالتوازي.

لماذا يفشل الـ pipe الخاص بي بسبب خطأ في binlog مرتبط بـ max_allowed_packet؟

إذا فشل الـ pipe الخاص بك مع ظهور خطأ مشابه لما يلي:
هذا يعني أن حدث binlog واحدًا (يمثل تغييرًا في صف واحد) أكبر من إعداد max_allowed_packet على خادم MySQL لديك. وبما أن الخادم لا يمكنه إرسال حدث يتجاوز هذا الحد، تتوقف قراءة تدفق binlog ولا يعود بإمكان CDC التقدم. يحدث هذا غالبًا بسبب صفوف تحتوي على قيم BLOB أو TEXT أو JSON كبيرة. لحل هذه المشكلة:
  • زِد قيمة max_allowed_packet على المصدر. ارفعها لتكون أكبر من حجم أكبر تغيير صف لديك — وعادةً ما يكون تعيينها إلى الحد الأقصى 1G آمنًا:
    اضبطها أيضًا في تهيئة الخادم لديك (مثل my.cnf أو DB Parameter Group) حتى تبقى سارية بعد إعادة التشغيل.
  • إذا كان صف واحد أكبر من 1G: أعد مزامنة الـ pipe.

لماذا يفشل الـpipe الخاص بي بسبب خطأ JSON جزئي في binlog؟

إذا فشل الـpipe الخاص بك بخطأ مشابه لما يلي:
يعني ذلك أن خادم MySQL المصدر يضبط binlog_row_value_options على PARTIAL_JSON. عند تفعيل هذا الخيار، يسجل MySQL تحديثات أعمدة JSON على شكل فروقات جزئية (المسارات التي تغيّرت فقط) بدلًا من المستند كاملًا. لا يستطيع ClickPipes تطبيق هذه الفروقات الجزئية، لذا لا يمكن لـ CDC المتابعة. لحل المشكلة:
  • عطّل PARTIAL_JSON على المصدر. أعد ضبط القيمة لتكون فارغة:
    أزلها أيضًا من إعدادات الخادم (مثل my.cnf أو مجموعة معلمات DB) لضمان استمرار هذا الإعداد بعد إعادة التشغيل.
  • أعد مزامنة المسار لاستئناف النسخ المتماثل من إزاحة نظيفة.

لماذا يفشل pipe لديّ مع ظهور الخطأ require_secure_transport؟

إذا فشل pipe لديك مع ظهور خطأ مشابه لما يلي:
يعني ذلك أن الخادم المصدر قد فعّل require_secure_transport — إذ يرفض أي اتصال غير مشفّر — بينما تم تعطيل TLS في ClickPipe. في RDS for MySQL، يأتي هذا الإعداد من DB Parameter Group الخاصة بالمثيل. أما في Aurora MySQL، فهو إعداد ضمن DB Parameter Group للمجموعة، ولا يتوفر مطلقًا في مجموعات معلمات المثيلات. لا يتطلب أي منهما إعادة تشغيل حتى يسري مفعوله، وفي Aurora MySQL 8.4 تكون قيمته الافتراضية ON، بينما تكون OFF في الإصدارين 2 و3. لذلك، قد يبدأ pipe كان ينسخ البيانات بصورة سليمة في الفشل بعد تغيير معلمة أو ترقية الإصدار، من دون أي تغيير من جانب pipe. لحل المشكلة:
  • أعِد تفعيل TLS في pipe. من Settings الخاصة بـ pipe، افتح إعدادات الاتصال وأوقِف مفتاح التبديل Disable TLS. إذا ظهر خطأ في الشهادة عند الحفظ، فراجع لماذا أتلقى خطأ في التحقق من شهادة TLS عند الاتصال بـ MySQL؟ لمعرفة كيفية تعيين مضيف TLS، أو تحميل CA جذرية، أو تجاوز التحقق من الشهادة.
  • أو عطّل require_secure_transport في المصدر — ضمن DB Parameter Group في RDS، أو DB Parameter Group للمجموعة في Aurora — إذا كانت الاتصالات غير المشفّرة مقبولة في بيئتك.
تُستأنف النسخ المتماثل من حيث توقفت بمجرد نجاح الاتصال. إذا كان pipe يفشل لمدة أطول من فترة الاحتفاظ بـ binlog (راجع كيف تتم إدارة النسخ المتماثل؟)، فستحتاج إلى إعادة مزامنته.

لماذا يظهر لي خطأ في التحقق من شهادة TLS عند الاتصال بـ MySQL؟

عند الاتصال بـ MySQL، قد تواجه أخطاء في الشهادة مثل x509: certificate is not valid for any names أو x509: certificate signed by unknown authority. يحدث ذلك لأن ClickPipes يفعّل تشفير TLS افتراضيًا. لديك عدة خيارات لمعالجة هذه المشكلات:
  1. عيّن حقل TLS Host - إذا كان اسم المضيف في الاتصال مختلفًا عن الاسم الموجود في الشهادة (وهذا شائع مع AWS PrivateLink عبر Endpoint Service)، فعيّن “TLS Host (optional)” بحيث يطابق الاسم الشائع في الشهادة (CN) أو Subject Alternative Name ‏(SAN).
  2. ارفع Root CA الخاص بك - ينطبق هذا على خوادم MySQL التي تستخدم جهات إصدار شهادات داخلية أو Google Cloud SQL ضمن إعداد CA الافتراضي لكل مثيل. لمزيد من المعلومات حول كيفية الوصول إلى شهادات Google Cloud SQL، راجع هذا القسم.
  3. اضبط شهادة الخادم - حدّث SSL certificate الخاصة بخادمك لتتضمن جميع أسماء المضيفين المستخدمة في الاتصال، واستخدم جهة إصدار شهادات موثوقة.
  4. تخطَّ التحقق من الشهادة - في MySQL أو MariaDB المستضاف ذاتيًا، إذ توفّر الإعدادات الافتراضية شهادة موقعة ذاتيًا لا يمكننا التحقق منها (MySQL، MariaDB). الاعتماد على هذه الشهادة يشفّر البيانات أثناء النقل، لكنه ينطوي على خطر انتحال هوية الخادم. نوصي باستخدام شهادات موقعة على نحو صحيح في بيئات production، لكن هذا الخيار مفيد للاختبار على مثيل لمرة واحدة أو عند الاتصال ببنية تحتية قديمة.

هل تدعمون تغييرات المخطط؟

يُرجى الرجوع إلى صفحة ClickPipes for MySQL: دعم تمرير تغييرات المخطط لمزيد من المعلومات.

هل تدعمون نسخ عمليات الحذف المتسلسل للمفاتيح الخارجية في MySQL ON DELETE CASCADE؟

نظرًا إلى الكيفية التي يتعامل بها MySQL مع عمليات الحذف المتسلسل، فإن هذه العمليات لا تُكتب في binlog. لذلك لا يمكن لـ ClickPipes (أو لأي أداة CDC) نسخها. وقد يؤدي ذلك إلى عدم اتساق البيانات. ويُنصح باستخدام المشغلات بدلًا من ذلك لدعم عمليات الحذف المتسلسل.

لماذا لا يمكنني نسخ جدولي المتماثل إذا كان يحتوي على نقطة؟

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

هل يمكنني تضمين الأعمدة التي استبعدتها في البداية من النسخ المتماثل؟

هذا غير مدعوم بعد. كحل بديل، يمكنك إعادة مزامنة الجدول الذي تريد تضمين أعمدته.
آخر تعديل في ١٤ أغسطس ٢٠٢٦