จะย้ายฐานข้อมูล GCP ได้อย่างราบรื่นได้อย่างไร? การย้ายข้อมูลแบบไม่หยุดนิ่งด้วย Database Migration Service (DMS)

ในด้านการประมวลผลแบบคลาวด์มีสิ่งหนึ่งที่สถาปนิกและการดำเนินงานและการบำรุงรักษา (SRE) ทุกคนสามารถทำงานล่วงเวลาได้ตลอดทั้งคืนและนั่นคือ

การย้ายฐานข้อมูล

。

เมื่อหลายคนได้ยินคำว่า "ย้ายห้องสมุด" ภาพที่อยู่ในใจคือเลือกช่วงเวลาธุรกิจที่ต่ำในวันที่30ของปีใหม่หรือสามโมงเช้าแขวนประกาศ "ระบบอยู่ระหว่างการบำรุงรักษา" ในหน้าแรกจากนั้นรีบส่งออก SQL, ถ่ายโอนไฟล์, นำเข้าไลบรารีใหม่, แก้ไขการกำหนดค่า... กระบวนการทั้งหมดก็เหมือนกับการเดินไต่เชือกที่ระดับความสูงเมื่อลิงก์ใดติดอยู่หรือข้อมูลไม่ตรงกันเวลาในการระงับธุรกิจจะยาวขึ้นเรื่อยๆ

แต่ในความเป็นจริงแล้วผู้ให้บริการระบบคลาวด์ในปัจจุบันไม่ได้รับความนิยมมานานแล้วในการ "ฆ่าศัตรูหนึ่งพันคนและเอาชนะตัวเองแปดร้อยคน" วันนี้เราจะมาพูดถึงสิ่งประดิษฐ์ที่จัดทำโดย Google Cloud (GCP)-

Database Migration Service (DMS)

。

ในฐานะคนที่ผ่านโคลนในสภาพแวดล้อมการผลิตวันนี้ฉันใช้ภาษาที่เข้าใจง่ายที่สุดโดยไม่ต้องพูดถึงคำศัพท์ที่ทำให้ง่วงนอนในเอกสารราชการและสอนวิธีใช้ DMS เพื่อให้บรรลุ "การหยุดทำงานเป็นศูนย์" "การเคลื่อนไหวที่ราบรื่น

1.แนวคิดหลัก: "zero stop moving moving" ของ DMS คืออะไร?

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

การซื้อบัญชี Google Cloud

การเริ่มต้นแบบเต็ม (การจำลองข้อมูลหุ้น):DMS จะคัดลอกข้อมูลย้อนหลังทั้งหมดที่มีอยู่ในฐานข้อมูลต้นฉบับไปยังไลบรารีเป้าหมายของ GCP (เช่น Cloud SQL) ก่อนในกระบวนการนี้ธุรกิจออนไลน์ของคุณจะทำงานตามปกติและการอ่านและการเขียนตามปกติจะไม่ได้รับผลกระทบเลย

การซิงโครไนซ์ที่เพิ่มขึ้น (ข้อมูลการติดตามแบบเรียลไทม์): เมื่อมีการส่งข้อมูลในอดีต DMS จะอ่านบันทึกของไลบรารีต้นทาง (เช่น Binlog ของ MySQL หรือ WAL ของ PostgreSQL) และข้อมูลทางธุรกิจที่สร้างขึ้นใหม่อย่างต่อเนื่องในระหว่างการย้ายเต็มจำนวนซิงโครไนซ์ "ไปยังไลบรารีใหม่ในขณะนี้ข้อมูลของไลบรารีเก่าและใหม่เกือบจะซิงโครไนซ์แบบเรียลไทม์

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

เวลาหยุดชะงักของธุรกิจเป็นเพียงไม่กี่สิบวินาทีหรือแม้แต่วินาทีเมื่อรีสตาร์ทแอปพลิเคชันและสลับการกำหนดค่า

2."การตรวจสอบความปลอดภัยสามครั้ง" ก่อนย้าย (การเตรียมการ)

การเคลื่อนย้ายด้วย DMS ก็เหมือนกับการบินโดยเครื่องบินเมื่อการตรวจสอบความปลอดภัยเสร็จสิ้นการเดินทางก็ประสบความสำเร็จครึ่งหนึ่งสามจุดต่อไปนี้กำหนดโดยตรงว่าการย้ายข้อมูลจะล้มเหลวหรือไม่:

1.เปิดบันทึกของไลบรารีต้นทาง (ขั้นตอนที่สำคัญที่สุด)

DMS ต้องสามารถอ่านบันทึกแบบเรียลไทม์ของไลบรารีต้นทางของคุณเพื่อทำการซิงโครไนซ์เพิ่มเติม

ถ้าไลบรารีต้นทางคือ MySQL: คุณต้องแน่ใจว่าได้เปิด binlog และ binlog_format ต้องตั้งค่าเป็น ROW,binlog

_ Row_image ถูกตั้งค่าเป็น FULL 。

หากไลบรารีต้นทางเป็น PostgreSQL: คุณต้องตั้งค่า wal_level เป็น logical และกำหนดค่า Slots Replication

2.คิดเกี่ยวกับวิธีการเชื่อมต่อเครือข่าย (แผนการเชื่อมต่อ)

ต้องสามารถพูดคุยระหว่างไลบรารีต้นทางและ GCP ได้อย่างปลอดภัย DMS มีวิธีการเชื่อมต่อหลายวิธีเรียงตามระดับความปลอดภัยและคำแนะนำ:

การเชื่อมต่อ VPC (การเชื่อมต่อแบบเพียร์ทูเพียร์ VPC): หากไลบรารีต้นทางของคุณอยู่ใน VPC อื่นของ GCP หรือห้องคอมพิวเตอร์ที่เชื่อมต่อผ่านสายเฉพาะ (Interconnect) นี่เป็นตัวเลือกแรกรวดเร็วและปลอดภัย

Reverse SSH Tunnel (อุโมงค์ SSH ย้อนกลับ): โปรแกรมพลเรือนที่ใช้บ่อยที่สุดเปิดเครื่องเสมือนขนาดเล็กในเครือข่ายของไลบรารีต้นทางเป็นเครื่องกระโดดน้ำและเชื่อมต่อ GCP ผ่านอุโมงค์เข้ารหัส

รายการอนุญาต IP (Public IP): ง่ายที่สุดแต่ยังแนะนำน้อยที่สุดเปิดเผย IP เครือข่ายสาธารณะของไลบรารีต้นทางโดยตรงไปยังช่วง IP ของ DMS หากการทดสอบสามารถทำได้เพียงแค่ใช้สภาพแวดล้อมการผลิตด้วยความระมัดระวัง

3.สร้างบัญชีการโยกย้าย

การซื้อบัญชี Google Cloud

อย่าใช้โดยตรง

รูท

หรือ

ผู้ดูแลระบบ

บัญชีสูงสุดประเภทนี้จะเรียกใช้สำหรับการโยกย้ายสร้างไฟล์

Dms_user

ให้สิทธิ์การอ่านและคัดลอกที่จำเป็นเท่านั้น (เช่น MySQL

REPLICATION CLIENT

,

REPLICATION SLAVE

,

เลือก

ฯลฯ) หลังจากการย้ายเสร็จสิ้นให้ลบบัญชีนี้โดยตรงซึ่งปลอดภัยและสง่างาม

3.การต่อสู้จริง: สี่ขั้นตอนในการกำหนดค่า DMS

การเตรียมการเสร็จสิ้นเราตรงไปที่คอนโซล GCP ค้นหา

Database Migration

。

ขั้นตอนที่1: สร้าง "Migration Job"

หลังจากคลิกที่สร้างคุณจะต้องกรอกข้อมูลพื้นฐานของงาน:

ประเภทฐานข้อมูลต้นทาง: เช่น MySQL ที่สร้างขึ้นเอง, AWS RDS หรือฐานข้อมูลระบบคลาวด์อื่นๆ

ประเภทฐานข้อมูลเป้าหมาย: โดยปกติแล้วจะเป็น Cloud SQL หรือ AlloyDB ที่โฮสต์โดย GCP 。

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

ขั้นตอนที่2: กำหนดค่าการเชื่อมต่อแหล่งที่มา (Connection Profile)

นี่คือการกรอก "ข้อมูลการตรวจสอบความปลอดภัย" ที่เราเพิ่งเตรียมไว้:

ป้อนที่อยู่ IP พอร์ตบัญชี dms_user และรหัสผ่านของไลบรารีต้นทาง

เลือกวิธีการเชื่อมต่อเครือข่ายที่คุณกำหนด (เช่นกำหนดค่า Rev

อุโมงค์ SSH)

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

ขั้นตอนที่3: กำหนดค่าไลบรารีปลายทาง (Cloud SQL)

หากยังไม่ได้สร้าง Cloud SQL เป้าหมาย DMS จะอนุญาตให้คุณ "สร้างใหม่ด้วยคลิกเดียว" โดยตรงในอินเทอร์เฟซ

คุณสามารถเลือกการกำหนดค่าเดียวกันกับไลบรารีต้นทาง (CPU, หน่วยความจำ, พื้นที่เก็บข้อมูล)

ขอแนะนำอย่างยิ่ง: โดยวิธีการตรวจสอบความพร้อมใช้งานสูง (HA) และการสำรองข้อมูลอัตโนมัติของไลบรารีเป้าหมายในขั้นตอนเดียว

ขั้นตอนที่4: เริ่มการตรวจสอบและเรียกใช้ (Start Job)

ก่อนที่จะคลิกเรียกใช้ DMS จะมีฟังก์ชัน "Pre-flight check" ที่มีประสิทธิภาพมากโดยอัตโนมัติจะช่วยให้คุณตรวจสอบ: รูปแบบบันทึกของไลบรารีต้นทางใช่ไหม? สิทธิ์เพียงพอหรือไม่? เวอร์ชันเข้ากันไม่ได้?

หากมีข้อผิดพลาดสีแดงให้ไปที่ไลบรารีต้นทางเพื่อเปลี่ยนการกำหนดค่าตามคำแนะนำหากเป็นเครื่องหมายขีดสีเขียวทั้งหมดให้คลิกโดยตรง

"เริ่มต้น (Start)"

。

4.Cutover: วิธียิง "ช็อตสุดท้าย" อย่างสมบูรณ์แบบ

เมื่องานทำงานคุณจะเห็นสถานะกลายเป็น

Full dump in progress

(ส่งออกเต็มจำนวน) แล้วกลายเป็น

CDC in progress

(การซิงโครไนซ์ที่เพิ่มขึ้น)

เมื่อเข้าสู่สถานะ

CDC in progress

และ

"ซิงโครไนซ์หน่วงเวลา (Lag)" เข้าใกล้0

ในเวลานั้นหมายความว่าข้อมูลของไลบรารีใหม่และไลบรารีเก่าได้รับการซิงโครไนซ์อย่างสมบูรณ์ในเวลานี้เราสามารถเตรียม "การตัด" ที่แท้จริงได้

นี่คือสาระสำคัญของการกำหนดความสำเร็จหรือความล้มเหลวของการหยุดทำงานเป็นศูนย์โปรดปฏิบัติตามขั้นตอนต่อไปนี้อย่างเคร่งครัด:

1.ธุรกิจสัมผัสกับ "อ่านอย่างเดียว"

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

2.รอให้คลื่นข้อมูลสุดท้ายของ DMS ผูก

สังเกตอินเทอร์เฟซ DMS เพื่อให้แน่ใจว่าความล่าช้า (Lag) กลายเป็น0อย่างสมบูรณ์ซึ่งหมายความว่าข้อมูลสองสามชิ้นสุดท้ายที่สร้างโดยไลบรารีต้นทางก่อนการอ่านอย่างเดียวนั้นอยู่ในไลบรารี GCP ใหม่อย่างต่อเนื่อง

3.คลิกที่ "สมบูรณ์ (Promote)" บน DMS

คลิกที่คอนโซล GCP

“โปรโมชั่น”

ปุ่มการกระทำนี้จะทำสองสิ่ง:

ตัดการซิงโครไนซ์ระหว่างไลบรารีใหม่และไลบรารีเก่า

การซื้อบัญชี Google Cloud

อัปเกรด Cloud SQL เป้าหมายจาก "ผู้รับแบบอ่านอย่างเดียว" เป็น "ไลบรารีหลักของการผลิตที่อ่านและเขียนได้อย่างอิสระ"

4.แก้ไขการกำหนดค่าแอปพลิเคชันและออนไลน์ทั้งหมด

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

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

หากไม่มีการรับรู้เลยก็สำเร็จ!

5.สามเณรหลีกเลี่ยงหลุมและพูดคุยเกี่ยวกับประสบการณ์

แม้ว่า DMS จะใช้งานง่ายแต่ในฐานะคนที่มามีหลุมขนาดใหญ่ที่มองไม่เห็นหลายแห่งที่ต้องเตือนคุณ:

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

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

หมายเหตุเกี่ยวกับเขตเวลา (Timezone): Cloud SQL เป็นเขตเวลา UTC โดยค่าเริ่มต้นหากไลบรารีต้นทางของคุณใช้ Asia/Shanghai (East Eight District) เวลาในการค้นหาแอปพลิเคชันหลังจากการย้ายข้อมูลอาจน้อยกว่า8ชั่วโมงอย่างอธิบายไม่ได้โปรดจำไว้ว่าเมื่อสร้างไลบรารีเป้าหมายให้ปรับพารามิเตอร์โซนเวลา (default_timezone) ให้เหมือนกับไลบรารีต้นทางทุกประการ

📝สรุป

Database Migration Service(DMS) ของ GCP เป็นหลัก

ฟรีไม่มีเซิร์ฟเวอร์ (Serverless) เครื่องมือการโยกย้าย

(คุณจะต้องจ่ายค่าฮาร์ดแวร์และเครือข่ายของไลบรารีเป้าหมายในระหว่างขั้นตอนการย้ายข้อมูลและ DMS เองจะไม่เรียกเก็บค่าธรรมเนียมซอฟต์แวร์)

มันเปลี่ยน "คลังขนย้ายเนื้อมนุษย์ด้วยตนเอง" ที่เคยมีเกณฑ์สูงและมีความเสี่ยงสูงให้กลายเป็นเมาส์ที่ได้มาตรฐานและเป็นภาพ

สรุปประโยคสุดท้าย:

หยุดใช้ความคิดเก่าๆในการปิดระบบและการบำรุงรักษาเพื่อโยนสภาพแวดล้อมการผลิตใช้ DMS เพื่อทำการซิงโครไนซ์ที่เพิ่มขึ้นอย่างต่อเนื่องเข้าใจความคิดริเริ่มในมือของคุณเองและย้ายห้องสมุดด้วยการดื่มกาแฟในระหว่างวันนี่คือท่าทางที่สง่างามที่การดำเนินการและการบำรุงรักษาระบบคลาวด์สมัยใหม่ควรมี!