البحث في الموقع

MySQL replication هي العمليّة التي يمكن من خلالها نسخ البيانات أوتوماتيكيًا من أحد مخدّمات قاعدة بيانات MySQL “الرئيسي” (master) إلى واحد أو أكثر من مخدّمات قواعد بيانات MySQL “التابع” (slaves). وعادةً ما تستخدم لتوزيع إمكانيّة وصول القراءة read access على مخدّمات متعددة من أجل قابلية التوسع scalability، كما يمكن أن تستخدم أيضًا لأغراض أخرى مثل تجاوز الفشل failover، أو تحليل البيانات على الـ slave من أجل عدم زيادة التحميل على الـ master. كما أنّ الـ master-slave replication هي عمليّة باتجاه واحد (من الـ master إلى slave)، تستخدم قاعدة بيانات الـ master فقط لعمليات الكتابة. بينما يمكن أن توزّع عمليات القراءة على عدّة قواعد بيانات slave. ما الذي يعنيه إذا استخدم master-slave replication كحل للتوسع، ستحتاج لأن تملك على الأقل مصدرين محدّدين للبيانات، واحد لعمليات الكتابة وآخر لعمليات القراءة. يعمل مطوّرو MySQL عادةً على جهاز واحد فقط و ويسعون لأن يكون لديهم كامل بيئة التطوير على ذلك الجهاز. مع منطق عدم الاعتماد على شبكة أو اتصال بالإنترنت. إذا كان هناك حاجة لـ master-slave replication فلأنه على سبيل المثال، يحتاجون إلى اختبار النسخ المتماثل/التكرار replication في بيئة التطوير قبل نشر التغييرات في مكان آخر، عليهم إنشاؤئه على نفس الجهاز. إن الإعداد لمثال MySQL واحد (single MySQL instance) بسيط نوعًا ما، ونحتاج لبذل بعض الجهد الإضافي لإعداد المثال الثاني، وبعدها عملية التكرار master-slave replication. للمتابعة في هذه الدرس خطوة بخطوة، اخترت Ubuntu Linux كنظام تشغيل مضيف (host). والأوامر الواردة هي من أجل هذا النظام. إذا أردت إعداد الـ MySQL master-slave replication الخاص بك على نظام تشغيل مختلف، ستكون بحاجة إلى القيام بتعديلات على هذه الأوامر. ومع ذلك ، المبادئ العامة لإعداد الـ MySQL master-slave replication على نفس الجهاز هي نفسها بالنسبة لجميع أنظمة التشغيل. تثبيت أول مثالMySQL (MySQL instance) إذا كان لديك مسبقًا مثال قاعدة بيانات MySQL واحد على جهازك، فيمكنك تجاوز هذه الخطوة. هذه أسهل طريقة لتثبيت MySQL على نظام Ubuntu وهي بتشغيل الأوامر التالية في موجّه الطرفية (terminal prompt): sudo apt-get install mysql-server خلال عملية التثبيت، ستُقاطع لوضع كلمة مرور لمستخدم root لـ MySQL. إعداد mysqld_multi من أجل إدارة مثالية لـ MuSQL على نفس الجهاز بكفاءة، نحن بحاجة إلى استخدام mysqld_multi. الخطوة الأولى في إعداد mysqld_multi هي إنشاء مجموعتي [mysqld] منفصلتين في الملف الموجود my.cnf. المكان الافتراضي لملف my.cnf في Ubuntu هو /etc/mysql/. لذلك افتح ملف my.cnf بمحرّر نصوصك المفضّل، وسمِّ مجموعة [mysqld] الموجودة إلى [mysqld1]. هذه المجموعة المسمّاة تستخدم لتكوين أول مثال MySQL وستكوّن أيضا كمثال رئيسي. كما هو الحال في MySQL master-slave replication كل مثال يجب أن يكون له server-id فريد خاص به، أضف السطر التالي في مجموعة [mysqld1]: server-id = 1 نظرًا لأننا بحاجة إلى مجموعة [mysqld]منفصلة لمثال MySQL الثاني ، انسخ المجموعة [mysqld1] مع كافة التهيئات الحالية، والصقها في ملف my.cnf نفسه. الآن، أعد تسمية المجموعة المنسوخة إلى [mysqld2]، وقم بإجراء التغييرات التالية في تكوين الـ slave: server-id = 2 port = 3307 socket = /var/run/mysqld/mysqld_slave.sock pid-file = /var/run/mysqld/mysqld_slave.pid datadir = /var/lib/mysql_slave log_error = /var/log/mysql_slave/error_slave.log relay-log = /var/log/mysql_slave/relay-bin relay-log-index = /var/log/mysql_slave/relay-bin.index master-info-file = /var/log/mysql_slave/master.info relay-log-info-file = /var/log/mysql_slave/relay-log.info read_only = 1 لإعداد مثيل MySQL الثاني كـتابع slave ، اضبط server-id إلى 2، والتي يجب أن تكون مختلفة بالنسبة لـ master’s server-id. كلا المثالين سيُشغّلان على نفس الجهاز، اضبط منفذ المثال الثاني إلى قيمة 3307 بحيث يمتلك رقم مختلف عن المنفذ الخاص بالمثال الأول، والذي يكون افتراضيًا 3306. من أجل تفعيل هذا المثال الثاني ليستخدم نفس MySQL binaries، نحتاج لضبط قيم مختلفة للـ socket، pid-file، datadir و log_error. نحن أيضًا بحاجة لتفعيل relay-log من أجل استخدام المثال الثاني كتابع (slave) (المتغيرات relay-log، relay-log-index و relay-log-info-file)، فضلًا عن تعيين master-info-file. أخيرًا، من أجل جعل المثال التابع للقراءة فقط read-only، ضبط المتغير read_only بقيمة 1. يجب أن تكون حذرًا معه فهو لا يمنع التغيرات بشكل كامل على الـ slave. حتى عندما تضبط read_only إلى 1، سيسمح للتحديثات فقط من المستخدمين الذين يملكون امتياز SUPER. أدخل MySQL المتغير الجديد super_read_only لمنع إجراء تغييرات من قبل مستخدمين الـ SUPER. هذا الخيار متوفر مع الإصدار 5.7.8. بعيدًا عن مجموعات الـ [mysqld1] و [mysqld2]، نحن بحاجة إلى إضافة مجموعة جديدة [mysqld_multi] إلى ملف my.cnf. [mysqld_multi] mysqld = /usr/bin/mysqld_safe mysqladmin = /usr/bin/mysqladmin user = multi_admin password = multipass بمجرد تثبيتنا لمثال MySQL الثاني، والقيام بتشغيلهما، سنمنح الامتيازات المناسبة للمستخدم multi_admin ليكون قادرًا على إيقاف تشغيل أمثلة MySQL. أنشئ مجلدات جديدة من أجل مثال MySQL الثاني في الخطوة السابقة قمنا بإعداد ملف التكوين من أجل مثال MySQL الثاني. في ملف التكوين هذا يتم استخدام مجلدين جديدين. يجب استخدام أوامر لينكس التالية من أجل إنشاء هذه المجلدات مع الامتيازات المناسبة: mkdir -p /var/lib/mysql_slave chmod --reference /var/lib/mysql /var/lib/mysql_slave chown --reference /var/lib/mysql /var/lib/mysql_slave mkdir -p /var/log/mysql_slave chmod --reference /var/log/mysql /var/log/mysql_slave chown --reference /var/log/mysql /var/log/mysql_slave إعدادات أمنية إضافية في AppArmor في بعض بيئات لينكس، هناك حاجة إلى إعدادات أمن AppArmor لتشغيل مثال MySQL الثاني. على الأقل هي مطلوبة في Ubuntu . لإعداد AppArmor بشكل صحيح. حرّر ملف /etc/apparmor.d/usr.sbin.mysqld بمحرّر نصوصك المفضّل، وأضف الأسطر التالية: /var/lib/mysql_slave/ r، /var/lib/mysql_slave/** rwk، /var/log/mysql_slave/ r، /var/log/mysql_slave/* rw، /var/run/mysqld/mysqld_slave.pid rw، /var/run/mysqld/mysqld_slave.sock w، /run/mysqld/mysqld_slave.pid rw، /run/mysqld/mysqld_slave.sock w، بعد أن تحفظ الملف، أعد تشغيل الجهاز حتى تصبح هذه التغييرات نافذة المفعول. تثبيت مثال MySQL الثاني يمكن اتباع عدّة نُهج مختلفة لتركيب مثال MySQL الثاني. يستخدم النهج المعروض في هذه الدورة التعليميّة نفس ثنائيات الـ MySQL كما في الأول، مع ملفات بيانات منفصلة ضرورية للتثبيت الثاني. حيث أننا قمنا بالفعل بإعداد ملف التكوين والمجلدات الضرورية والتغييرات الأمنية في الخطوات السابقة، الخطوة الأخيرة في التثبيت للمثال الثاني لـ MySQL هي تهيئة دليل بيانات MySQL. نفذ الأمر التالي من أجل تهيئة دليل بيانات MySQL جديد: mysql_install_db --user=mysql --datadir=/var/lib/mysql_slave بمجرد تهيئة دليل بيانات MySQL، يمكنك بدء كل من مثالي MySQL باستخدام الخدمة mysqld_multi. mysqld_multi start ضع كلمة سر الـ root لمثال MySQL الثاني باستخدام الـ mysqladmin مع المضيف والمنفذ المناسبين. وضع في اعتبارك ، أنه إذا تَركت المنفذ والمضيف دون تحديد، سيتصل mysqladmin بأول مثال MySQL افتراضيًا. mysqladmin --host=127.0.0.1 --port=3307 -u root password rootpwd في المثال الذي في الأعلى قم بوضع “rootpwd” ككلمة سر، ولكن يستحسن استخدام كلمة سر أكثر أمنًا. تهيئة إضافية لـ mysqld_multi في نهاية قسم " إعداد mysqld_multi، كتبت أننا سنقدم امتيازات مناسبة للمستخدم multi_admin في وقت لاحق، والآن حان الوقت لذلك. نحن بحاجة إلى منح امتيازات هذا المستخدم في كلا المثالين، لذلك دعونا أولًا نقوم بالاتصال بالمثال الأول: mysql --host=127.0.0.1 --port=3306 -uroot -p عند تسجيلك الدخول، نفّذ الأمرين التاليين: mysql> GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass'; mysql> FLUSH PRIVILEGES; اخرج من MySQL client، وقم بالاتصال بالمثال الثاني: mysql --host=127.0.0.1 --port=3307 -uroot -p عند تسجيلك الدخول، نفّذ نفس الأمرين كما في الأعلى: mysql> GRANT SHUTDOWN ON *.* TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass'; mysql> FLUSH PRIVILEGES; اخرج من MySQL client. بدء كل من مثالي MySQL أوتوماتيكيًا عند الإقلاع الخطوة الأخيرة في إعداد mysqld_multi هي التثبيت لسكريبت الإقلاع الأتوماتيكي في الـ init.d. لفعل ذلك، أنشئ ملف جديد سمّه mysqld_multi في /etc/init.d، وامنحه الامتيازات المناسبة: cd /etc/init.d touch mysqld_multi chmod +x /etc/init.d/mysqld_multi افتح هذا الملف الجديد بمحرّر نصوصك المفضل، وانسخ السكريبت التالي: #!/bin/sh ### BEGIN INIT INFO # Provides: scriptname # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start daemon at boot time # Description: Enable service provided by daemon. ### END INIT INFO bindir=/usr/bin if test -x $bindir/mysqld_multi then mysqld_multi="$bindir/mysqld_multi"; else echo "Can't execute $bindir/mysqld_multi"; exit; fi case "$1" in 'start' ) "$mysqld_multi" start $2 ;; 'stop' ) "$mysqld_multi" stop $2 ;; 'report' ) "$mysqld_multi" report $2 ;; 'restart' ) "$mysqld_multi" stop $2 "$mysqld_multi" start $2 ;; *) echo "Usage: $0 {start|stop|report|restart}" >&2 ;; esac أضف خدمة mysqld_multi لـ runlevels الافتراضي بالأمر التالي: update-rc.d mysqld_multi defaults أعد تشغيل جهازك، وتحقق من أن كلا مثالي MySQL قيد التشغيل باستخدام الأمر التالي: mysqld_multi report إعداد Setup master-slave replication الآن، عندما يكون لدينا مثالي MySQL قيد التشغيل على نفس الجهاز، نقوم بإعداد المثال الأول كـ master، والثاني كـ slave. تم القيام بجزء واحد من التكوين configuration مسبقا في فصل “إعداد mysqld_multi”. التغيير الوحيد المتبقي في الملف my.cnf هو ضبط binary logging على الـ master. لفعل ذلك، حرّر ملف my.cnf مع التغيرات التالية والإضافات في المجموعة [mysqld1]: log_bin = /var/log/mysql/mysql-bin.log innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 binlog-format = ROW أعد تشغيل مثال MySQL الرئيسي (master MySQL instance) لتأخذ التغيرات مفعولها: mysqld_multi stop 1 mysqld_multi start 1 من أجل اتصال الـ slave بالـ master بامتيازات تكرار replication مناسبة، يجب أن ينشأ المستخدم الجديد في الـ Master. اتصل بمثال maste باستخدام الـ MySQL clien مع المضيف والمنفذ المناسبين: mysql -uroot -p --host=127.0.0.1 --port=3306 أنشئ مستخدم جديد من أجل التكرار replication: mysql> CREATE USER 'replication'@'%' IDENTIFIED BY 'replication'; mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'; اخرج من MySQL client. نفّذ الأمر التالي من أجل إنشاء ملف نسخ احتياطي (dump) لبيانات الـ master: mysqldump -uroot -p --host=127.0.0.1 --port=3306 --all-databases --master-data=2 > replicationdump.sql هنا استخدمنا الخيار --master-data=2 من أجل الحصول على تعليق يحتوي على عبارة CHANGE MASTER داخل ملف النسخ الاحتياطي، ذاك التعليق يشير الى إحداثيات الـ replication في وقت النسخ الاحتياطي، وسنحتاج هذه الإحداثيات لاحقًا لتحديث معلومات الـ master في مثال الـ slave. وهنا مثال لهذا التعليق: -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001'، MASTER_LOG_POS=349; استورد dump الذي أنشأته في الخطوة السابقة ضمن مثال الـ slave. mysql -uroot -p --host=127.0.0.1 --port=3307 < replicationdump.sql أخيرًا، من أجل اتصال مثال الـ slave بمثال الـ master، يجب تحديث معلومات الـ master في الـ slave مع متغيرات الاتصال المناسبة. اتصل بمثال الـ slave باستخدام MySQL clien مع المضيف والمنفذ المناسبين: mysql -uroot -p --host=127.0.0.1 --port=3307 نفّذ الأمر التالي لتحديث معلومات الـ master (خُذ احداثيات التكرار replication من ملف (dump) replicationdump.sql، كما شُرح سابقًا): mysql> CHANGE MASTER TO -> MASTER_HOST='127.0.0.1'، -> MASTER_USER='replication'، -> MASTER_PASSWORD='replication'، -> MASTER_LOG_FILE='mysql-bin.000001'، -> MASTER_LOG_POS=349; نفذ الأمر التالي من أجل تشغيل الـ slave: mysql> START SLAVE; نفذ الأمر التالي للتأكد من أن replication قيد التشغيل: mysql> SHOW SLAVE STATUS \G تهانينا. تم إعداد MySQL master-slave replication على نفس الجهاز لديك بنجاح. خاتمة وجود النسخ المتماثل master-slave مهيئًا في بيئة التطوير الخاصة بك مفيد إذا كنت بحاجة لحل للتوسع في بيئة الإنتاج. بهذه الطريقة، سيكون لديك مصادر بيانات منفصلة مُهيئة لعمليات الكتابة والقراءة وبذلك تكون قادرًا على اختبار أن كل شيء يعمل محلياً كما هو متوقع قبل النشر. بالإضافة إلى ذلك، قد تحتاج إلى تكوينات أمثلة slave على نفس الجهاز لاختبار موازن الحمل الذي يوزّع عمليات القراءة إلى عدد من الـ slave. في هذه الحالة، يمكنك استخدام هذه الطريقة لإعداد أمثلة أخرى بتكرار كل الخطوات السابقة نفسها. ترجمة -وبتصرّف- للمقال MySQL Master-Slave Replication on the Same Machine لصاحبه Ivan Bojovic

سنشرح اليوم فكرة التوفّر أو تكرار البيانات (redundancy). البيانات المُكررة ليست نسخةً احتياطية، بل هي بيانات يمكن أن تساعدك على تجاوز عمليات فشل الأقراص (disks fail) في حال ما إذا تعذّر عليك الوصول إلى بيانات الأقراص الصلبة عبر الطريقة الأساسية التي تستعملها. تعتمد طريقة تشغيل النسخ المتماثل (replication) على نظامك على كيفية استعمالك لبياناتك، الأخطاء التي تريد تجنّبها وكيفيّة تفاعل زوّارك مع خادومك. الوفرة العالية عبر RAIDربّما يكون أشهر أنواع النسخ المتماثل (replication) هو تقنية RAID. ترمز RAID إلى "مصفوفة تكرار الأقراص المستقلة - Redundant Array of Independent Disks". يعني هذا أنّه وفي غالب الأحيان، تعمل الأقراص كمرايا (mirrors) لبعضها البعض. التطبيق الأكثر شيوعًا لتقنية RAID هو مصفوفة RAID 1. يقوم هذا النوع من المصفوفات بتمرير (mirror) قرصٍ صلب ما على قرصٍ صلبٍ آخر. يعني أنّه وفي حال فشل القرص الصلب الأوّل، فسيبقى القرص الصلب الثاني موجودًا للخدمة وكتابة البيانات. يسرّع هذا النوع من المصفوفات عملية القراءة من الأقراص بسبب توفّر البيانات في أكثر من مكان وبالتالي يستطيع النظام قراءتها من أيّ موقعٍ يريد من الموقعين المتوفّرين. هذا المثال أيضًا هو مثالٌ جيّد لتوضيح السبب الذي من أجله تكون تقنية مثل RAID، أو عملية تكرار البيانات (redundancy) عمومًا مختلفة عن عملية النسخ الاحتياطي (backup). إذا قمتَ بحذف ملفّ ما فقد تمّ حذفه بالفعل ولن تتمكن من استرجاعه. يتم تطبيق التغييرات على جميع الأقراص مباشرةً بالوقت نفسه لضمان المزامنة بينها. يتم تطبيق تقنية RAID في المستوى المنخفض (low-level)، هذا يعني أنّك لن تستطيع التحكّم بتقنية RAID وخصائصها أو تضمينها على خادومك الافتراضي الخاصّ على شركة DigitalOcean مثلا، إن كان خادومك على مزود آخر، فراجع دليل المساعدة الخاص بالمزود. تكرار البيانات على مستوى الكتل Block-Levelمن الطرق الأخرى للقيام بعملية تكرار البيانات (Redundancy) هي عبر تمرير هيكلة الكُتَل (Blocks) بالكامل. DRBD أو "جهاز الكُتَل المكررة الموزّع - Distributed Replicated Block Device"، هو عبارة عن طريقة يمكن تطبيقها للقيام بعملية تكرار البيانات على امتداد أجهزة الكُتَل (Block Devices). قد يبدو هذا مشابهًا لمصفوفة RAID التي تستعمل المرايا، وفي بعض الأحيان، هي كذلك بالفعل. لكنّ الفرق هو في المكان الذي تتم فيه عملية النسخ المتماثل. في RAID، تتم عمليّة تكرار البيانات على مستوى أقل من مستوى تطبيقات النظام. تدير بطاقة RAID أو برمجيّة RAID الأقراص الصلبة الفيزيائية بنفسها وتقوم في النهاية بتقديم قرصٍ واحد ليتم قراءة البيانات منه. DRBD على الجانب الآخر، مُعدّة بطريقة مختلفة تماًمًا. في DRBD، يتم تمرير محتويات كلّ خادوم بالكامل إلى خادومٍ آخر. يتم تمرير واجهة التطبيقات كذلك. هذا يعني أنّه يمكن التعامل مع فشل التطبيقات بسهولة بسبب وجود آلة أخرى منفصلة تمامًا عن الخادوم الرئيسي تحوي على نفس محتويات الخادوم الرئيسي. إذا فشل خادومك الأوّل مثلًا بسبب مشاكل بالطاقة، فسيتم تشغيل خادومك الثاني ليقوم بنفس المهام. النسخ المتماثل في SQLإذا كانت بياناتك المهمّة مخزّنة في قاعدة بيانات SQL (مثل MySQL ،MariaDB ،PostgreSQL، ..)، فيمكنك الاستفادة من بعض مزايا النسخ التكراري أو النسخ المتماثل المضمّنة بالفعل. يمكن لهذه المزايا أن توفّر لك نظام استرجاع في حال تعطّل نظامك الرئيسي. النسخ المتماثل بـ Master-Slaveالنوع الأساسي للنسخ التكراري أو المتماثل (replication) الخاصّ بـSQL هو إعداد Master-Slave. في هذا السيناريو، تمتلك خادوم قاعدة بيانات رئيسي، والذي يتم الإشارة إليه باسم السيّد أو "Master". هذا الخادوم هو المسؤول عن تنفيذ جميع مهام الكتابة والتحديثات. يتم نسخ البيانات من هذا الخادوم بشكلٍ مستمر إلى الخادوم الفرعي أو "slave". يمكن أيضًا القراءة من هذا الخادوم، ولكن لا يمكن الكتابة عليه. يسمح لك هذا التثبيت بتوزيع البيانات على امتداد أجهزة متعددة، والذي يمكنه تحسين أداء تطبيقك بشكل ملحوظ. في حين أنّ تحسين الأداء هذا يعتبر ميّزة مهمّة، واحدٌ من الأسباب الرئيسية التي قد تودّ من أجلها إعداد نسخٍ تكراري باستخدام Master-Slave هو لمعالجة الأعطاب ومشاكل الفشل. إذا أصبح خادومك الرئيسي غير متوفّر، فيمكنك القراءة من خادومك الفرعي. أيضًا من الممكن أن تقوم بتحويل الخادوم الفرعي إلى خادوم رئيسي في حال ما إذا كان خادومك الرئيسي معطّلًا لفترة معيّنة من الوقت. نسخ Master-Slave المتماثل في الواقع هو مكان من الأماكن التي يمكننا أن نلاحظ فيها تكامل عمليتيّ النسخ الاحتياطي والنسخ المتماثل. في إعداد master-slave، يمكنك نسخ البيانات بشكلٍ متماثل من الخادوم السيّد أو الرئيسي إلى الخادوم الفرعي. يمكنك بعدها تعطيل النسخ المتماثل بشكلٍ مؤقّت لمعرفة حالة المعلومات وصيانتها على الخادوم الفرعي. من هنا، يمكنك عمل نسخة احتياطية من قاعدة البيانات باستخدام أيّ أداة نسخ احتياطي تريدها. يمكنك قراءة المزيد عن: إعداد النسخ المتماثل بـMaster-Slave لـMySQL أو إعداد النسخ المتماثل بـMaster-Slave لـPostgreSQL. النسخ المتماثل بـMaster-Masterالنوع الثاني من النسخ المتماثل يدعى "Master-Master" أو من خادومٍ رئيسي إلى خادومٍ رئيسي آخر. يسمح هذا الإعداد لكلا الخادومين بامتلاك الميّزات "الرئيسية". يعني هذا أنّه يمكن لكلا الخادومين أن يقبلا الكتابة والتحديثات ونقل التغييرات إلى الخادوم الآخر. يرث هذا الإعداد مزايا إعداد master-slave، ولكنّه يستفيد أيضًا من التحسّن بأداء الكتابة على الأقراص إذا كانت طريقة الكتابة موزّعة بشكلٍ جيّدة عبر آلية موازنة حملٍ جيّدة. هذا يعني أيضًا أنّه في حال تعطّل خادومٍ ما، سيبقى الآخر عامِلًا وقادرًا على استقبال الطلبات وخدمة الزوّار. صحيحٌ أنّ عملية الإعداد ستكون أكثر تعقيدًا هنا، ولكنّ عملية الاسترجاع في هذه الحالة هي أقل تعقيدًا من حالة الاسترجاع من الفشل في إعداد master-slave، لأنّه لا حاجة إلى نقل قاعدة البيانات من الخادوم الفرعي إلى الخادوم الرئيسي. يمكن أيضًا دمج هذا الإعداد مع آلية نسخٍ احتياطي إذا قمت بتعطيل واحدٍ من الخواديم الرئيسية. يجب أن تقوم بإعداد قاعدة بيانات ثابتة للنسخ الاحتياطي لتعمل بشكلٍ صحيح، لذا يجب عليك أن تتأكّد من أنّه لا يتم كتابة أو تعديل أيّ بيانات إلى حين انتهاء عملية النسخ الاحتياطي. يمكنك قراءة المزيد عن: النسح المتماثل كـmaster-master. التوزيع كبديل للنسخ لتكرار البياناتتعرض الأنظمة الموزّعة العديد من المزايا مقارنةً بتضبيطات تكرار البيانات التقليدية. شرحنا مراحل RAID الممررة عبر المرايا أعلاه (RAID 1). هناك مرحلة أخرى شائعة الاستخدام في RAID وهي RAID 5. تقوم هذه المرحلة بتوزيع البيانات على امتداد عددٍ من الأجهزة وتقوم أيضًا بكتابة بياناتٍ مساوية على امتداد كلّ جهاز. يعني هذا أنّه يمكن إعادة بناء أيّ نوع من الإجراءات (Transactions) عبر جمع المعلومات الموزّعة بشكلٍ متساوٍ من الأجهزة الأخرى في حال تعطّل جهازٍ ما. يوفّر هذا طريقةً مختلفة لتوزيع البيانات عبر مختلف الأقراص، ويمكنه معالجة فشل واحدٍ من الأقراص كذلك. لا يجب أن تتم الأنظمة الموزّعة على صعيد العتاد (hardware) فقط. هناك أيضًا عدّة قواعد بيانات وحلول برمجية أخرى مصممة للتعامل مع البيانات الموزّعة كميّزة أساسية لها. من الأمثلة على هذا هو Riak، Riak هو عبارة عن قاعدة بيانات موزّعة. عُقَد Riak متطابقة جميعًا. لا يوجد أيّ علاقة master-slave بين الأجزاء المختلفة. تتم عملية النسخ المتماثل على الكائنات المخزّنة في قاعدة البيانات تلقائيًا، لذا فهناك عملية نسخ متماثل تلقيدية في هذا الجانب. على كلّ حال، لا تقوم كلّ عقدة بتخزين قاعدة البيانات بأكملها داخلها، بل يتم توزيع البيانات على جميع العقد بطريقة مشابهة. يتم وضع الكائنات التي تمّ نسخها بشكلٍ متماثل على عقدٍ مختلفة للسماح بالتوفّر العالي في حال حصول أعطاب على مستوى العتاد. مثالٌ آخر قائم على هذا المبدأ المُضمّن في قاعدة بيانات هو Cassandra. وهو مبني على نفس المبادئ الموجود في Riak، ولكنّها مضمّنة بطريقة مختلفة. خاتمةكما يمكنك أن ترى، هناك العديد من الخيارات المتوفّرة للنسخ المتماثل أو النسخ التكراري، كلّ واحدٍ منه يمتلك إيجابياتٍ وسلبيات. يعتمد الأمر بشكلٍ أساسي على المشاكل التي تحاول تجنّبها وماهيّة أجزاء النظام التي لا تريد أن تكون خارج الخدمة بتاتًا. خليطٌ من هذه التقنيات سيكون دومًا خيارًا أأمن وأكثر شمولية. يجب أيضًا أن تكون قادرًا على أن ترى الآن أن إعداد النسخ المتماثل ليس بديلًا عن النسخ الاحتياطي. للتطبيقات التي يكون فيها توافق البيانات والوصول أمرًا أساسيًا، سيكون النسخ الاحتياطي والنسخ المتماثل تقنيتين لا تقدرّان بثمن. تضمينٌ صحيح لهاتين التقنيتين سيضمن لك أنّ منتجك سيكون دومًا متوفرًا للمستخدمين وأنّ البيانات لن تضيع منك. ترجمة -وبتصرف- للمقال: How To Choose a Redundancy Plan To Ensure High Availability لصاحبه: Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.