> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # MySQL أم MariaDB؟ ومتى تختار أياً منهما - URL: https://arabroot.io/articles/mysql-ام-mariadb-ومتى-تختار-ايا-منهما/ - Published: 2026-10-12T10:00:00.000Z - Updated: 2026-10-11T11:18:16.000Z - Description: لماذا لم يعد MariaDB نسخة من MySQL، وأين ينكسر نقل تطبيقك بينهما، وكيف تختار الأنسب لك. - Author: فريق عرب رووت - Tags: الأدلة التقنية, هندسة البرمجيات وتصميم الأنظمة, قواعد البيانات, الاستضافة الذاتية عندما تقوم بتثبيت تطبيق مثل [WordPress](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-wordpress-%D9%85%D8%B9-docker-compose/) أو [BookStack](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-bookstack-%D9%84%D8%AA%D9%88%D8%AB%D9%8A%D9%82-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82/) سوف تجد في التوثيق جملة مثل «يعمل مع MySQL أو MariaDB»، وكأن الاثنين اسمان لشيء واحد، وهذا كان صحيحاً تقريباً قبل خمسة عشر عاماً، أما اليوم فهما قاعدتا بيانات مختلفتان تتشاركان الأصل والبروتوكول وأغلب لغة SQL، وتختلفان في أشياء كثيرة لن تراها حتى تنقل بياناتك من واحدة إلى الأخرى أو تكتب استعلاماً يعمل على واحدة ويفشل على الأخرى. وفي [مقال أنواع قواعد البيانات](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D9%85%D8%AA%D9%89-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D9%83%D9%84-%D9%86%D9%88%D8%B9/) تكلمنا عن القواعد العلائقية Relational بشكل عام، وهنا سوف ننزل إلى الاثنين بالتحديد ونشغلهما جنباً إلى جنب على نفس الجدول ونفس الاستعلامات حتى نرى بالضبط أين يتوقف التطبيق. وسوف نناقش في هذا المقال ما يلي: - كيف خرج MariaDB من MySQL، ومن يملك كل واحد منهما اليوم. - الرخص: ما المفتوح وما المغلق وما الذي يقع بينهما. - التوافق Compatibility اليوم: ما الذي ما زال مشتركاً وأين ينكسر. - تجربة عملية على MySQL 9.7.2 وMariaDB 12.3.3 بمليون طلب، مع أربعة أماكن ينكسر فيها النقل. - النسخ المتماثل Replication والعناقيد في كل منهما. - متى تختار كل واحد، وكيف تنقل بياناتك من MySQL إلى MariaDB دون مفاجآت. ## من أين جاء MariaDB؟ ظهرت أول نسخة من MySQL في 23 مايو 1995 من شركة سويدية اسمها MySQL AB، وفي يناير 2008 اشترتها Sun Microsystems بمليار دولار، ثم أعلنت Oracle شراء Sun في 2009 وأكملت الصفقة في 27 يناير 2010 كما يذكر [سجل MySQL](https://en.wikipedia.org/wiki/MySQL?ref=arabroot.io). وهنا ظهرت المشكلة التي أنتجت MariaDB، فOracle تبيع أشهر قاعدة بيانات تجارية في العالم، وأصبحت الآن تملك أشهر منافس مفتوح لها، فقام Michael Widenius الملقب Monty، وهو أحد مؤسسي MySQL الأصليين، بعمل نسخة مستقلة Fork من الكود في 2009 وسماها MariaDB على اسم ابنته الصغرى (كما سمى MySQL قبلها على اسم ابنته My)، وصدرت أول نسخة منها 5.1.38 في 29 أكتوبر 2009 بحسب [سجل MariaDB](https://en.wikipedia.org/wiki/MariaDB?ref=arabroot.io)، والهدف المعلن أن يبقى الكود تحت رخصة GPL دون أن يعتمد مصيره على شركة واحدة. والصورة التالية تبين الخطين على محور زمني واحد: ![محور زمني بخطين: خط MySQL يبدأ بأول إصدار في 1995 ثم شراء Sun لشركة MySQL AB في 2008 ثم امتلاك Oracle لها في 2010 ثم 8.4 LTS في 2024 ثم 9.7 LTS في 2026 والانتقال إلى أرقام إصدارات بالتاريخ، وخط MariaDB يتفرع منه في 2009 بالإصدار 5.1.38 ثم إدراج MariaDB plc في بورصة نيويورك في 2022 ثم شراء K1 لها في 2024 ثم Galera وSkySQL في 2025 ثم 12.3 LTS في مايو 2026](https://arabroot.io/content/images/2026/10/mysql-mariadb-01-family.webp) MariaDB خرج من MySQL في 2009، وبعدها سار كل منهما في طريقه بإصداراته وملاكه وفي السنوات الأولى كان MariaDB نسخة من MySQL بأرقام الإصدار نفسها، تستطيع أن تضعه مكانها على نفس الملفات ويعمل التطبيق دون أن يشعر، ولكن منذ MariaDB 10.0 بدأت الأرقام تفترق، ومنذ MySQL 8.0 افترق شكل الملفات على القرص نفسه كما سوف نرى في التجربة، ولذلك صفحة [التوافق في توثيق MariaDB](https://mariadb.com/docs/release-notes/community-server/about/compatibility-and-differences/mariadb-vs-mysql-compatibility?ref=arabroot.io) تصف كل إصدار بعد MariaDB 10.4 بقائمة اختلافات، وليس بأنه بديل مباشر Drop-in Replacement. ## من يملك كل واحد منهما اليوم؟ هذا السؤال مهم أكثر مما يبدو، والسبب أن من يملك الكود ويوظف أغلب المطورين هو الذي يحدد ماذا يدخل في الإصدار القادم وماذا يبقى في النسخة التجارية فقط. - **MySQL:** تملكها Oracle بالكامل، وهي التي تكتب الكود وتصدر النسخة المجانية Community والنسخة التجارية Enterprise. ونموذج الإصدارات بحسب [صفحة الإصدارات](https://dev.mysql.com/doc/refman/9.7/en/mysql-releases.html?ref=arabroot.io) فيه مساران: إصدارات طويلة الدعم LTS لا تحذف فيها ميزات وتدعم ثماني سنوات (خمس دعم أساسي وثلاث ممتدة)، وإصدارات الابتكار Innovation التي تأتي بالميزات الجديدة وتغير السلوك ويدعم كل منها حتى يصدر الذي بعده. وكان آخر إصدار LTS هو 9.7 في أبريل 2026 بعد 8.4 في 2024، والصفحة نفسها تقول إن 9.7 آخر إصدار بالأرقام المتتالية، وبعده تستخدم MySQL أرقاماً بالتاريخ بالشكل YY.M مثل 26.7. - **MariaDB:** هنا جهتان. الأولى [مؤسسة MariaDB Foundation](https://mariadb.org/about/?ref=arabroot.io)، وهي جهة غير ربحية مهمتها أن يبقى كود MariaDB Server مفتوحاً للاستخدام والمساهمة مستقلاً عن أي شركة. والثانية الشركة MariaDB plc التي توظف أغلب المطورين وتبيع النسخة Enterprise والدعم. هذه الشركة دخلت بورصة نيويورك في ديسمبر 2022، ثم [اشترتها K1 Investment Management](https://mariadb.com/newsroom/press-releases/k1-acquires-a-leading-database-software-company-mariadb-and-appoints-new-ceo/?ref=arabroot.io) في سبتمبر 2024 وأخرجتها من البورصة، وبعدها [اشترت Codership](https://mariadb.com/newsroom/press-releases/mariadb-acquires-galera-cluster/?ref=arabroot.io) صاحبة Galera Cluster في مايو 2025، و[أعادت شراء SkySQL](https://mariadb.com/newsroom/press-releases/mariadb-accelerates-cloud-deployments-adds-agentic-ai-and-serverless-capability-with-acquisition-of-skysql/?ref=arabroot.io) في أغسطس 2025\. وسياسة الإصدارات في [صفحة المؤسسة](https://mariadb.org/about/?ref=arabroot.io) أن يصدر إصدار LTS جديد كل سنة، يدعم مجاناً ثلاث سنوات بعد صدوره، وآخرها 12.3 الذي صدر في 28 مايو 2026 ويدعم حتى يونيو 2029، وقبله 11.8 حتى يونيو 2028 و11.4 حتى مايو 2029. وقد يتساءل البعض: هل يعني تغير ملاك الشركة أن MariaDB قد تغير رخصتها كما فعلت Redis وMongoDB؟ والإجابة أن الكود الأساسي مسجل باسم كثير من المساهمين تحت GPLv2، والمؤسسة تملك الاسم والمستودع، وهذا يجعل تغيير الرخصة صعباً جداً، ولكن الأدوات الجانبية التي تكتبها الشركة وحدها قصة أخرى كما سوف نرى في القسم التالي. ## الرخص: ما المفتوح وما المغلق؟ شرحنا معنى GPL وCopyleft والرخص التي تسمى مصدراً متاحاً Source Available في [مقال الرخص](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/)، والمهم هنا أن تعرف ماذا يقع تحت كل رخصة: | الجزء | MySQL | MariaDB | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | السيرفر | GPLv2 للنسخة Community كما في [ملف الرخصة](https://github.com/mysql/mysql-server/blob/trunk/LICENSE?ref=arabroot.io)، ورخصة تجارية من Oracle لمن يريد أن يدمجها في منتج مغلق | GPLv2 كما في [المستودع](https://github.com/MariaDB/server?ref=arabroot.io) | | النسخ الاحتياطي الساخن Hot Backup | MySQL Enterprise Backup تجاري، والبديل المفتوح من خارج Oracle | [mariadb-backup](https://mariadb.com/docs/server/server-usage/backup-and-restore/mariadb-backup?ref=arabroot.io) داخل النسخة المجانية | | Thread Pool والتدقيق Audit والتشفير على القرص | ضمن [MySQL Enterprise](https://www.mysql.com/products/enterprise/?ref=arabroot.io) التجارية | [Thread Pool](https://mariadb.com/docs/server/ha-and-performance/optimization-and-tuning/buffers-caches-and-threads/thread-pool/thread-pool-in-mariadb?ref=arabroot.io) و[Audit Plugin](https://mariadb.com/docs/server/reference/plugins/mariadb-audit-plugin?ref=arabroot.io) و[التشفير](https://mariadb.com/docs/server/security/encryption/data-at-rest-encryption?ref=arabroot.io) في النسخة المجانية | | البروكسي | MySQL Router تحت GPLv2 | [MaxScale تحت BSL 1.1](https://github.com/mariadb-corporation/MaxScale/blob/develop/licenses/LICENSE2408.TXT?ref=arabroot.io)، مجاني لأقل من ثلاثة سيرفرات في الإنتاج، ويتحول إلى GPL بعد تاريخ محدد لكل إصدار | ولاحظ أن رخصة GPL لا تمنعك من تشغيل أي منهما داخل شركتك أو خلف تطبيقك على الإنترنت، فهي تتعلق بتوزيع البرنامج نفسه، ولذلك أغلب من يستضيف تطبيقاته لن يلمس فرقاً في الرخصة، والفرق الحقيقي هو في الميزات التي تحتاجها، مثل النسخ الاحتياطي الساخن وThread Pool، وهل هي في النسخة المجانية أم في نسخة تدفع ثمنها. ## التوافق اليوم: ما الذي ما زال مشتركاً؟ الكثير ما زال مشتركاً، وهذا هو سبب انتشار جملة «MySQL أو MariaDB» في التوثيق: نفس بروتوكول الاتصال على المنفذ 3306، لذلك أغلب المكتبات Drivers تتصل بالاثنين، ونفس محرك التخزين الافتراضي InnoDB، ونفس أوامر SQL الأساسية من SELECT وJOIN والمفاتيح الأجنبية Foreign Keys والمعاملات Transactions، ونفس شكل ملف `my.cnf` في أغلب الإعدادات، ونفس الأمر `mysqldump` للنسخ المنطقي. وتطبيق يكتب SQL عادياً عبر ORM لن يرى في الغالب أي فرق. أما الاختلافات فتظهر في خمسة أماكن، وكل واحد منها سوف نراه في التجربة: - **JSON:** في MySQL هو نوع حقيقي يخزن بصيغة ثنائية Binary ويقارن كقيم JSON، وفي MariaDB هو اسم آخر لـ LONGTEXT مع شرط CHECK يتحقق أن النص JSON صالح، كما في [توثيق نوع JSON](https://mariadb.com/docs/server/reference/data-types/string-data-types/json?ref=arabroot.io)، والمعامل `->>` المختصر غير موجود في MariaDB. - **الصياغة الإضافية:** كل واحد أضاف أشياء ليست عند الآخر، فMariaDB عنده [INSERT … RETURNING](https://mariadb.com/docs/server/reference/sql-statements/data-manipulation/inserting-loading-data/insertreturning?ref=arabroot.io) و[السلاسل Sequences](https://mariadb.com/docs/server/reference/sql-structure/sequences?ref=arabroot.io)، وMySQL عنده أشياء مثل المعاملات المختصرة لل JSON. - **ال GTID في النسخ المتماثل:** MySQL يكتبه بالشكل `UUID:رقم`، وMariaDB بالشكل `Domain-ServerID-رقم`، والصيغتان غير متوافقتين بحسب [مصفوفة التوافق](https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/moving-from-mysql/mysql-to-mariadb-compatibility-matrix?ref=arabroot.io). - **المصادقة Authentication:** MySQL يستخدم `caching_sha2_password` افتراضياً وعطل `mysql_native_password` افتراضياً منذ 8.4، وMariaDB ما زال يستخدم `mysql_native_password` للمستخدمين الذين ينشئهم. - **الملفات على القرص:** MySQL 8.0 حذف ملفات `.frm` ووضع تعريف الجداول في قاموس بيانات Data Dictionary داخلي، وMariaDB ما زال يحتاج `.frm`، ولذلك يقول [دليل النقل](https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/moving-from-mysql/mysql-to-mariadb-migration-the-master-guide?ref=arabroot.io) إن الانتقال من MySQL 8 لا يكون إلا بنسخة منطقية Dump ثم استعادتها. والصورة التالية تلخص ما خرج من التجربة: ![جدول بثلاثة أعمدة: الأمر، ونتيجته على MySQL 9.7، ونتيجته على MariaDB 12.3. إنشاء جدول بعمود JSON يعمل على الاثنين لكن MySQL يخزنه JSON ثنائياً وMariaDB يخزنه LONGTEXT مع CHECK، والمعامل ->> يعمل على MySQL ويعطي ERROR 1064 على MariaDB، وINSERT RETURNING يعطي ERROR 1064 على MySQL ويعمل على MariaDB، وملف mysqldump من MySQL يتوقف عند استيراده في MariaDB بخطأ 1193 بسبب GTID_PURGED، ونسخ مجلد البيانات لا يعمل لأن MySQL لا يملك ملفات frm، وJSON_VALUE يعمل على الاثنين](https://arabroot.io/content/images/2026/10/mysql-mariadb-02-what-breaks.webp) أغلب SQL يعمل على الاثنين، والانكسار في ال JSON والصياغة الإضافية وملفات النسخ ومجلد البيانات ## تجربة عملية: نفس الجدول على السيرفرين سوف نشغل MySQL 9.7.2 (إصدار LTS) وMariaDB 12.3.3 (إصدار LTS) جنباً إلى جنب، وننشئ نفس الجدول، ونحمل فيه نفس مليون طلب، ثم نشغل نفس الاستعلامات. والتجربة تعمل على Docker Engine 29.8.0 في Docker Desktop مع WSL2 على جهاز بثمانية أنوية و32 GB ذاكرة، والأرقام للتوضيح فقط وليست قياس أداء Benchmark، والسبب أن ملف البيانات يقرأ من مجلد Windows مشترك وهو أبطأ من قرص سيرفر حقيقي، والإعدادات كلها افتراضية. ### ملفات التجربة الملف الأول يولد مليون طلب ثابت في كل مرة (البذرة Seed ثابتة)، وهو نفس الملف الذي سوف نستخدمه في مقالات MongoDB وClickHouse والمقارنة حتى تكون الأرقام على نفس البيانات: ```python # Writes orders.csv: the same 1,000,000 orders used by the database labs of ArabRoot (fixed seed, same file every time). # python gen_orders.py [rows] import csv, random, sys from datetime import datetime, timedelta N = int(sys.argv[1]) if len(sys.argv) > 1 else 1_000_000 rnd = random.Random(42) countries = ['SA', 'EG', 'AE', 'JO', 'MA', 'KW', 'QA', 'DZ'] statuses = ['paid'] * 7 + ['refunded', 'cancelled', 'pending'] start = datetime(2025, 1, 1) with open('orders.csv', 'w', newline='') as f: w = csv.writer(f) for i in range(1, N + 1): ts = start + timedelta(seconds=rnd.randrange(0, 365 * 86400)) w.writerow([i, rnd.randrange(1, 100_001), rnd.choice(countries), rnd.choice(statuses), f'{rnd.uniform(5, 900):.2f}', ts.strftime('%Y-%m-%d %H:%M:%S')]) print(f'{N} rows written to orders.csv') ``` والملف `compose.yaml` يشغل السيرفرين على منفذين مختلفين مربوطين بالعنوان 127.0.0.1 فقط: ```yaml # The same schema and queries on MySQL and MariaDB, side by side (ArabRoot lab). # docker compose -p lab-mysqlmaria up -d name: lab-mysqlmaria services: mysql: image: mysql:9.7.2 container_name: lab-mysqlmaria-mysql environment: MYSQL_ROOT_PASSWORD: lab-root-pass MYSQL_DATABASE: shop command: ["--local-infile=1"] ports: ["127.0.0.1:33061:3306"] volumes: ["./:/lab:ro", "mysql-data:/var/lib/mysql"] mariadb: image: mariadb:12.3.3 container_name: lab-mysqlmaria-mariadb environment: MARIADB_ROOT_PASSWORD: lab-root-pass MARIADB_DATABASE: shop ports: ["127.0.0.1:33062:3306"] volumes: ["./:/lab:ro", "mariadb-data:/var/lib/mysql"] volumes: mysql-data: mariadb-data: ``` والجدول في الملف `schema.sql`، وهو نفسه للسيرفرين: ```sql -- The same table on both servers CREATE TABLE orders ( id BIGINT PRIMARY KEY, customer_id INT NOT NULL, country CHAR(2) NOT NULL, status VARCHAR(12) NOT NULL, amount DECIMAL(10,2) NOT NULL CHECK (amount > 0), created_at DATETIME NOT NULL, extra JSON NULL, KEY idx_customer (customer_id), KEY idx_created (created_at) ); ``` الآن نقوم بتوليد البيانات وتشغيل السيرفرين وإنشاء الجدول: ```bash python gen_orders.py docker compose -p lab-mysqlmaria up -d docker exec -i lab-mysqlmaria-mysql mysql -uroot -plab-root-pass shop < schema.sql docker exec -i lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass shop < schema.sql ``` ### نفس الجدول، وتعريفان مختلفان الجدول أنشئ على الاثنين دون أي خطأ، ولكن لنطلب من كل سيرفر أن يرينا كيف فهمه بالأمر `SHOW CREATE TABLE`: ```bash docker exec lab-mysqlmaria-mysql mysql -uroot -plab-root-pass shop -E -e "SHOW CREATE TABLE orders" docker exec lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass shop -E -e "SHOW CREATE TABLE orders" ``` والمخرج من MySQL سوف يكون كما يلي: ```text Create Table: CREATE TABLE `orders` ( `id` bigint NOT NULL, `customer_id` int NOT NULL, `country` char(2) NOT NULL, `status` varchar(12) NOT NULL, `amount` decimal(10,2) NOT NULL, `created_at` datetime NOT NULL, `extra` json DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_customer` (`customer_id`), KEY `idx_created` (`created_at`), CONSTRAINT `orders_chk_1` CHECK ((`amount` > 0)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ``` والمخرج من MariaDB: ```text Create Table: CREATE TABLE `orders` ( `id` bigint(20) NOT NULL, `customer_id` int(11) NOT NULL, `country` char(2) NOT NULL, `status` varchar(12) NOT NULL, `amount` decimal(10,2) NOT NULL CHECK (`amount` > 0), `created_at` datetime NOT NULL, `extra` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL CHECK (json_valid(`extra`)), PRIMARY KEY (`id`), KEY `idx_customer` (`customer_id`), KEY `idx_created` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_uca1400_ai_ci ``` في المخرج أعلاه لاحظ التالي: - العمود `extra` نوعه `json` في MySQL، أما في MariaDB فهو `longtext` مع `CHECK (json_valid(...))`، فالقيمة تحفظ نصاً ويتحقق السيرفر فقط أنها JSON صالح. - الترتيب الافتراضي للنصوص Collation مختلف: `utf8mb4_0900_ai_ci` في MySQL و`utf8mb4_uca1400_ai_ci` في MariaDB، والاثنان لا يفرقان بين الحروف الكبيرة والصغيرة، ولكن المقارنة بين عمودين بترتيبين مختلفين في JOIN قد تمنع استخدام الفهرس. - MariaDB ما زال يكتب العرض `bigint(20)` و`int(11)`، وMySQL توقف عن ذلك، وهذا شكلي فقط ولكنه يظهر في أي أداة تقارن تعريفات الجداول. ### تحميل مليون طلب نحمل الملف في الاثنين بالأمر `LOAD DATA LOCAL INFILE`، ونقيس الوقت من خارج ال Container: ```bash L="LOAD DATA LOCAL INFILE '/lab/orders.csv' INTO TABLE orders FIELDS TERMINATED BY ',' (id,customer_id,country,status,amount,created_at)" time docker exec lab-mysqlmaria-mysql mysql --local-infile=1 -uroot -plab-root-pass shop -e "$L" time docker exec lab-mysqlmaria-mariadb mariadb --local-infile=1 -uroot -plab-root-pass shop -e "$L" ``` والمخرج سوف يكون كما يلي (الأول MySQL والثاني MariaDB): ```text real 1m48.032s real 0m58.479s ``` ثم ثلاثة استعلامات، كل واحد ثلاث مرات: مجموع المبيعات المدفوعة لكل دولة (يقرأ الجدول كله)، وطلبات عميل واحد (فهرس `idx_customer`)، وطلبات يوم واحد (فهرس `idx_created`). والوقت الذي يطبعه العميل بالخيار `-vvv` كان كما يلي: | الاستعلام | MySQL 9.7.2 | MariaDB 12.3.3 | | ---------------------------------- | ----------------------------- | ----------------------------- | | تحميل مليون صف | 1m48s | 58s | | GROUP BY country على الجدول كله | 4.106 ثم 1.654 ثم 2.383 ثانية | 4.442 ثم 2.421 ثم 2.507 ثانية | | طلبات عميل واحد بالفهرس | 0.001 ثانية | 0.001 إلى 0.002 ثانية | | طلبات يوم واحد بالفهرس | 0.002 إلى 0.007 ثانية | 0.001 إلى 0.012 ثانية | | حجم البيانات والفهارس بعد ANALYZE | 53 MB و67 MB | 53 MB و67 MB | | الذاكرة بعد التحميل (docker stats) | 630.8 MiB | 234.1 MiB | والنتيجة نفسها على السيرفرين، وهذا جزء منها: ```text country orders revenue SA 87916 39867208.77 QA 87834 39609909.90 KW 87524 39566498.31 ``` وهل يعني هذا أن MariaDB أسرع في التحميل؟ لا يمكن أن نقول ذلك من تجربة واحدة بإعدادات افتراضية، والسبب أن الإعدادات الافتراضية نفسها مختلفة بين الاثنين، والاستعلامات بالفهرس متساوية تقريباً، واستعلام الجدول الكامل متقارب. والدرس الحقيقي من الجدول أن الأداء ليس هو ما يفرق بين الاثنين في تطبيق عادي، وإنما التوافق والميزات والرخص. أما الذاكرة فاستهلاك MySQL بعد التحميل كان قرابة ثلاثة أضعاف MariaDB بالإعدادات الافتراضية، وهذا يهم إذا كان السيرفر صغيراً، فراجع الإعدادات قبل أن تحكم. ### الانكسار الأول: المعامل المختصر لل JSON لنفرض أن التطبيق يحفظ كود الخصم في العمود `extra` ويقرؤه بالطريقة المختصرة التي يكتبها أغلب المطورين على MySQL: ```sql UPDATE orders SET extra='{"coupon":"RAMADAN","items":3}' WHERE id=1; SELECT id, extra->>'$.coupon' AS coupon FROM orders WHERE id=1; ``` على MySQL يعطي `RAMADAN`، وعلى MariaDB يكون المخرج كما يلي: ```text ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '>>'$.coupon' AS coupon FROM orders WHERE id=1' at line 1 ``` والحل أن تكتب الدوال التي يفهمها الاثنان، فالأمران التاليان أعطيا `RAMADAN` على السيرفرين: ```sql SELECT id, JSON_VALUE(extra,'$.coupon') AS coupon FROM orders WHERE id=1; SELECT JSON_UNQUOTE(JSON_EXTRACT(extra,'$.coupon')) AS coupon FROM orders WHERE id=1; ``` ### الانكسار الثاني: INSERT … RETURNING والعكس أيضاً يحدث، فMariaDB يسمح لك بأن تحصل على الصف الذي أدخلته في نفس الأمر: ```sql INSERT INTO orders (id,customer_id,country,status,amount,created_at) VALUES (1000001,7,'SA','paid',50,NOW()) RETURNING id, created_at; ``` والمخرج على MariaDB: ```text id created_at 1000001 2026-10-10 05:43:31 ``` أما على MySQL: ```text ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'RETURNING id, created_at' at line 1 ``` ولاحظ أن رقم الخطأ نفسه 1064 في الحالتين، وهو خطأ صياغة عام، فإذا رأيته بعد نقل تطبيق من سيرفر إلى آخر فابحث أولاً عن صياغة خاصة بالسيرفر القديم، وليس عن خطأ في الكود. ### الانكسار الثالث: ملف النسخ من MySQL لا يدخل MariaDB هذا أهم انكسار في التجربة، لأنه يحدث في يوم النقل نفسه. نصنع جدولاً صغيراً للعملاء في MySQL، ثم نأخذ منه نسخة بالأمر `mysqldump` كما هو، ونستوردها في MariaDB: ```bash docker exec lab-mysqlmaria-mysql mysql -uroot -plab-root-pass shop -e "CREATE TABLE customers (id INT PRIMARY KEY, name VARCHAR(80)); INSERT INTO customers VALUES (1,'سارة'),(2,'Sara'),(3,'Ahmed');" docker exec lab-mysqlmaria-mysql mysqldump -uroot -plab-root-pass shop customers > customers.sql docker exec lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass -e "CREATE DATABASE fromdump" docker exec -i lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass fromdump < customers.sql ``` والمخرج سوف يكون كما يلي: ```text -------------- SET @@GLOBAL.GTID_PURGED=/*!80000 '+'*/ '77796506-c46c-11f1-8231-f68dd65c7de7:1-11' -------------- ERROR 1193 (HY000) at line 24: Unknown system variable 'GTID_PURGED' ``` والسبب أن ال GTID مفعل افتراضياً في MySQL 9.7، فالقيمة الافتراضية لـ `gtid_mode` هي `ON` بحسب [توثيق متغيرات GTID](https://dev.mysql.com/doc/refman/9.7/en/replication-options-gtids.html?ref=arabroot.io)، وتأكدنا من ذلك في السيرفر نفسه: ```text @@gtid_mode @@server_uuid ON 77796506-c46c-11f1-8231-f68dd65c7de7 ``` ولذلك يضع `mysqldump` في أول الملف سطراً يخبر السيرفر الذي يستورد بأرقام المعاملات التي تمت، وهذا المتغير غير موجود في MariaDB لأن صيغة GTID عنده مختلفة. والأخطر هنا أن الاستيراد توقف عند السطر 24، أي بعد أن نفذ ما قبله، فإذا كان الملف فيه عدة قواعد قد تجد بعضها منقولاً وبعضها لا. والحل أن تطلب من `mysqldump` ألا يكتب هذا السطر: ```bash docker exec lab-mysqlmaria-mysql mysqldump --set-gtid-purged=OFF -uroot -plab-root-pass shop customers > customers.sql docker exec -i lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass fromdump < customers.sql docker exec lab-mysqlmaria-mariadb mariadb -uroot -plab-root-pass fromdump -e "SHOW CREATE TABLE customers\G SELECT * FROM customers WHERE name='sara';" ``` والمخرج: ```text Create Table: CREATE TABLE `customers` ( `id` int(11) NOT NULL, `name` varchar(80) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci id name 2 Sara ``` ولاحظ هنا أمرين: الأول أن MariaDB 12.3 قبل الترتيب `utf8mb4_0900_ai_ci` القادم من MySQL، وهذا الترتيب كان سبب فشل كثير من عمليات النقل في الإصدارات الأقدم من MariaDB بالخطأ `Unknown collation`، فإذا كان السيرفر الذي تنقل إليه أقدم فتوقع هذا الخطأ واستبدل الترتيب في الملف. والثاني أن البحث عن `'sara'` أعطى `Sara` على السيرفرين، فالترتيب لا يفرق بين الحروف الكبيرة والصغيرة على الاثنين. ### الانكسار الرابع: عميل MariaDB يرفض الاتصال بـ MySQL نستخدم الآن برنامج العميل `mariadb` من داخل ال Container الثاني للاتصال بسيرفر MySQL، وهذا ما يحدث عندما تستخدم أدوات MariaDB لإدارة سيرفر MySQL أثناء النقل: ```bash docker exec lab-mysqlmaria-mariadb mariadb -h mysql -uroot -plab-root-pass -e "SELECT VERSION(), CURRENT_USER()" ``` والمخرج: ```text ERROR 2026 (HY000): TLS/SSL error: self-signed certificate in certificate chain ``` والسبب أن العميل في MariaDB منذ 11.4 يتحقق من شهادة السيرفر افتراضياً، ومع سيرفر MariaDB ينجح هذا حتى مع شهادة موقعة ذاتياً Self-signed بطريقة تربط بصمة الشهادة بكلمة مرور المستخدم كما تشرح [مدونة MariaDB](https://mariadb.org/mission-impossible-zero-configuration-ssl/?ref=arabroot.io)، ولكن هذه الطريقة خاصة بسيرفر MariaDB، وMySQL ينشئ لنفسه شهادة موقعة ذاتياً عند أول تشغيل، فرفضها العميل. والحل الصحيح في الإنتاج أن تعطي MySQL شهادة من جهة تثق بها وتمرر ملفها للعميل، أما في المختبر فالخيار `--skip-ssl-verify-server-cert` يكفي: ```text VERSION() CURRENT_USER() 9.7.2 root@% ``` ولاحظ أن المستخدم في MySQL يستخدم `caching_sha2_password`، وفي MariaDB `mysql_native_password`، كما يظهر من جدول المستخدمين في كل منهما: ```text MySQL: root caching_sha2_password MariaDB: root mysql_native_password ``` وهذا يعني أن المستخدمين لا ينتقلون مع كلمات مرورهم كما هي، فدليل النقل الرسمي يعيد تعيين كلمات المرور للمستخدمين الذين يستخدمون `caching_sha2_password`، فخطط لإنشاء المستخدمين من جديد في السيرفر الجديد. ### الانكسار الخامس: مجلد البيانات آخر شيء ننظر إليه هو الملفات نفسها على القرص: ```bash docker exec lab-mysqlmaria-mysql ls -la /var/lib/mysql/shop/ docker exec lab-mysqlmaria-mariadb ls -la /var/lib/mysql/shop/ ``` والمخرج من MySQL ثم MariaDB: ```text -rw-r----- 1 mysql mysql 114688 Oct 10 05:43 customers.ibd -rw-r----- 1 mysql mysql 134217728 Oct 10 05:43 orders.ibd -rw-rw---- 1 mysql mysql 70 Oct 10 05:36 db.opt -rw-rw---- 1 mysql mysql 2215 Oct 10 05:38 orders.frm -rw-rw---- 1 mysql mysql 134217728 Oct 10 05:42 orders.ibd ``` MariaDB يحتفظ بتعريف كل جدول في ملف `.frm` بجانب ملف البيانات، أما MySQL فلا يوجد عنده هذا الملف لأن التعريف في قاموس البيانات الداخلي، ولذلك لا تقم بالحل البسيط الذي كان يعمل قديماً، وهو أن توقف MySQL وتشغل MariaDB على نفس ال Volume، والسبب أن MariaDB لن يجد تعريف الجداول، وقد تخسر ال Volume إذا حاول إصلاحه. والطريقة الصحيحة دائماً نسخة منطقية ثم استعادة كما في [قسم النقل](#migration). ### حذف المختبر ```bash docker compose -p lab-mysqlmaria down -v rm orders.csv customers.sql ``` ## النسخ المتماثل Replication والعناقيد شرحنا أشكال العناقيد وفكرة الانتقال Failover بالتفصيل في [مقال عناقيد قواعد البيانات](https://arabroot.io/articles/%D8%B9%D9%86%D8%A7%D9%82%D9%8A%D8%AF-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#engine-mysql)، والمهم هنا هو الفرق بين الاثنين: - **النسخ الأساسي:** الاثنان يرسلان سجل التغييرات Binary Log من السيرفر الرئيسي إلى النسخ، وكلاهما يدعم النسخ بالموقع File and Position والنسخ بال GTID، ولكن صيغة GTID مختلفة كما رأينا، ولذلك لا تستطيع أن تخلط بينهما بال GTID، وإذا احتجت أن يكون MariaDB نسخة من MySQL أثناء النقل فاستخدم النسخ بالموقع كما ينصح [دليل النقل](https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/moving-from-mysql/mysql-to-mariadb-migration-the-master-guide?ref=arabroot.io). - **العنقود بأكثر من سيرفر يكتب:** في MariaDB هو [Galera Cluster](https://mariadb.com/docs/galera-cluster?ref=arabroot.io)، وهو مدمج في الحزمة، وأصبح فريقه داخل MariaDB plc منذ 2025\. وفي MySQL هو [Group Replication](https://dev.mysql.com/doc/refman/9.7/en/group-replication.html?ref=arabroot.io) ومعه InnoDB Cluster وMySQL Router. - **البروكسي:** MySQL Router مفتوح تحت GPL، وMaxScale تحت BSL كما في جدول الرخص، فإذا كان لديك ثلاثة سيرفرات أو أكثر في الإنتاج وتريد MaxScale فاقرأ شروط الرخصة أولاً، أو استخدم بروكسي مفتوحاً مثل ProxySQL أو [تجميع الاتصالات](https://arabroot.io/articles/%D8%AA%D8%AC%D9%85%D9%8A%D8%B9-%D8%A7%D9%84%D8%A7%D8%AA%D8%B5%D8%A7%D9%84%D8%A7%D8%AA-connection-pooling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) من جهة التطبيق. ## متى تختار كل واحد منهما؟ ### MySQL **نقاط القوة:** هو الأصل الذي تختبر عليه أغلب الأدوات والمكتبات والخدمات السحابية المدارة، ونوع JSON فيه حقيقي ويقارن كقيم، وإصدارات LTS تدعم ثماني سنوات، وGroup Replication وInnoDB Cluster وMySQL Router كلها مفتوحة. **نقاط الضعف:** شركة واحدة تملك الكود وتقرر ما يدخل النسخة المجانية، والنسخ الاحتياطي الساخن وThread Pool والتدقيق في النسخة التجارية، واستهلاك الذاكرة الافتراضي أعلى، ونموذج Innovation يغير السلوك بين الإصدارات فلا تستخدمه في الإنتاج إلا إذا كنت تتابع كل إصدار. ### MariaDB **نقاط القوة:** النسخ الاحتياطي الساخن وThread Pool والتدقيق والتشفير كلها في النسخة المجانية، ومؤسسة مستقلة تحرس الكود، وGalera مدمج، وصياغة مفيدة مثل RETURNING وSequences، والحزمة [default-mysql-server](https://packages.debian.org/trixie/default-mysql-server?ref=arabroot.io) في Debian تثبت MariaDB. **نقاط الضعف:** لم يعد بديلاً مباشراً لـ MySQL 8 وما بعده، وJSON نص وليس نوعاً ثنائياً، ودعم LTS المجاني ثلاث سنوات فقط، وبعض المنتجات التجارية والخدمات المدارة تدعم MySQL ولا تذكر MariaDB، وMaxScale ليس مفتوح المصدر. ### دليل القرار - **تطبيق جاهز تستضيفه (WordPress وNextcloud وBookStack وغيرها):** استخدم ما يذكره التطبيق في توثيقه أولاً، وإذا ذكر الاثنين فاختر الذي تعرف إدارته، فالفرق لن يظهر في هذه التطبيقات. - **تطبيق تكتبه أنت ويعتمد على JSON كثيراً:** MySQL أنسب، أو فكر في PostgreSQL كما في [مقال PostgreSQL لكل شيء](https://arabroot.io/articles/postgresql-%D9%84%D9%83%D9%84-%D8%B4%D9%8A%D8%A1-%D9%85%D8%AA%D9%89-%D8%AA%D9%83%D9%81%D9%8A%D9%83-%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D8%A7%D8%AD%D8%AF%D8%A9/). - **تريد كل الأدوات مجاناً دون نسخة تجارية:** MariaDB أنسب. - **تريد عنقوداً يكتب على أكثر من سيرفر:** Galera في MariaDB أبسط في البداية، ولكن اقرأ [قسم Multi-Primary](https://arabroot.io/articles/%D8%B9%D9%86%D8%A7%D9%82%D9%8A%D8%AF-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#multi-primary) قبل أن تقرر أنك تحتاجه أصلاً. - **ستستخدم خدمة مدارة لاحقاً:** تأكد أن الخدمة تقدم القاعدة التي تختارها اليوم بنفس الإصدار، حتى لا تحتاج نقلاً بين الاثنين في المستقبل. - **لديك تطبيق قائم يعمل:** لا تنقله من واحدة إلى الأخرى لأن مقالاً قال إن الأخرى أفضل، فالنقل كما رأينا له ثمن، وانقل فقط عندما تحتاج ميزة أو رخصة لا توجد في الحالية. وللمقارنة مع PostgreSQL وMongoDB على نفس البيانات راجع مقال [PostgreSQL أم MySQL أم MongoDB؟](https://arabroot.io/articles/postgresql-%D8%A7%D9%85-mysql-%D8%A7%D9%85-mongodb/). ## النقل من MySQL إلى MariaDB دون مفاجآت إذا قررت النقل، فهذه الخطوات بالترتيب، وكل خطوة جاءت من شيء انكسر في التجربة أو من [دليل النقل الرسمي](https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/migrating-to-mariadb/moving-from-mysql/mysql-to-mariadb-migration-the-master-guide?ref=arabroot.io): 1. ابحث في كود التطبيق عن المعامل `->` و`->>` وعن أي دالة خاصة بـ MySQL، واستبدلها بـ `JSON_VALUE` و`JSON_EXTRACT`. 2. شغل اختبارات التطبيق على MariaDB في بيئة منفصلة قبل أي شيء، فهي أسرع طريقة لتجد أخطاء 1064. 3. خذ النسخة بالخيارات `--single-transaction --routines --events --triggers --hex-blob --set-gtid-purged=OFF`، ولاحظ أن الخيار الأخير ليس في الدليل الرسمي ولكنه هو الذي حل خطأ 1193 في التجربة. 4. لا تنقل قاعدة `mysql` نفسها (المستخدمين والصلاحيات)، وأنشئ المستخدمين من جديد في MariaDB. 5. إذا كان السيرفر الجديد أقدم من 11.4 فابحث في الملف عن `utf8mb4_0900_ai_ci` واستبدله بترتيب موجود عنده. 6. استورد، ثم قارن عدد الصفوف في كل جدول وبعض المجاميع بين السيرفرين قبل أن توجه التطبيق إلى الجديد. 7. احتفظ بالنسخة القديمة واختبر الاستعادة منها كما في [مقال النسخ الاحتياطي 3-2-1](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/)، فهي طريق الرجوع إذا ظهرت مشكلة بعد أيام. والنقل في الاتجاه المعاكس من MariaDB إلى MySQL يمر بنفس الطريق مع مشاكل معكوسة: RETURNING وSequences وأي صياغة خاصة بـ MariaDB سوف تعطي 1064 على MySQL. ## أخطاء شائعة - **تشغيل MariaDB على مجلد بيانات MySQL 8:** لا يعمل، والنقل يكون بنسخة منطقية فقط. - **استيراد نسخة `mysqldump` دون `--set-gtid-purged=OFF`:** يتوقف الاستيراد في المنتصف بالخطأ 1193 بعد أن نفذ جزءاً منه. - **الاعتماد على `->>` في تطبيق يقول إنه يدعم الاثنين:** يعمل في بيئتك على MySQL ويفشل عند أول عميل يستخدم MariaDB. - **اختيار إصدار Innovation من MySQL للإنتاج:** يدعم حتى الإصدار التالي فقط وقد يغير السلوك، فاستخدم LTS. - **نسيان أن دعم MariaDB LTS المجاني ثلاث سنوات:** خطط للترقية مبكراً، أو قم بشراء الدعم الممتد. - **تعطيل التحقق من الشهادة في الإنتاج لأن العميل رفض الاتصال:** أصلح الشهادة بدل أن تطفئ التحقق. ## الخلاصة - MariaDB خرج من MySQL في 2009 بعد أن اشترت Oracle شركة Sun، واليوم MySQL تملكها Oracle، وMariaDB تملكها K1 مع مؤسسة مستقلة تحرس الكود. - السيرفر في الاثنين تحت GPLv2، والفرق في الأدوات حوله: النسخ الساخن وThread Pool والتدقيق مجانية في MariaDB وتجارية في MySQL، وMaxScale تحت BSL. - نفس البروتوكول ونفس InnoDB وأغلب SQL، ولكن في التجربة انكسر `->>` على MariaDB، وRETURNING على MySQL، وملف النسخ من MySQL توقف في MariaDB بسبب GTID\_PURGED، والعميل رفض الشهادة الموقعة ذاتياً، ومجلد البيانات لا يشارك. - الأداء على مليون طلب متقارب في الاستعلامات، والفرق ليس سبباً كافياً للاختيار. - اختر ما يذكره تطبيقك، ولا تنقل تطبيقاً قائماً إلا لميزة أو رخصة تحتاجها، وإذا نقلت فبنسخة منطقية واختبار كامل. [![](https://arabroot.io/content/images/2026/10/db-types-cover-cover.webp)دليلأنواع قواعد البيانات ومتى تختار كل نوعالفرق بين قواعد البيانات العلائقية والمستندات والمفتاح والقيمة وغيرها، وأي الأسئلة تجيب عنها كل عائلة بسهولة.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%88%D9%85%D8%AA%D9%89-%D8%AA%D8%AE%D8%AA%D8%A7%D8%B1-%D9%83%D9%84-%D9%86%D9%88%D8%B9/)[![](https://arabroot.io/content/images/2026/10/db-clustering-cover-cover.webp)دليلعناقيد قواعد البيانات Database Clustering ومتى تحتاجهاماذا تعني كلمة Cluster في كل قاعدة بيانات، ومتى تحتاج نسخاً أو انتقالاً تلقائياً، ومتى يكفيك سيرفر واحد مع نسخ احتياطية جيدة.](https://arabroot.io/articles/%D8%B9%D9%86%D8%A7%D9%82%D9%8A%D8%AF-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/postgres-mysql-mongodb-cover-cover.webp)دليلPostgreSQL أم MySQL أم MongoDB؟مقارنة عادلة بين أشهر ثلاث قواعد بيانات على نفس البيانات، وأسئلة بسيطة تساعدك على اختيار ما يناسب مشروعك.](https://arabroot.io/articles/postgresql-%D8%A7%D9%85-mysql-%D8%A7%D9%85-mongodb/)[![](https://arabroot.io/content/images/2026/10/db-admin-ui-cover-cover.webp)دليلواجهات إدارة قواعد البيانات: pgAdmin وAdminer وCloudBeaverكيف تختار واجهة ويب لإدارة قاعدة بياناتك وتشغلها، ولماذا يجب ألا تصل إليها من الإنترنت إلا عبر باب واحد محمي.](https://arabroot.io/articles/%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA-%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-pgadmin-%D9%88-adminer-%D9%88-cloudbeaver/)[![](https://arabroot.io/content/images/2026/10/backup-321-cover-cover.webp)دليلالنسخ الاحتياطي بقاعدة 3-2-1 واختبار الاستعادةكيف تحدد كم بيانات تقبل أن تخسر، وتبني نسخاً لا يستطيع المخترق حذفها، وتتأكد أنك تستطيع استعادتها فعلاً.](https://arabroot.io/articles/%D8%A7%D9%84%D9%86%D8%B3%D8%AE-%D8%A7%D9%84%D8%A7%D8%AD%D8%AA%D9%8A%D8%A7%D8%B7%D9%8A-%D8%A8%D9%82%D8%A7%D8%B9%D8%AF%D8%A9-3-2-1-%D9%88%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%B3%D8%AA%D8%B9%D8%A7%D8%AF%D8%A9/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، والتجربة على MySQL 9.7.2 وMariaDB 12.3.3 في Docker Engine 29.8.0، والمعلومات من توثيق MySQL وMariaDB وبيانات MariaDB plc ومؤسسة MariaDB كما قرأناها في 10 و11 أكتوبر 2026.