هل يدعم MySQL ClickPipe MariaDB؟
لماذا فشل الـ pipe الخاص بي بسبب حدث صف جزئي غير مدعوم من MariaDB؟
binlog_row_event_fragment_threshold في المصدر لتقليل تجزئة تغييرات الصفوف — احرص على أن تبقيه أقل من max_allowed_packet، لأن حدث binlog واحدًا غير مُجزّأ يتجاوز max_allowed_packet سيؤدي بدلًا من ذلك إلى فشل تدفق النسخ المتماثل (راجع لماذا يفشل الـ pipe الخاص بي بسبب خطأ binlog متعلق بـ max_allowed_packet؟).
لماذا فشل الـ pipe الخاص بي بسبب عمود COMPRESSED غير مدعوم في MariaDB؟
COLUMN_FORMAT COMPRESSED). لا يمكننا فك ضغط هذه القيم من binlog، لذلك لا يمكن نسخ الجدول المتأثر عبر CDC.
لحل ذلك:
- حوّل الأعمدة المضغوطة إلى نوع غير مضغوط في المصدر (أو أزل جدولًا من pipe):
- أعد مزامنة الجدول أو pipe
هل يدعم MySQL ClickPipe أيًا من PlanetScale أو Vitess أو TiDB؟
كيف تُدار عملية النسخ المتماثل؟
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؟
max_allowed_packet على خادم MySQL لديك. وبما أن الخادم لا يمكنه إرسال حدث يتجاوز هذا الحد، تتوقف قراءة تدفق binlog ولا يعود بإمكان CDC التقدم.
يحدث هذا غالبًا بسبب صفوف تحتوي على قيم BLOB أو TEXT أو JSON كبيرة. لحل هذه المشكلة:
- زِد قيمة
max_allowed_packetعلى المصدر. ارفعها لتكون أكبر من حجم أكبر تغيير صف لديك — وعادةً ما يكون تعيينها إلى الحد الأقصى1Gآمنًا:اضبطها أيضًا في تهيئة الخادم لديك (مثلmy.cnfأوDB Parameter Group) حتى تبقى سارية بعد إعادة التشغيل. - إذا كان صف واحد أكبر من 1G: أعد مزامنة الـ pipe.
لماذا يفشل الـpipe الخاص بي بسبب خطأ JSON جزئي في binlog؟
binlog_row_value_options على PARTIAL_JSON. عند تفعيل هذا الخيار، يسجل MySQL تحديثات أعمدة JSON على شكل فروقات جزئية (المسارات التي تغيّرت فقط) بدلًا من المستند كاملًا. لا يستطيع ClickPipes تطبيق هذه الفروقات الجزئية، لذا لا يمكن لـ CDC المتابعة.
لحل المشكلة:
- عطّل
PARTIAL_JSONعلى المصدر. أعد ضبط القيمة لتكون فارغة:أزلها أيضًا من إعدادات الخادم (مثلmy.cnfأو مجموعة معلمات DB) لضمان استمرار هذا الإعداد بعد إعادة التشغيل. - أعد مزامنة المسار لاستئناف النسخ المتماثل من إزاحة نظيفة.
لماذا يفشل pipe لديّ مع ظهور الخطأ require_secure_transport؟
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 — إذا كانت الاتصالات غير المشفّرة مقبولة في بيئتك.
لماذا يظهر لي خطأ في التحقق من شهادة TLS عند الاتصال بـ MySQL؟
x509: certificate is not valid for any names أو x509: certificate signed by unknown authority. يحدث ذلك لأن ClickPipes يفعّل تشفير TLS افتراضيًا.
لديك عدة خيارات لمعالجة هذه المشكلات:
- عيّن حقل TLS Host - إذا كان اسم المضيف في الاتصال مختلفًا عن الاسم الموجود في الشهادة (وهذا شائع مع AWS PrivateLink عبر Endpoint Service)، فعيّن “TLS Host (optional)” بحيث يطابق الاسم الشائع في الشهادة (CN) أو Subject Alternative Name (SAN).
- ارفع Root CA الخاص بك - ينطبق هذا على خوادم MySQL التي تستخدم جهات إصدار شهادات داخلية أو Google Cloud SQL ضمن إعداد CA الافتراضي لكل مثيل. لمزيد من المعلومات حول كيفية الوصول إلى شهادات Google Cloud SQL، راجع هذا القسم.
- اضبط شهادة الخادم - حدّث SSL certificate الخاصة بخادمك لتتضمن جميع أسماء المضيفين المستخدمة في الاتصال، واستخدم جهة إصدار شهادات موثوقة.
- تخطَّ التحقق من الشهادة - في MySQL أو MariaDB المستضاف ذاتيًا، إذ توفّر الإعدادات الافتراضية شهادة موقعة ذاتيًا لا يمكننا التحقق منها (MySQL، MariaDB). الاعتماد على هذه الشهادة يشفّر البيانات أثناء النقل، لكنه ينطوي على خطر انتحال هوية الخادم. نوصي باستخدام شهادات موقعة على نحو صحيح في بيئات production، لكن هذا الخيار مفيد للاختبار على مثيل لمرة واحدة أو عند الاتصال ببنية تحتية قديمة.