Rolling Upgrade MongoDB Enterprise از 7.0.15 به 7.0.29 (Replica Set)

database administration بازدید: 22

این مقاله یک سناریوی واقعی و عملیاتی از ارتقای MongoDB Enterprise در معماری Replica Set سه‌نودی را توضیح می‌دهد؛ ارتقایی که با هدف رفع آسیب‌پذیری امنیتی (حداقل نسخه قابل قبول 7.0.28) انجام شده و بدون downtime محسوس و با حفظ دسترس‌پذیری انجام شده است.

سناریو دقیقاً همان چیزی است که در محیط تست اجرا شده و خروجی‌ها از اجرای واقعی گرفته شده‌اند، اما برای جلوگیری از حوصله‌سربر شدن، فقط بخش‌های کلیدی آن‌ها آورده شده است.

 

مشخصات محیط

  • MongoDB Edition: Enterprise

  • نسخه اولیه: 7.0.15

  • نسخه هدف: 7.0.29

  • سیستم‌عامل: RHEL 8.10

  • Topology: Replica Set (3 Node)

    • mongo1 (Primary اولیه)

    • mongo2 (Secondary)

    • mongo3 (Secondary)

نصب اولیه MongoDB از طریق Repository رسمی MongoDB Enterprise انجام شده است:

[mongodb-enterprise-7.0]
name=MongoDB Enterprise Repository
baseurl=https://repo.mongodb.com/yum/redhat/8/mongodb-enterprise/7.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-7.0.asc

و نصب با دستور زیر انجام شده بود:

dnf install -y mongodb-enterprise

بررسی وضعیت Replica Set قبل از Upgrade

قبل از هر اقدامی، وضعیت Replica Set بررسی شد:

rs.status()
rs.printSecondaryReplicationInfo()

خروجی‌ها نشان می‌دادند که:

  • هر سه نود health: 1 هستند

  • هر دو secondary کاملاً sync هستند

  • replLag نزدیک صفر است

این مرحله بسیار مهم است؛ چون rolling upgrade فقط زمانی امن است که replication سالم باشد.

 

استراتژی Upgrade

استراتژی انتخاب‌شده:

Rolling Upgrade بدون توقف سرویس

ترتیب اجرا:

  1. Secondary اول (mongo2)

  2. Secondary دوم (mongo3)

  3. StepDown روی Primary و Upgrade نود اصلی (mongo1)

در کل فرآیند، یک اسکریپت پایتون ساده در حال insert هر 0.5 ثانیه داده بود تا پایداری write بررسی شود.

 

مرحله 1: Upgrade نود Secondary (mongo2)

خاموش کردن mongod به‌صورت Graceful

db.adminCommand({ shutdown: 1 })

وضعیت سرویس:

Active: inactive (dead)

status=0/SUCCESS

ارتقا با استفاده از Repository

dnf -y update mongodb-enterprise*

بخشی از خروجی:

Upgrading:

 mongodb-enterprise-server 7.0.29

 mongodb-enterprise-mongos 7.0.29

 mongodb-enterprise-cryptd 7.0.29

 ...

Cleanup:

 mongodb-enterprise-server-7.0.15

راه‌اندازی مجدد سرویس و بررسی نسخه

systemctl start mongod
mongosh --eval "db.version()"

خروجی:

7.0.29

و در Replica Set:

mongo2 stateStr:
 SECONDARY
replLag: 0

مرحله 2: Upgrade نود Secondary دوم (mongo3)

این مرحله دقیقاً مشابه mongo2 انجام شد:

  • shutdown

  • dnf update

  • start mongod

  • بررسی نسخه

پس از این مرحله، هر دو Secondary روی نسخه 7.0.29 قرار گرفتند.

 

مرحله 3: StepDown و Upgrade نود Primary (mongo1)

اجرای StepDown

rs.stepDown(60)

پس از آن، mongo1 به وضعیت زیر رفت:

Enterprise rs0 [direct: secondary]

Upgrade روی mongo1

dnf -y update mongodb-enterprise*

systemctl start mongod

بررسی نسخه:

7.0.29

وضعیت نهایی Replica Set

بررسی نهایی:

rs.status().members.map(m => ({name: m.name, stateStr: m.stateStr}))

خروجی:

mongo2: PRIMARY

mongo1: SECONDARY

mongo3: SECONDARY

بررسی نسخه:

db.version()

7.0.29

بررسی Feature Compatibility Version:

db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })

featureCompatibilityVersion: { version: '7.0' }

که کاملاً صحیح است، چون ارتقا در همان major version انجام شده است.

جمع‌بندی

در این سناریو:

  • ارتقا از MongoDB Enterprise 7.0.15 به 7.0.29 انجام شد

  • آسیب‌پذیری امنیتی هدف برطرف شد

  • Replica Set بدون downtime محسوس باقی ماند

  • write availability و majority حفظ شد

  • Election و replication بدون مشکل انجام شد