การย้ายฐานข้อมูลที่ราบรื่น: ใช้บริการย้ายฐานข้อมูล GCP เพื่อให้ MySQL ไปยังระบบคลาวด์ได้อย่างราบรื่น

ในวิวัฒนาการทางสถาปัตยกรรมของบริษัทอินเทอร์เน็ตงานที่น่าตื่นเต้นที่สุดเช่นการเดินบนน้ำแข็งบางๆคือ "การย้ายฐานข้อมูล" อย่างแน่นอน

การย้ายฐานข้อมูลแบบเดิมก็เหมือนกับการเปลี่ยนยางสำหรับรถเฮอริเคนบนทางหลวงเพื่อให้แน่ใจว่าข้อมูลมีความสอดคล้องกันแนวทางปฏิบัติเดิมมักจะเลือกที่จะวางสายประกาศปิดเครื่องเวลาสามโมงเช้าตัดการรับส่งข้อมูลส่วนหน้าทั้งหมดจากนั้นใช้

มายเอสคิวแอลดัมป์

ส่งออกไฟล์ SQL ขนาดใหญ่หลายสิบ GB จากนั้นส่งและนำเข้าสู่ระบบคลาวด์อย่างช้าๆผลลัพธ์ที่ได้มักเกิดจากการหยุดชะงักของเครือข่ายกระวนกระวายใจหรือความเร็วในการนำเข้าช้าเกินไปซึ่งนำไปสู่รุ่งอรุณและในที่สุดก็ถูกบังคับให้ม้วนกลับภายใต้ความกดดันสูงของพนักงานทุกคนซึ่งไม่เพียงแต่ทำให้ทีม R & D สูญเสียเส้นผมแต่ยังส่งผลกระทบอย่างร้ายแรงต่อบริษัทธุรกิจหลัก.

ในระบบนิเวศสมัยใหม่ของ Google Cloud(GCP, Google Cloud) มีสิ่งประดิษฐ์การโจมตีแบบลดมิติที่ออกแบบมาเพื่อทำลายการหยุดชะงักนี้เรียกว่า

Database Migration Service (บริการย้ายฐานข้อมูลเรียกว่า DMS)

。

ตรรกะหลักของมันบริสุทธิ์มาก:

การโฮสต์เต็มรูปแบบการหยุดทำงานเป็นศูนย์การซิงโครไนซ์แบบเรียลไทม์ที่ไร้รอยต่อ

。ด้วยการรวมเทคโนโลยีการจำลองแบบ Binlog เนทีฟของ MySQL DMS สามารถเปิดประตูเพื่อรับลูกค้าทางธุรกิจออนไลน์ได้ตามปกติและในขณะเดียวกันก็ย้ายข้อมูลจากฐานข้อมูลเก่าไปยังระบบคลาวด์อย่างต่อเนื่องเหมือนน้ำไหลในพื้นหลังหลังจากข้อมูลทั้งสองด้านได้รับการจัดตำแหน่งอย่างสมบูรณ์แล้วคุณจะต้องเลือกช่วงบ่ายที่สงบและใช้เวลาสองสามวินาทีในการเปลี่ยนสตริงการเชื่อมต่อส่วนหน้าเบาๆเพื่อทำ "คลาวด์ที่ราบรื่น" ในระดับโรงงานขนาดใหญ่

วันนี้เราไม่ได้พูดถึงสูตรการเข้ารหัสที่ซับซ้อนและปฏิเสธเรื่องไร้สาระใดๆตัดโดยตรงจากการต่อสู้แบบฮาร์ดคอร์และจับมือคุณเพื่อดำเนินการจาก MySQL ที่สร้างขึ้นเองในเครื่องไปยัง Google Cloud

Cloud SQL for MySQL

แบบฝึกหัดการโยกย้ายที่ไร้รอยต่อ

ขั้นตอนที่1: การรื้อลึก DMS การโยกย้ายแบบเรียลไทม์ของ "สองขั้นตอนของโลกทางกายภาพแบบจำลอง"

ก่อนที่จะไปที่คอนโซลและคลิกเมาส์คุณต้องสร้างแบบจำลองการทำงานทางกายภาพของ DMS ในใจของคุณมิฉะนั้นคุณจะสับสนกับเครือข่ายที่ซับซ้อนและการกำหนดค่าสิทธิ์อย่างแน่นอน

การโยกย้าย DMS แบบเรียลไทม์ที่เพิ่มขึ้นเต็มรูปแบบโดยพื้นฐานแล้วจะสร้างช่องทางการส่งข้อมูลที่มีความพร้อมใช้งานสูงที่ด้านล่างของอินทราเน็ตของ Google วงจรชีวิตทั้งหมดแบ่งออกเป็นสองขั้นตอนหลัก:

ขั้นตอนแรก: การเริ่มต้นตลาดสต็อก (Full Dump): เมื่อคุณเริ่มงานการย้าย DMS จะบรรจุโครงสร้างตารางและข้อมูลทั้งหมดของสต็อกปัจจุบันของไลบรารีต้นทางอย่างรวดเร็วโดยไม่ส่งผลกระทบต่อการอ่านและเขียนฐานข้อมูลต้นทางของคุณสำเนาหนึ่งชุดจะถูกส่งไปยังไลบรารีเป้าหมาย Cloud SQL บนคลาวด์อย่างรวดเร็ว

ขั้นตอนที่สอง: การติดตามกระแสที่เพิ่มขึ้น (สำเนา CDC/Binlog): เมื่อสินค้าคงคลังถูกย้าย DMS จะเปลี่ยนไปใช้โหมดการเก็บข้อมูลต่อเนื่อง (CDC) อย่างราบรื่นมันจะกลายเป็น MySQL Slave มาตรฐาน (ไลบรารีทาส) จ้องมองไปที่ Binlog (บันทึกไบนารี) ของไลบรารีต้นทางตราบใดที่ผู้ใช้ออนไลน์สั่งซื้อใหม่และเปลี่ยนรหัสผ่าน DMS จะใส่สิ่งนี้ในระดับมิลลิวินาที

"คว้า" การแก้ไขส่วนเพิ่มและเล่นซ้ำในคลังเป้าหมายบนคลาวด์

ข้อสรุปของสถาปัตยกรรมหลัก: ในสองขั้นตอนนี้ฐานข้อมูลเก่าของคุณจะถูกเก็บไว้สำหรับธุรกิจภายนอกตลอดกระบวนการทั้งหมดและไม่จำเป็นต้องหยุดทำงานแม้แต่วินาทีเดียวไลบรารีคลาวด์ใหม่เปรียบเสมือนเงาของไลบรารีเก่าและทำตามขั้นตอนเดียวกันจนกว่าความแตกต่างของเวลาของข้อมูลทั้งสองด้านจะเป็นศูนย์

ขั้นตอนที่สอง: วันก่อนการต่อสู้จริง-ดึง "pass" ในฐานข้อมูลต้นทางที่สร้างขึ้นเอง

เพื่อให้ DMS สามารถเข้ามาและเคลื่อนย้ายอิฐได้อย่างถูกกฎหมายก่อนอื่นเราต้องกลับไปที่บ้านเกิดของเรา (ไลบรารีแหล่ง MySQL ที่สร้างขึ้นเองในท้องถิ่น) เพื่อทำการกำหนดค่าพื้นฐานบางอย่าง

1.เปิดบันทึก Binlog (ฉีดวิญญาณคัดลอกแบบเรียลไทม์)

เปิดไลบรารีต้นทางของคุณ

มาย.ซีเอ็นเอฟ

หรือ

My.ini

ไฟล์คอนฟิกูเรชันตรวจสอบให้แน่ใจว่าบรรทัดต่อไปนี้ไม่ได้แสดงความคิดเห็นและพารามิเตอร์ถูกต้อง:

Ini, TOML

[Mysqld]

Log-bin = mysql-bin

Binlog_format = ROW # ต้องอยู่ในรูปแบบ ROW DMS อาศัยสิ่งนี้เพื่อระบุการเปลี่ยนแปลงของข้อมูลแต่ละแถวอย่างแม่นยำ

Server-id = 100001 # ระบุ ID คลัสเตอร์ที่ไม่ซ้ำกันสำหรับไลบรารีต้นทาง

Expire_logs_days = 7 # Binlog เก็บไว้อย่างน้อย7วันเพื่อป้องกันไม่ให้ DMS ถูกลบโดยอัตโนมัติก่อนที่ระบบจะอ่าน

หลังจากการเปลี่ยนแปลงอย่าลืมรีสตาร์ท MySQL ที่สร้างขึ้นเองเพื่อให้การกำหนดค่ามีผล

2.สร้างบัญชี "ตัวเชื่อมต่อ" เฉพาะ DMS

เชื่อมต่อกับไลบรารีต้นทางและพิมพ์คำสั่ง SQL ของข้อกำหนดผู้ผลิตรายใหญ่ต่อไปนี้เพื่อสร้างบัญชีที่ปลอดภัยพร้อมสิทธิ์การคัดลอกเฉพาะสำหรับ GCP DMS:

เอสคิวแอล

-สร้างบัญชีที่เรียกว่า gcp_dms และอนุญาตให้เชื่อมต่อจากที่ใดก็ได้ (หรือระบุส่วนเครือข่ายภายใน GCP)

CREATE USER 'gcp _ dms' @ '%' IDENTIFIED BY 'YourHardPassword123! ';

-ให้สิทธิ์การอ่านข้อมูลพื้นฐานและสิทธิ์การคัดลอกคลัสเตอร์ (หลักการของการอนุญาตขั้นต่ำสำหรับผู้ผลิตรายใหญ่)

GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *. * TO 'gcp_ dms' @ '%';

-รีเฟรชสิทธิ์เพื่อให้รหัสลับมีผลทันที

FLUSH PRIVILEGES;

ขั้นตอนที่สาม: การกำหนดค่าสายการประกอบการโยกย้าย DMS แบบลงมือปฏิบัติจริง

สภาพแวดล้อมพร้อมเราเข้าสู่ระบบ

คอนโซล GCP

,ค้นหาแล้วเข้าไป

Database Migration (การย้ายฐานข้อมูล)

หน้าเพจ

ขั้นตอนที่1: สร้างงานโยกย้าย (Migration Job)

คลิก "สร้างงานโยกย้าย" ที่ด้านบน:

ชื่องาน: mysql-to-cloudsql-prod 。

เครื่องยนต์ฐานข้อมูลต้นทาง: เลือก MySQL 。

เครื่องมือฐานข้อมูลเป้าหมาย: เลือก Cloud SQL สำหรับ MySQL 。

ประเภทการโยกย้าย: ไม่ลังเลที่จะเลือก "Continuous (Continuous)" หมายเหตุ: เฉพาะการเลือก Continuous เท่านั้นที่เป็นการย้ายข้อมูลที่ราบรื่นและราบรื่นด้วยการซิงโครไนซ์ที่เพิ่มขึ้นหากคุณเลือก One-time (ครั้งเดียว) ข้อมูลจะหยุดทันทีหลังจากการย้ายข้อมูลและไม่สามารถเปลี่ยนการหยุดทำงานเป็นศูนย์ได้

ขั้นตอนที่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ไต้หวัน)

ตั้งรหัสผ่านที่แข็งแกร่งสำหรับบัญชีรูทคลาวด์และเลือกข้อมูลจำเพาะของเครื่อง (เช่นหน่วยความจำ2คอร์4GB สภาพแวดล้อมการผลิตอย่าลืมตรวจสอบ "ความพร้อมใช้งานสูงและแนวป้องกันสูง" เพื่อเปิดใช้งานการกู้คืนระบบแบบ dual-acting ข้ามพื้นที่ใช้งาน)

ขั้นตอนที่4: Connectivity Method-ตัดแฮกเกอร์สอดแนม

นี่เป็นสถานที่ที่ง่ายที่สุดในการเหยียบหลุม DMS ของ Google Cloud ผ่านไฟร์วอลล์เพื่อเชื่อมต่อเครื่องท้องถิ่นของคุณอย่างไร DMS มีวิธีการเชื่อมต่อมาตรฐานสามวิธี:

คำแนะนำขั้นสูง: Reverse SSH Tunnel: DMS จะสร้างเครื่องเสมือน VM ระดับกลางที่มีน้ำหนักเบามากในพื้นหลังและให้คำสั่ง SSH แก่คุณคุณจะต้องเรียกใช้ชุดคำสั่งนี้บนเซิร์ฟเวอร์ภายในเพื่อดึงอุโมงค์ทางเดียวที่เข้ารหัสอย่างสมบูรณ์ซึ่งเจาะผ่านไฟร์วอลล์ระหว่างอินทราเน็ตท้องถิ่นและ GCP คุณไม่จำเป็นต้องเปิดพอร์ต3306ทั่วโลกบนไฟร์วอลล์ของบริษัทและปัจจัยด้านความปลอดภัยจะเต็มโดยตรง

ทางเลือก: รายการอนุญาต IP: ล็อกกลุ่มที่อยู่ IP สาธารณะอย่างเป็นทางการที่ GCP DMS แจ้งให้คุณเข้าสู่รายการที่อนุญาตพิเศษของไฟร์วอลล์ฮาร์ดแวร์ที่ชั้นนอกสุดของห้องคอมพิวเตอร์ในพื้นที่ของคุณ

หลังจากผ่านการทดสอบการเชื่อมต่อแล้วให้คลิกที่ด้านล่าง

"สร้างและเริ่มงาน (Create &

Amp; Start Job)”

。

ขั้นตอนที่สี่: เป็นสักขีพยานในช่วงเวลาแห่งปาฏิหาริย์-การไล่ตามแบบเรียลไทม์ออนไลน์และการหยุดชะงักขั้นสูงสุดการเปลี่ยนแปลงทั้งหมด

หลังจากคลิกเพื่อเริ่มต้นพลังการประมวลผลแบบกระจายที่ยืดหยุ่นขนาดใหญ่ของ DMS จะถูกปลุกขึ้นทันทีกลับไปที่รายการย้ายงานและคุณจะจ้องที่แถบสถานะเพื่อเป็นสักขีพยานในวิวัฒนาการของวงจรชีวิตที่มีมนต์ขลัง:

สถานะเปลี่ยนจากการสร้างเป็นการเริ่มต้นจากนั้นป้อนการถ่ายโอนข้อมูลแบบเต็มในขั้นตอน (หมายความว่ามันกำลังจัดการข้อมูลสต็อกเก่าที่คุณฝากไว้ในช่วงไม่กี่ปีที่ผ่านมา)

หลังจากย้ายสต็อกแล้วสถานะจะกลายเป็น CDC สีเขียวในขั้นตอน (การจำลองแบบต่อเนื่อง)

จุดนี้ไปที่คอนโซลและดู

"ความล่าช้าในการคัดลอก (Replication Lag)"

ตัวชี้วัดในช่วงแรกเนื่องจากการเปลี่ยนแปลงใหม่ที่เกิดขึ้นระหว่างการจัดการสินค้าคงคลังความล่าช้าอาจใช้เวลาไม่กี่นาทีแต่ในไม่ช้าเนื่องจากแบนด์วิดท์อินทราเน็ตที่แข็งแกร่งของ Google ถูกเปิดอย่างเต็มที่

Replication Lag จะเป็นศูนย์ (0 seconds)

。

ซึ่งหมายความว่าในขณะนี้ข้อมูลทุกชิ้นในฐานข้อมูลเก่าในเครื่องของคุณและข้อมูลในฐานข้อมูล Google Cloud Cloud SQL ใหม่ได้มาถึงแล้ว

การซิงโครไนซ์แบบเรียลไทม์ระดับพิกเซลแบบสัมบูรณ์

。

วิธีการทำงานห้าขั้นตอนของ "การตัดทองและการไหล" ของมาตรฐานโรงงานขนาดใหญ่:

เมื่อความล่าช้าคงที่ที่0วินาทีเราสามารถเลือกช่วงเวลาที่ตกต่ำทางธุรกิจได้ (เช่นเมื่อผู้ใช้เข้าชมน้อยที่สุดในเวลา16.00น.) และดำเนินการตัดการไหลขั้นสุดท้ายทั้งหมดกระบวนการทั้งหมดใช้เวลาเพียง10วินาที:

ระงับการอ่านอย่างเดียวชั่วคราวที่ส่วนหน้า: เรียกใช้ SET GLOBAL read_only = 1ในพื้นหลังของเว็บแอปพลิเคชันของคุณหรือในไลบรารีต้นทาง MySQL บังคับให้ไลบรารีเก่ากลายเป็น "สถานะอ่านอย่างเดียว" การดำเนินการนี้ใช้เพื่อให้แน่ใจว่าภายในไม่กี่วินาทีของการสลับคำสั่งซื้อใหม่จะไม่ถูกเขียนลงในไลบรารีเก่าอย่างลับๆซึ่งจะทำให้ข้อมูลทั้งสองด้านขาดการเชื่อมต่อ

รอการตรวจสอบขั้นสุดท้าย: จ้องที่คอนโซล DMS รอ5วินาทีเพื่อให้หาง Binlog สุดท้ายที่กำลังส่งจะเล่นซ้ำอย่างสมบูรณ์ในระบบคลาวด์เพื่อให้แน่ใจว่าข้อมูลทั้งสองด้านไม่เลว

คลิกปุ่มใหญ่ "อัพเกรด": บนคอนโซล GCP DMS ให้คลิก "อัพเกรด" ที่ด้านบนเรื่องราวภายใน: การกระทำนี้จะตัดความสัมพันธ์ในการจำลองแบบทาสระหว่างไลบรารีคลาวด์ใหม่และไลบรารีเก่าทันทีไลบรารีเป้าหมาย Cloud SQL จะแยกออกจากข้อมูลประจำตัวของไลบรารีทาสในทันทีและพัฒนาไปสู่ไลบรารีหลักระดับบนสุด (Master) ที่เป็นอิสระอย่างสมบูรณ์อ่านได้และเขียนได้

เปลี่ยนสตริงการเชื่อมต่อ: เชื่อมต่อฐานข้อมูลทั้งหมดในการกำหนดค่าเว็บและไมโครเซอร์วิสแบ็คเอนด์ของคุณเข้ากับ IP จาก IP ไลบรารีที่สร้างขึ้นเองเดิมคลิกเดียวเพื่อแก้ไขและชี้ไปยัง IP เครือข่ายสาธารณะ/อินทราเน็ต Cloud SQL ใหม่

รีสตาร์ทแอปพลิเคชันและคืนชีพอย่างสมบูรณ์: แอปส่วนหน้าเชื่อมต่อกับไลบรารีคลาวด์ใหม่อีกครั้งและยกเลิกการอ่านอย่างเดียวคำสั่งซื้อใหม่เริ่มเข้าสู่ตลาดด้วยประสิทธิภาพที่สูงมากใน Google Cloud

งานที่สมบูรณ์แบบ!

หลังจากการต่อสู้ทั้งหมดไคลเอนต์จะได้รับข้อความแจ้ง "ไม่สามารถสั่งซื้อ/รายงานข้อผิดพลาด" เล็กน้อยและสั้นมากระหว่างขั้นตอนที่1และ4เว็บไซต์โดยรวมไม่เคยมีการประกาศบ้านสีดำขนาดเล็กและข้อมูลจะสูญหายเป็นศูนย์, Shangyun ได้รับชัยชนะครั้งใหญ่

ขั้นตอนที่5: ประวัติการหลีกเลี่ยงเลือดและน้ำตาภายใต้โครงสร้างฐานข้อมูลข้ามชาติ

แผนการย้ายโฮสต์เต็มรูปแบบนี้มีความหรูหราอย่างยิ่งในการใช้งานแต่เพื่อที่จะอยู่รอดในสภาพแวดล้อมการผลิตพร้อมกันระดับสูงระดับองค์กรในฐานะหัวหน้าสถาปนิกข้อมูลคุณต้องป้องกันหลุมที่มองไม่เห็นสองหลุมต่อไปนี้ที่มาจากความแตกต่างในรายละเอียดทางเทคนิคพื้นฐาน:

1.ร้ายแรง "โซนเวลาและชุดอักขระ (Collation) ความผิดปกติทางจิต"

หลายทีมย้ายข้อมูลและพบว่ารหัสเก่าที่ทำงานออนไลน์เป็นเวลาครึ่งปีหลังจากเชื่อมต่อกับ Cloud 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 Database Migration Service สำหรับการย้ายฐานข้อมูลที่ราบรื่นสาระสำคัญระดับอุตสาหกรรมหลักอยู่ที่16คำ:

กำหนดค่าล็อค

อุโมงค์เปิด Binlog จับอัพเกรดตัดกระแส

。

คุณได้อำลาการส่งออกและการขนส่งด้วยตนเองในรูปแบบการประชุมเชิงปฏิบัติการในเวลาสามโมงเช้าการสื่อสารบนเครือข่ายทั้งหมดแพ็คเกจข้อมูลขนาดใหญ่และการซิงโครไนซ์สถานะแบบเรียลไทม์จะถูกส่งมอบให้กับสมองที่มีการโฮสต์และปลอดภัยระดับบนสุดของ Google เพื่อโคลนการเชื่อมสินทรัพย์ฐานข้อมูลหลักอย่างราบรื่นและราบรื่นบนรากฐานที่มีการป้องกันสูงของระบบคลาวด์เป็นท่าทางการกวาดล้างของสถาปนิกที่สง่างามและเป็นของแท้ที่สุดในยุคคลาวด์สมัยใหม่