ฉันมีอินสแตนซ์ RDS MySQL ขนาดเล็กซึ่งเป็นส่วนหนึ่งของระบบการผลิตของฉันและฉันต้องการอัพเกรดเป็นอินสแตนซ์ขนาดกลางที่มี IOPS ที่ให้มา

ในฐานะ DBA โรงเรียนเก่าฉันทราบเกี่ยวกับวิธี "เพิ่มทาส; เลื่อนระดับเป็นหลัก; เปลี่ยนลูกค้า" แต่ AWS สัญญาว่าจะให้บริการเส้นทางการอัปเกรดด้วยคลิกเดียวเช่น "อัปเกรดอินสแตนซ์" "เพิ่ม IOPS ที่จัดเตรียมไว้"

ลองสิ่งนี้กับอินสแตนซ์ทดสอบ RDS การหยุดทำงานนานเกินไป IMHO: ประมาณ 5 นาทีสำหรับการอัพเกรดขนาดเล็ก -> ขนาดกลางและ 30 นาที (!!!) สำหรับการเปลี่ยนเป็น IOPS ที่ให้มา

• นี่เป็นพฤติกรรมปกติหรือไม่
• มีวิธีใดบ้างที่จะเรียกใช้การอัปเกรดจาก RDS ที่ใช้งานจริงซึ่งไม่มีการหยุดทำงานหรือไม่
• คุณแนะนำ "หยุดสร้างสแนปชอตคืนค่าจากสแน็ปช็อตไปเป็นอินสแตนซ์ที่ใหญ่กว่า" หรือไม่?

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

ดูเหมือนจะมีวิธีหนึ่งในการหลีกเลี่ยงปัญหานี้: การปรับใช้ Multi-AZ ซึ่งสร้างแบบจำลองที่มองไม่เห็นและไม่สามารถเข้าถึงได้ (สำหรับคุณ) ในโซนความพร้อมใช้งานอื่นภายในภูมิภาค

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

^{- http://aws.amazon.com/rds/multi-az/}

นั่นควรเป็นเส้นทางการย้ายที่รวดเร็วและราบรื่นแม้ว่าฉันจะไม่มีโอกาสทดสอบความสามารถนี้ "Modify" ในคอนโซลปรากฏขึ้นเพื่อให้คุณสามารถแปลงอินสแตนซ์เป็น Multi-AZ สันนิษฐานว่าสิ่งนี้จะส่งผลให้ I / O สั้น ๆ เมื่ออินสแตนซ์ถูกโคลนดังนั้นแน่นอนว่าผมขอแนะนำให้ทดสอบฟังก์ชั่นทั้งหมดก่อนที่จะลอง

อีกทางเลือกหนึ่ง RDS สนับสนุนกลไกภายในที่ควรอนุญาตให้คุณเลียนแบบการดำเนินการ "เพิ่มทาส; เลื่อนระดับเป็นต้นแบบ; สลับลูกค้า" และสิ่งนี้ยังช่วยให้คุณบรรลุการแปลงที่ไม่เป็นศูนย์:

• สร้าง RDS ที่อ่านได้จริงของฐานข้อมูลของคุณด้วยคลาสอินสแตนซ์ที่ต้องการ
• รอให้แบบจำลองออนไลน์และซิงค์กับต้นแบบ
• ปรับเปลี่ยนการกำหนดค่าของแบบจำลองเพื่อเพิ่ม IOPS ที่จัดสรรไว้
• รอให้แบบจำลองออนไลน์และซิงค์กับต้นแบบ
• ตรวจสอบว่าทั้งสองระบบมีข้อมูลเหมือนกันโดยใช้เครื่องมือของบุคคลที่สาม
• ตัดการเชื่อมต่อแอปพลิเคชันของคุณจากต้นแบบเก่า
• ตรวจสอบพิกัด binlog ที่ตรงกันบนต้นแบบและเรพลิกาเพื่อให้มั่นใจว่าการเขียนแอปพลิเคชันทั้งหมดได้จำลอง
• แบ่งระบบด้วย "Promote Read Replica" บนเรพลิกาใหม่ใน RDS
• เชื่อมต่อแอปพลิเคชันของคุณเข้ากับมาสเตอร์ใหม่

http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/

แม้จะมีสภาพแวดล้อมหลาย AZ คุณจะมีไฟ 60-120 นี่เป็นกรณีที่เมื่อฉันกด RDS อินสแตนซ์ของเราซ้ำ ๆ ในขณะที่ทำการอัพเกรดจาก PostgreSQL db.m3.medium ไปเป็น db.m3. large

นอกจากนี้ยังเป็นไปได้ที่จะหลีกเลี่ยงการหยุดทำงานในระหว่างการอัพเกรด วิธีที่จะทำได้คือการเปิดตัว RDS ใหม่สั้น ๆ จากสแน็ปช็อตการอ่านแบบจำลองและกำหนดค่าเป็น Active / active Master เป็น Master replication เมื่อกำหนดค่าแล้วคุณสามารถสลับแอปพลิเคชันทราฟฟิกของเซิร์ฟเวอร์ APP หนึ่งตัวในเวลานั้น เราใช้วิธีการทุกครั้งที่ AWS ประกาศการบำรุงรักษา RDS เพื่อหลีกเลี่ยงการหยุดทำงานเช่นเดียวกับในระหว่างการบำรุงรักษาตามกำหนดเวลาของเรา

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

นี่คือรายละเอียด:

M1 - อาจารย์ดั้งเดิม

R1 - อ่านแบบจำลองของ M1

SNAP1 - ภาพรวมของ R1

M2 - ปรมาจารย์ใหม่

ลำดับการสร้าง M2: M1 → R1 → SNAP1 → M2

• เนื่องจากเราไม่สามารถใช้สิทธิ์พิเศษบน RDS ได้เราจึงไม่ใช้ mysqldump กับ— master_data2ตัวเลือกใน M1 แต่เราเปิดตัว R1 เพื่อรับตำแหน่ง binlog ของ M1จากมัน จากนั้นสร้างสแน็ปช็อต (SNAP1) จาก R1 จากนั้นเปิด M2 จาก SNAP1

• สร้างกลุ่มพารามิเตอร์ RDS แยกกันสองกลุ่มด้วย offsets ต่อไปนี้เพื่อหลีกเลี่ยงการสับสน PK:

  M1: auto_increment_ increment = 4 and auto_increment_offset = 1

  M2: auto_increment_ increment = 4 and auto_increment_offset = 2

• สร้างผู้ใช้การจำลองแบบบน M1

  GRANT EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ‘repl’@’%’ IDENTIFIED BY PASSWORD <secret>;

1. สร้าง R1 จาก M1

-- Connect to the R1 and stop replication
   CALL mysql.rds_stop_replication;
-- Obtain M1’s (!!) current binlog file and position 
        `mysql> show slave status\G
             Master_Log_File: mysql-bin.000622
             Exec_Master_Log_Pos: 9135555

2. สร้าง SNAP1 จาก R1

• สร้าง M2 จาก SNAP1 ด้วยคุณลักษณะที่ได้รับจาก M1

• กำหนดกลุ่มพารามิเตอร์ให้กับ M2 ด้วยอ็อฟเซ็ต auto_increment_ อื่นจาก M1 เพื่อหลีกเลี่ยงความขัดแย้งของคีย์การจำลองแบบ M / M

4. ตั้งค่าการจำลองแบบ M / M

-- Configure M2 as a slave of M1
CALL mysql.rds_set_external_master (‘m1.xyxy24.us-east-1.rds.amazonaws.com’, 3306, ‘repl’, ‘mypassword’, ‘mysql-bin.000622, 9135555, 0);
CALL mysql.rds_start_replication;
-- Connect to M2 and obtain its current binlog file and position
         mysql> show master status\G
            File: mysql-bin.004444
            Position: 6666622
-- Connect to M1 and configure it to be a slave of the M2
CALL mysql.rds_set_external_master (‘m2.xyxy24.us-east-1.rds.amazonaws.com’, 3306 , ‘repl’, ‘mypassword’, ‘mysql-bin.004444, 6666622, 0);
CALL mysql.rds_start_replication;

5. ลบ R1 และ SNAP1 เนื่องจากไม่ต้องการอีกต่อไป

6. อัปเกรด M2 ผ่าน AWS Console

ใช้ขั้นตอนมาตรฐานเพื่อปรับเปลี่ยนอินสแตนซ์ตามความต้องการของคุณ

7. ดำเนินการเปลี่ยนแปลงอย่างสง่างามเป็น M2

เนื่องจากการตั้งค่าการจำลองแบบ M / M สำเร็จแล้วเราพร้อมที่จะดำเนินการบำรุงรักษาฐานข้อมูลโดยไม่ต้องหยุดทำงานโดยสลับเซิร์ฟเวอร์แอปหนึ่งครั้ง

นี่คือรายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงาน

https://workmarket.tech/zero-downtime-maintenances-on-mysql-rds-ba13b51103c2

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