الترحيل السلس لقاعدة البيانات: استخدام خدمة ترحيل قاعدة بيانات GCP لجعل MySQL سلسة في السحابة
في التطور الهيكلي لشركات الإنترنت ، فإن المهمة الأكثر إثارة ، مثل المشي على الجليد الرقيق ، هي بالتأكيد "ترحيل قاعدة البيانات".
يشبه ترحيل قاعدة البيانات التقليدية تغيير الإطارات على الطريق السريع. من أجل ضمان اتساق البيانات ، عادة ما تكون الطريقة القديمة هي اختيار تعليق إعلان الإغلاق في الساعة 3 صباحًا ، وقطع جميع حركة المرور الأمامية ، ثم استخدامها
مسك دامب
قم بتصدير ملف SQL كبير بسعة عشرات غيغابايت ، ثم قم بنقله واستيراده ببطء إلى السحابة. غالبًا ما تكون النتيجة بسبب انقطاع اهتزاز الشبكة أو بطء سرعة الإدخال ، مما يؤدي إلى عدم اكتمال الفجر. في النهاية ، لا يمكن إجبارهم إلا على التراجع تحت الضغط العالي لجميع الموظفين ، الأمر الذي لا يجعل فريق البحث والتطوير يسقط شعره فحسب ، بل يؤثر أيضًا بشكل خطير على الشركة. الأعمال الأساسية.
في البيئة الحديثة لـ Google Cloud(GCP ، Google Cloud) ، هناك قطعة أثرية مصممة لكسر هذا المأزق ، تسمى
خدمة قاعدة البيانات Migration Service (خدمة ترحيل قاعدة البيانات ، DMS)
.
منطقها الأساسي نقي للغاية:
استضافة كاملة ، صفر توقف ، مزامنة سلسة في الوقت الحقيقي
. من خلال الجمع بين تقنية النسخ المتماثل Binlog الأصلية لـ MySQL ، يمكن لـ DMS فتح أبوابها عبر الإنترنت واستلام العملاء كالمعتاد ، مع نقل بيانات قاعدة البيانات القديمة باستمرار إلى السحابة مثل المياه الجارية في الخلفية. بعد محاذاة البيانات على كلا الجانبين تمامًا ، تحتاج فقط إلى اختيار فترة بعد الظهر هادئة ، وقضاء بضع ثوانٍ في تغيير سلسلة الاتصال في الواجهة الأمامية برفق لإكمال "السحب السلس" على مستوى المصنع الكبير.
اليوم نحن لا نتحدث عن صيغ التشفير المعقدة ، ونرفض أي هراء. اقطع مباشرة من القتال الفعلي للنواة الصلبة ، ويأخذك المقبض لإكمال MySQL المحلي إلى Google Cloud
Cloud SQL for MySQL
تمرين الهجرة السلس.
المرحلة الأولى: التفكيك العميق ، "نموذج العالم المادي على مرحلتين" لـ DMS في الوقت الفعلي
قبل الذهاب إلى وحدة التحكم والنقر بالماوس ، يجب عليك إنشاء نموذج تشغيل فعلي للطبقة السفلية من DMS في عقلك ، وإلا فسوف تشعر بالدوار تمامًا من خلال تكوين الشبكة والأذونات المعقدة.
إن الترحيل التدريجي الكامل في الوقت الفعلي لـ DMS هو في الأساس قناة نقل بيانات قابلة للاستخدام للغاية في الجزء السفلي من الشبكة الداخلية من Google. وتنقسم دورة الحياة بأكملها إلى مرحلتين أساسيتين:
المرحلة الأولى: تهيئة سوق الأسهم (Full Dump): عند بدء مهمة الترحيل ، سيقوم DMS بتعبئة جميع هياكل الجدول وبيانات المخزون الحالي لمكتبة المصدر بطريقة البرق دون التأثير على القراءة والكتابة العادية لمكتبة المصدر الخاصة بك. نسخة واحدة وتسليمها بسرعة إلى مستودع هدف Cloud SQL في السحابة.
المرحلة الثانية: اللحاق بالركب التدريجي (CDC/Binlog): في اللحظة التي يتم فيها نقل المخزون ، سيتحول DMS بسلاسة إلى وضع التقاط البيانات المستمر (CDC). سوف يتحول إلى MySQL Slave قياسي (من المكتبة) ، يحدق في Binlog (السجل الثنائي) للمكتبة المصدر. طالما أن المستخدم عبر الإنترنت يضع طلبًا جديدًا ويغير كلمة المرور ، فإن DMS سيضع هذا على مستوى المللي ثانية
التعديلات الإضافية "الاستيلاء" وإعادة وضعها في مستودع الهدف السحابي.
استنتاج البنية الأساسية: في هاتين المرحلتين ، تظل قاعدة البيانات القديمة الخاصة بك مفتوحة للجمهور طوال العملية بأكملها ، دون الحاجة إلى التوقف لمدة ثانية واحدة. تشبه المكتبة السحابية الجديدة ظل المكتبة القديمة ، وتمضي قدمًا ، حتى يعود فارق التوقيت بين البيانات على كلا الجانبين إلى الصفر.
المرحلة الثانية: عشية القتال الفعلي-سحب "جواز السفر" في قاعدة بيانات مصدر البناء الذاتي
من أجل السماح لـ DMS بالدخول ونقل الطوب بشكل قانوني ، يجب علينا أولاً العودة إلى مسقط رأسنا (مكتبة مصدر MySQL المحلية المبنية ذاتيًا) لإجراء بعض التكوينات الأساسية.
1. فتح سجل Binlog (حقن في الوقت الحقيقي نسخ الروح)
افتح مكتبة المصدر الخاصة بك
ملف my.cnf
أو
.
ملف التكوين ، تأكد من عدم تعليق السطور التالية وأن المعلمات صحيحة:
Ini, TOML
[Mysqld]
Log-bin = mysql-bin
Binlog_format = ROW # يجب أن يكون تنسيق ROW ، يعتمد DMS على هذا لتحديد التغييرات بدقة في كل سطر من البيانات
Server-id = 100001 # تعيين معرف هوية مجموعة فريد للمكتبة المصدر
Expire_logs_days = 7 # Binlog احتفظ بها لمدة 7 أيام على الأقل لمنع DMS من حذفها تلقائيًا بواسطة النظام قبل أن تتمكن من قراءتها
بعد التغيير ، تذكر إعادة تشغيل MySQL الخاص بك لجعل التكوين ساري المفعول.
2. إنشاء حساب "موصل" حصري لـ DMS
قم بربط المكتبة المصدر ، وادخل أوامر SQL التالية الخاصة بمواصفات الشركات المصنعة الرئيسية لإنشاء حساب آمن مع حقوق النسخ الحصرية لـ GCP DMS:
إس كيو إل
-- قم بإنشاء حساب يسمى gcp_dms ، مما يسمح له بالربط من أي مكان (أو تعيين قسم إنترانت GCP)
CREATE USER 'gcp _ dms' @ '%' IDENTIFIED BY 'YourHard Password123! '؛
-- منح حقوق قراءة البيانات الأساسية ونسخ الكتلة (مبدأ السلطة الدنيا للمصنع الكبير)
GRANT SELECT ، RELOAD ، SHOW DATABASES ، REPLICATION SLAVE ، REPLICATION CLIENT ON *.* TO 'gcp _ dms' @ '%' ؛
-- قم بتحديث الأذونات بحيث تصبح العلامة السرية فعالة على الفور
FLUSH PRIVILEGES;
المرحلة الثالثة: تدريب عملي-خط نقل DMS
البيئة جاهزة ، ونحن تسجيل الدخول
وحدة تحكم GCP
، ابحث وادخل
قاعدة بيانات Migration (نقل قاعدة البيانات)
الصفحة.
الخطوة 1: إنشاء مهمة ترحيل (Migration Job)
في الجزء العلوي ، انقر على "إنشاء مهمة ترحيل":
اسم الوظيفة: mysql-to-cloudsql-prod.
محرك قاعدة بيانات المصدر: اختر MySQL.
محرك قاعدة البيانات المستهدفة: اختر Cloud SQL لـ MySQL.
نوع الهجرة: لا تتردد في اختيار "Continuous". ملاحظة: فقط اختيار Continuous هو الانتقال السلس مع التزامن التدريجي ؛ إذا اخترت وقت واحد (لمرة واحدة) ، فستتوقف البيانات بشكل مفاجئ بعد نقل البيانات ، ولا يمكن تحقيق تبديل التوقف الصفري.
الخطوة 2: تعريف ملف تعريف الاتصال المصدر (Source Connection Profile)
هنا ، نريد أن نقول لـ Google معلمات المرحلة الثانية في المنزل:
اسم ملف تعريف الاتصال: source-local-mysql.
اسم المضيف/IP والمنفذ: املأ عنوان IP الخاص بالشبكة العامة أو IP الخاص بالشبكة الداخلية الخاصة بـ MySQL المحلي ، والمنفذ الافتراضي 3306.
اسم المستخدم وكلمة المرور: املأ بدقة gcp_dms وكلمة المرور الخاصة به التي تم بناؤها للتو.
الخطوة 3: تحديد مكتبة الهدف السحابية (Destination)
أين ستنقل بياناتك ؟ يوفر DMS ميزة لا تقهر للغاية هنا --
بنقرة واحدة في الخلفية لمساعدتك في إنشاء مكتبة هدف Cloud SQL الجديدة مباشرة
.
أدخل معرف مثيل قاعدة البيانات السحابية الذي تريد إنشاؤه (مثل cloudsql-mysql-prod).
اختر إصدار MySQL (يوصى بالتوافق مع مكتبة المصدر ، مثل 8.0).
اختر المنطقة (مثل asia-east1 تايوان).
قم بتعيين كلمة مرور قوية لحساب جذر السحابة ، وحدد مواصفات الجهاز (مثل ذاكرة 4 جيجابايت ثنائية النواة ، وتذكر بيئة الإنتاج التحقق من "خط دفاع عالي التوافر" لتمكين القدرة على العيش المزدوج عبر المناطق المتاحة).
الخطوة 4: Connectivity Method-قطع المتسللين
هذا هو المكان الأكثر سهولة للدخول في حفرة. كيف يمكن لـ Google Cloud DMS عبور جدار الحماية للوصول إلى جهازك المحلي ؟ يوفر DMS ثلاث طرق قياسية للاتصال:
خطة التوصية المتقدمة: نفق SSH العكسي: سينشئ DMS جهازًا ظاهريًا متوسطًا خفيفًا للغاية في الخلفية ويعطيك سلسلة من أوامر SSH. تحتاج فقط إلى تشغيل هذه السلسلة من الأوامر على الخادم المحلي لسحب نفق سري أحادي الاتجاه مشفر بالكامل وياختراق جدار الحماية بين الشبكة الداخلية المحلية و GCP. لا تحتاج إلى فتح منافذ 3306 على مستوى العالم على جدار حماية الشركة على الإطلاق ، وعامل الأمان ممتلئ مباشرة.
البديل: قائمة IP المسموح بها: قم بإغلاق مجموعة عناوين IP الرسمية للشبكة العامة التي يطالبك بها GCP DMS في القائمة البيضاء لجدار حماية الأجهزة في الطبقة الخارجية من غرفة الكمبيوتر المحلية.
بعد اجتياز اختبار الاتصال ، انقر على الجزء السفلي
"إنشاء وبدء المهام (Create &
Amp ؛ Start Job)"
.
المرحلة الرابعة: شاهد لحظة المعجزة-اللحاق بالركب في الوقت الفعلي عبر الإنترنت وتغيير التدفق النهائي
بعد النقر لبدء التشغيل ، سيتم إيقاظ قوة الحوسبة الموزعة المرنة الضخمة لـ DMS على الفور. بالعودة إلى قائمة مهام الهجرة ، ستحدق في شريط الحالة لتشهد تطور دورة الحياة السحرية:
تتغير الحالة من Creating إلى Starting ، ثم تدخل Full dump في العرض (مما يعني أنها تنقل بشكل يائس البيانات القديمة التي ترسخت في السنوات القليلة الماضية).
بعد نقل المخزون ، ستصبح الحالة مركز السيطرة على الأمراض الأخضر (النسخ المستمر).
في هذه المرحلة ، اذهب إلى وحدة التحكم
"تأخير النسخ"
المؤشرات. في البداية ، بسبب التغييرات الجديدة التي حدثت أثناء نقل المخزون ، قد يكون هناك تأخير لبضع دقائق ؛ ولكن سرعان ما ، مع إطلاق عرض النطاق الترددي القوي من Google بالكامل ،
Replication Lag سيذهب إلى الصفر تمامًا (0 seconds)
.
هذا يعني أنه في هذه اللحظة ، تم الوصول إلى كل جزء من البيانات الموجودة في المكتبة المحلية القديمة والبيانات الموجودة في المستودع الجديد لـ Google Cloud SQL.
مطلق ، تزامن كامل في الوقت الحقيقي على مستوى البكسل
.
طريقة من خمس خطوات لعملية "التدفق الذهبي" القياسية على مستوى داتشانغ:
عندما يكون التأخير مستقرًا عند 0 ثانية ، يمكننا اختيار فترة منخفضة من الأعمال (على سبيل المثال ، عندما يكون لدى المستخدم أقل عدد من الزيارات في الساعة 4 مساءً) ، وإجراء الاستبدال النهائي. تستغرق العملية برمتها 10 ثوانٍ فقط:
قم بتعليق القراءة فقط المؤقتة في الواجهة الأمامية: قم بتنفيذ SET GLOBAL read_only = 1 في خلفية تطبيق الويب الخاص بك ، أو في مستودع مصدر MySQL ؛ قم بتحويل المكتبة القديمة بالقوة إلى "حالة القراءة فقط". يتم استخدام هذا الإجراء للتأكد تمامًا من أنه في غضون ثوانٍ قليلة من التبديل ، لن يتم كتابة أي طلب جديد سراً في المكتبة القديمة ، مما يؤدي إلى انقطاع البيانات على كلا الجانبين.
انتظر للتحقق من النقص في النهاية: التحديق في وحدة التحكم DMS ، انتظر 5 ثوانٍ ، دع آخر ذيل Binlog الذي يتم إرساله يتم إعادة تشغيله بالكامل في السحابة ، للتأكد من أن البيانات على كلا الجانبين ليست سيئة.
اضغط على الزر الكبير "Promote": في وحدة تحكم GCP DMS ، انقر بشكل حاسم على "Promote" في الجزء العلوي. من الداخل: سيؤدي هذا الإجراء على الفور إلى قطع علاقة نسخ العبيد بين المكتبة السحابية الجديدة والمكتبة القديمة. سيتم فصل المكتبة المستهدفة لـ Cloud SQL عن هوية المكتبة في لحظة ، وتتطور إلى مكتبة رئيسية مستقلة تمامًا وقابلة للقراءة والكتابة.
استبدال سلسلة الاتصال: قم بتوصيل IP لجميع تطبيقات الويب الخلفية وقاعدة البيانات في تكوين الخدمة المصغرة ، من عنوان IP الأصلي للمكتبة التي تم بناؤها ذاتيًا ، قم بتعديله بنقرة واحدة للإشارة إلى Cloud SQL العامة/إنترانت IP الجديد.
إعادة تشغيل التطبيق وإحيائه بالكامل: يتم توصيل التطبيق الأمامي مرة أخرى بمكتبة السحابة الجديدة لإلغاء القراءة فقط. بدأت الطلبات الجديدة في تقديم الطلبات في Google Cloud بأداء عالٍ للغاية.
نهاية مثالية!
بعد المعركة بأكملها ، لم يختبر العميل سوى تذكير بسيط للغاية وقصير المدى "لا يمكن تقديم الطلبات/الإبلاغ عن الأخطاء" بين الخطوتين 1 و 4. لم يعلق الموقع أبدًا إعلانًا عن المنزل الأسود الصغير ككل ، ولم تكن البيانات مفقودة. ، حقق Shangyun فوزًا كبيرًا.
المرحلة الخامسة: تاريخ الدم والدموع في إطار بنية قاعدة البيانات عبر الوطنية
هذه المجموعة من خطط الترحيل المدارة بالكامل أنيقة للغاية. ولكن للبقاء على قيد الحياة في بيئة إنتاج حقيقية عالية التزامن على مستوى المؤسسة ، بصفتك كبير مهندسي البيانات ، يجب عليك منع الحفر الخفية التالية المشتقة من الاختلافات في التفاصيل الفنية الأساسية:
1. "المنطقة الزمنية ومجموعة الأحرف (Collation) الفوضى" القاتلة
بعد الترحيل ، وجدت العديد من الفرق أن الكود القديم الذي تم تشغيله على الإنترنت لمدة نصف عام ، بعد الاتصال بـ Cloud SQL ، فقدت جميع الأوقات الصينية والمحلية بشكل غير مفهوم 8 ساعات. أو تحولت بعض تعليقات المستخدمين التي تحتوي على كلمات نادرة أو تعبيرات Emoji مباشرة إلى رموز مشوهة أو أخطاء.
تفكيك السبب: عادةً ما تتبع المنطقة الزمنية الافتراضية لـ MySQL التي تم إنشاؤها ذاتيًا المضيف (على سبيل المثال ، تم تعيينهما كمنطقة زمنية للنظام CST) ، في حين أن GCP Cloud SQL افتراضيًا للامتثال العالمي ، ويتم قفل المنطقة الزمنية الرئيسية الأساسية بشكل إلزامي كوقت قياسي دولي UTC ، وقد تكون مجموعة الأحرف أيضًا مختلفة قليلاً عن مكتبتك القديمة افتراضيًا.
عملية تجنب الحفرة القياسية للمصنع الكبير: قبل النقر فوق DMS لبدء الترحيل ، انتقل إلى "تغييرات التكوين" في Cloud SQL ، وابحث عن علامة قاعدة البيانات (علامة قاعدة البيانات) ، وأضف بشكل صريح default_time_zone = '08: 00 '(أو يناسب المنطقة الزمنية الرئيسية لعملك) ، ومحاذاة مجموعة الأحرف بالقوة إلى utf8mb4. المعلمة السفلية في المصدر هي نفسها ، وهو القانون الحديدي الأول لمنع الشفرة عبر الإنترنت من الإبلاغ عن الأخطاء.
2. "مصيدة الساعة الرملية الخاملة" بعد نقل DMS
يذهب العديد من المبتدئين بسعادة إلى العمل لتناول القدر الساخن بعد ترقية قاعدة البيانات ودخولها إلى السحابة. نتيجة لذلك ، نظرت إلى الفاتورة في نهاية الشهر ووجدت أنه تم إنشاء رسوم احتلال موارد DMS لا يمكن تفسيرها وغير مكلفة.
اقتراح وقف الخسارة الأساسي: بعد النقر فوق "Promote" ، لم يتم تدمير عملية الترحيل الخاصة بـ DMS فعليًا تمامًا. لا تزال تشغل موارد الحوسبة المؤقتة وواجهات شبكة الشبكة في الخلفية السحابية ، ولا تزال الساعة الرملية المحملة تعمل بشكل محموم.
الموقف الصحيح: بعد التأكد من أن المكتبة السحابية الجديدة تعمل بسلاسة لمدة 24 ساعة ، والتأكيد على عدم الحاجة إلى التراجع ، يجب عليك العودة إلى وحدة التحكم DMS على الفور ، وتحديد عملية الترحيل المكتملة ، والنقر فوق "حذف" بدون عقل. لا تقلق ، لن يكون لحذف المهمة أي تأثير على قاعدة بيانات Cloud SQL التي تطورت بنجاح ، وبهذه الطريقة فقط سيتم إيقاف الخصم تمامًا.
الخلاصة
باستخدام خدمة قاعدة بيانات GCP لنقل قاعدة البيانات بسلاسة ، يكمن جوهر المستوى الصناعي الأساسي في ستة عشر كلمة:
تكوين القفل ،
فتح النفق ، مطاردة Binlog ، ترقية قطع التدفق
.
لقد ودعت تمامًا المصنوعات اليدوية على غرار ورشة العمل التي كانت تحدق في الساعة الثالثة صباحًا. قم بتسليم جميع اتصالات الشبكة ، وتعبئة بيانات السوق الكبيرة ، وحالة الوقت الفعلي إلى أفضل عقل أمان مستضاف بالكامل من Google لاستنساخه. إن اللحام السلس لأصول قاعدة البيانات الأساسية على الأساس الدفاعي العالي للسحابة هو الموقف الأكثر أناقة وأصالة للمهندس المعماري في عصر السحابة الحديثة.