التوفير والمرونة في قواعد البيانات مع MaxScale

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

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

الهيكلة المعمارية

يوضح الرسم التخطيطي التالي الهيكلة المعمارية لتطبيق العرض التوضيحي:

A web application developed with JavaScript and the Svelte framework makes HTTP requests to a Java backend. The backend answers with server-sent events that the frontend uses to update the user interface on the browser.

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

• زيارات المنتجات في الدقيقة: عدد القراءات إلى قاعدة البيانات في الدقيقة.
• طلبات في الدقيقة: عدد الكتابات إلى قاعدة البيانات في الدقيقة.
• المنتجات لكل طلب: تكبير الكتابة.
• الزمن المنقضي بالميلي ثانية: عدد الثواني حتى يُعتبر طلب لقاعدة البيانات قد فشل.

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

بناء صور Docker من المصدر

I have prepared custom Docker images for every component in the simulator. You can either build the images from the source (optional) or use the already built and published images from Docker Hub. If you decide to build the images yourself, you can find the source code on GitHub:

• توزيعات MariaDB: صور مخصصة لتوضيح توزيع مشاركة لتوزيعات MariaDB باستخدام MaxScale. لا تستخدم هذه في الإنتاج! هذه الصور مناسبة فقط لتطبيقات العرض. استخدم صور Docker الرسمية لـ MariaDB للتوزيعات الإنتاجية.
• تطبيق الخلفية: تطبيق الخلفية الذي يتصل بمجموعة قواعد البيانات.
• تطبيق الواجهة الأمامية: تطبيق الواجهة الأمامية الذي يطلب تكوين المحاكاة من الخلفية ويستقبل الأحداث لإظهار نتيجة المحاكاة.

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

docker build --tag alejandrodu/online-store-simulator-java-backend .

تشغيل المحاكاة

يمكن بدء جميع الخدمات باستخدام ملف Docker Compose التالي (docker-compose.yml):

version: "3.9"
services:
  server-1:
    container_name: server-1
    image: alejandrodu/mariadb
    ports:
      - "3306:3306"
    environment:
      - MARIADB_CREATE_DATABASE=demo
      - MARIADB_CREATE_USER=user:Password123!
      - MARIADB_CREATE_REPLICATION_USER=replication_user:ReplicationPassword123!
      - MARIADB_CREATE_MAXSCALE_USER=maxscale_user:MaxScalePassword123!

  server-2:
    container_name: server-2
    image: alejandrodu/mariadb
    ports:
      - "3307:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  server-3:
    container_name: server-3
    image: alejandrodu/mariadb
    ports:
      - "3308:3306"
    environment:
      - MARIADB_REPLICATE_FROM=replication_user:ReplicationPassword123!@server-1:3306

  maxscale:
    container_name: maxscale
    image: alejandrodu/mariadb-maxscale
    command: --admin_host 0.0.0.0 --admin_secure_gui false
    ports:
      - "4000:4000"
      - "8989:8989"
      - "27017:27017"
    environment:
      - MAXSCALE_USER=maxscale_user:MaxScalePassword123!
      - MARIADB_HOST_1=server-1 3306
      - MARIADB_HOST_2=server-2 3306
      - MARIADB_HOST_3=server-3 3306
    healthcheck:
      test: ["CMD", "maxctrl", "list", "servers"]
      interval: 5s
      timeout: 10s
      retries: 5

  java-backend:
    container_name: java-backend
    image: alejandrodu/online-store-simulator-java-backend
    ports:
      - "8080:8080"
    environment:
    - spring.r2dbc.url=r2dbc:mariadb://maxscale:4000/demo
    - spring.r2dbc.username=user
    - spring.r2dbc.password=Password123!
    - spring.liquibase.url=jdbc:mariadb://maxscale:4000/demo
    - spring.liquibase.user=user
    - spring.liquibase.password=Password123!
    depends_on:
      maxscale:
        condition: service_healthy

  svelte-frontend:
    container_name: svelte-fronted
    image: alejandrodu/online-store-simulator-svelte-frontend
    ports:
      - "5173:80"
    environment:
      - BACKEND_URL=http://java-backend:8080

انتقل إلى الدليل الذي يوجد به ملف Docker Compose، وبدء الخدمات بوضع منفصل كما يلي:

docker compose up -d

تكوين MaxScale

قبل بدء المحاكاة، قم بتكوين MaxScale لإعادة لعب المعاملات. أيضاً، قم بتعديل مهلات التوقيت لجعل المحاكاة أكثر تشويقاً.

انتقل إلى http://localhost:8989/ وقم بتسجيل الدخول إلى الواجهة باستخدام:

• اسم المستخدم:admin
• كلمة المرور:mariadb

سترى tableau تفاعلي يعرض حالة خوادم الـ MariaDB.

يوجد خادم أساسي (server-1)، واثنين من النسخ الاحتياطية (server-2 و server-3). تم تكوين التكرار مسبقاً من server-1 (الأساسي) إلى server-2 و server-3 (النسخ الاحتياطية). يجب أن تكون جميع الخوادم متاحة وتعمل.

انقر على mdb_monitor ثم على أيقونة القلم لتمكين تحرير المعلمات. ضع المعلمات التالية:

• auto_failover (true): يتيح هذا التحول التلقائي. عندما يكون خادم MariaDB غير متاح، يختار MaxScale خادم نسخ احتياطي ويعيد تكوينه كخادم أساسي جديد لكي يستمر الكتابة في الحدوث.
• auto_rejoin (true): يتيح هذا إعادة الانضمام التلقائي للخوادم التي تعود للعمل. عندما يعود خادم فات للعمل مرة أخرى، يكتشفه MaxScale ويكونينه كخادم نسخ احتياطي متاح.
• failcount (1): يحدد عدد تكرارات المراقبة (المكون في MaxScale الذي يتحقق من حالة الخادم) اللازمة لكي يُعتبر الخادم غير متاح من أجل تنشيط عملية التحول. قمنا بتحديد قيمة 1 للتأكد من بدء التحول على الفور بعد الفشل.
• backend_connect_timeout (1000): يحدد وقت الانتظار لاتصالات المراقبة. قمنا بتحديد قيمة منخفضة (ثانية واحدة) لتنشيط التحول بسرور لهذه العرض.
• backend_read_timeout (1000): زمن الانتظار لقراءة الاتصالات المراقبة.
• backend_write_timeout (1000): زمن الانتظار لكتابة الاتصالات المراقبة.
• master_failure_timeout (1000): زمن الانتظار لفشل المسيطر.
• monitor_interval (1000): فترة مراقبة الخوادم.

تحذير: قيم هذه الأرقام مناسبة لهذا العرض التوضيحي لكنها غالباً ليست الأفضل للبيئات الإنتاجية!

بمجرد تعيين المعلمات، انقر على تم التحرير و تأكيد.

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

في القائمة الرئيسية، انقر على لوحة المعلومات ثم على أيٍ من روابط خدمة توجيه الاستعلام في قائمة الخوادم. تحرير المعلمات على النحو التالي:

• transaction_replay (true): تنشيط إعادة محاولة المعاملات الفاشلة تلقائياً.
• transaction_replay_retry_on_deadlock (true): مثل السابق عند حدوث تعطل.
• transaction_replay_retry_on_mismatch (true): مثل السابق عند حدوث خطأ في المطابقة.

بمجرد تعيين المعلمات، انقر على تم التحرير و تأكيد.

بدء المحاكاة

مع تكوين كل شيء، يمكنك بدء المحاكاة. انتقل إلى http://localhost:5173/ وقم بتكوين المعلمات التالية (أتمنى أن تكون الأسماء واضحة بما فيه الكفاية):

• الزيارات إلى المنتج في الدقيقة:6000
• طلبات في الدقيقة:60
• المهلة في مللي ثانية:8000

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

الآن يمكنك أخيرًا النقر على بدء ورؤية المحاكاة في العمل.

محاكاة فشل الخادم

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

docker stop server-1

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

بدء الخادم المعطل:

docker start server-1

انتقل إلى لوحة التحكم MaxScale لوحة التحكم (http://localhost:8989/) وتحقق من أن server-1 الآن نسخة تكرارية مفعلة.

يمكنك إجراء تحول يدوي لجعل الخادم-1 الخادم الرئيسي مرة أخرى. انقر على مراقبة_mdb ثم حدد بالماوس القسم الرئيسي. انقر على أيقونة القلم واختر الخادم-1. انقر تبديل وتحقق مرة أخرى في لوحة المعلومات أن الخادم الرئيسي الجديد هو الخادم-1.

الخاتمة

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