نسخة إحتياطية حية من قاعدة البيانات MySQL/MariaDB Replication

rasor_SQL_Backup
في اﻷيام الماضية كُنت أبحث عن طريقة لعمل نُسخة إحتياطية من قاعدة البيانات، وكانت الشروط هي:

  1. أن تكون في مخدم آخر
  2. أن تكون طريقة النسخ من قاعدة البيانات الرئيسة هي حسب التغييرات differential
  3. في حالة تعطل جهاز قاعدة البيانات الرئيس يُمكن إستخدام الجهاز اﻹحتياطي مباشرة، أي تكون النسخة اﻹحتياطية نسخة حية Live
  4. أن تكون الطريقة سهلة التنفيذ

وبعد بحث عن الـ replication والـ mirroring في محركات قواعد البينات MySQL, PostGreSQL و Firebird وجدت أن محرك قاعدة البيانات MySQL لديه طريقة سهلة وهي جزء لاتجزأ منه، أي لا نحتاج لتثبيت أي إضافات أخرى لتنفيذ عملية النسخ الحي هذه Replication. وقد وجدت الطريقة في هذه التدوينة وقمت بتنفيذها بنجاح والحمد لله ولم تأخذ وقت كبير.

الفكرة كانت في تثبيت محرك قاعدة بيانات MySQL في جهازين، الجهاز اﻷول هو الرئيسي Master واﻵخر التابع Slave، ثم نقوم بتفعيل الـ Loging في الجهاز الرئيس، ثم نقوم بقراءة معلومات الـ Log وتعريفها في الجهاز التابع، وإضافة مستخدم في الجهاز الرئيس لديه صلاحية الـ replication. ثم تعريف هذا المستخدم في الجهاز التابع. بعد ذلك نقوم بتشغيل خدمة الـ Slave في الجهاز التابع وهي ضمن محرك قاعدة البيانات MySQL، وبعدها يتم إضافة أي تعديل يحدث في الجهاز الرئيس إلى الجهاز التابع، وهذه التغييرات التي يتم نقلها تلقائياً يُمكن أن تكون:

  1. إنشاء قاعدة بينات جديدة
  2. إنشاء جدول جديد
  3. إضافة حقول
  4. حذف جدول أو حقل
  5. إضافة سجلات
  6. تعديل سجلات
  7. حذف سجلات

والجميل في الطريقة هي أنها Asynchronous أي أنه إذا كان الجهاز التابع مغلق أو تعذر اﻹتصال مع الجهاز الرئيس يتم تنفيذ كل التغييرات عند تشغيل التابع أو توفر اﻹتصال. ويتم نقل وتحديث كافة قواعد البيانات الموجودة في الجهاز الرئيس وليس قاعدة بيانات واحدة فقط.

في السابق كُنت أفكر أن أعتمد على طبقة اﻷقراص في النسخ اﻹحتياطي بإستخدام تقنية الـ RAID لكن هي طريقة مسؤول عنها من يقوم بتجهيز المخدمات، أما اﻹحتياطي الذي يتم في طبقة قواعد البيانات فيمكن أن تكون في مسؤولية وتحت تصرف المبرمج.

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

الطريقة:

1. في الجهاز الرئيس نقوم بتعديل ملف إعدادات MySQL التالي:


/etc/mysql/my.cnf

نقوم بإزالة التعطيل (#) من اﻷسطر التالية:

server-id        = 1
log_bin          = /var/log/mysql/mysql-bin.log

وهذا يعني أن الرقم التعريفي لمحرك قاعدة البيانات هو 1، وكذلك قُمنا بتعريف مكان تسجيل الـ log وهو لحفظ التغييرات التي تحدث على قواعد البيانات في هذا المخدم.

2. في الجهاز التابع نقوم بفتح نفس ملف اﻹعدادات نعطيه رقم تعريف مختلف مثلاً 2:

server-id=2

3. نقوم بعدها بإعادة تشغيل المخدمين كل على حده بهذا اﻷمر

sudo /etc/init.d/mysqld restart

4. نقوم بإنشاء إسم مستخدم جديد لديه صلاحية replication بالطريقة التالية في الجهاز الرئيس
بعد الدخول على طرفية mysql

motaz@main-server:~$  mysql -h 127.0.0.1 -u root -p'mypassword'
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave-ip' IDENTIFIED BY 'slavepass';
mysql> FLUSH PRIVILEGES;

5. ثم نقوم بإستعراض معلومة الـ Log في الجهاز الرئيس بواسطة هذا اﻷمر:

mysql> flush tables with read lock;
Query OK, 0 rows affected (0.14 sec)

mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000020 |     1417 |              |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.01 sec)

mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)

\quit

6. بعد ذلك في الجهاز التابع نقوم بإدخال تلك المعلومات في طرفية mysql بالطريفة التالية:

mysql> CHANGE MASTER TO

-> MASTER_HOST='192.168.1.2',

-> MASTER_USER='repl',

-> MASTER_PASSWORD='slavepass',

-> MASTER_LOG_FILE='mysql-bin.000020',

-> MASTER_LOG_POS=1417;

7. بعد ذلك نقوم بتشغيل خدمة الـ slave:

mysql> START SLAVE;

يُمكن إسثناء قواعد بيانات من نقلها إلى الجهاز التابع، حيث حدثت لي مشكلة لم يتم علاجها إلا بوضع بعض قواعد البيانات في هذا اﻹستثناء.
ويتم ذلك بإضافة مثل هذه اﻷسطر في الملف my.cfn في الجهاز التابع في البند [mysqld]

replicate-ignore-db = mysql
replicate-ignore-db = test

أيضاً قُمت بإضافة هذا السطر لتفادي التوقف عند حدوث خطأ. لكن يجب معرفة اﻷخطاء التي يُمكن أن تحدث قبل تنفيذ هذا اﻷمر:


slave-skip-errors = all

يتم التأكد من أن خدمة التابع تعمل بإستخدام اﻷمر show slave status\G

mysql> show slave status\G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.2
                  Master_User: root
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000020
          Read_Master_Log_Pos: 1903
               Relay_Log_File: file-server-relay-bin.000023
                Relay_Log_Pos: 252
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: mysql,citrus,agile,press,helpdesk
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 1903
              Relay_Log_Space: 413
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
1 row in set (0.00 sec)

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

إضافة:
قُمت بتحويل محرك قاعدة البيانات الرئيسة إلى MariaDB وعملت بتوافقية مع MySQL حيث كانت القاعدة التابعة هي MySQL

Advertisements

4 أفكار على ”نسخة إحتياطية حية من قاعدة البيانات MySQL/MariaDB Replication

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

WordPress.com Logo

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   / تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   / تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   / تغيير )

Google+ photo

أنت تعلق بإستخدام حساب Google+. تسجيل خروج   / تغيير )

Connecting to %s