Apigee Edge 4.53.01 را به عقب برگردانید

اگر در حین به‌روزرسانی Edge 4.53.01 با خطایی مواجه شدید، می‌توانید مؤلفه‌ای که باعث خطا شده است را برگردانید و سپس دوباره به‌روزرسانی را امتحان کنید.

می‌توانید Edge 4.53.01 را به هر یک از نسخه‌های اصلی زیر برگردانید:

  • نسخه 4.53.00
  • نسخه 4.52.02

بازگرداندن یک نسخه شامل بازگرداندن هر مؤلفه ای است که ممکن است ارتقا داده باشید. علاوه بر این، بر اساس نسخه ای که از آن شروع کرده اید، ممکن است لازم باشد قبل از بازگرداندن برخی از مؤلفه های نرم افزاری، مراحل خاصی را در نظر بگیرید. جدول زیر اجزای مختلف نرم افزاری را فهرست می کند که ممکن است در حین بازگشت به مراحل خاصی برای آنها نیاز باشد:

بازگشت به نسخه توجه ویژه به نرم افزار
4.53.00 Zookeeper ، Postgres ، LDAP
4.52.02 Zookeeper ، Cassandra ، Postgres ، LDAP

در اینجا سناریویی وجود دارد که ممکن است بخواهید یک بازگشت را انجام دهید:

به نسخه اصلی یا فرعی قبلی برگردید . به عنوان مثال، از 4.53.01 تا 4.53.00.

برای اطلاعات بیشتر، روند انتشار Apigee Edge را ببینید.

ترتیب برگشت

بازگشت کامپوننت‌ها باید به ترتیب معکوس انجام شود، با این استثنا که سرورهای مدیریتی باید بعد از کاساندرا بازگردانده شوند. یک ترتیب عمومی معمولی برای بازگشت به حالت اولیه برای Private Cloud 4.53.01 به شکل زیر خواهد بود:

  1. Rollback Qpid، سایر اجزای مرتبط با تجزیه و تحلیل و Postgres.
  2. روترهای برگشتی و پردازشگرهای پیام
  3. بازگشت کاساندرا، نگهبان باغ وحش
  4. سرور مدیریت بازگشت
  5. LDAP برگشتی

برای مثال، فرض کنید کل خوشه Cassandra، تمام سرورهای مدیریتی و چند RMP را از نسخه 4.52.02 به نسخه 4.53.01 ارتقا داده اید و می خواهید به عقب برگردید. در این مورد، شما:

  • همه RMP ها را یک به یک برگردانید
  • کل خوشه Cassandra را با استفاده از پشتیبان‌گیری برگردانید
  • گره های سرور مدیریت لبه برگشتی یکی یکی

چه کسی می تواند یک بازگشت را انجام دهد

کاربری که rollback انجام می دهد باید همان کاربری باشد که Edge را در ابتدا به روز کرده است یا کاربری که به عنوان root اجرا می شود.

به طور پیش فرض، اجزای Edge به عنوان کاربر "apigee" اجرا می شوند. در برخی موارد، ممکن است اجزای Edge را به عنوان کاربران مختلف اجرا کنید. به عنوان مثال، اگر روتر باید به پورت های دارای امتیاز دسترسی داشته باشد، مانند پورت های زیر 1000، باید روتر را به عنوان روت یا به عنوان کاربر با دسترسی به آن پورت ها اجرا کنید. یا ممکن است یک مؤلفه را به عنوان یک کاربر و مؤلفه دیگر را به عنوان کاربر دیگر اجرا کنید.

کامپوننت هایی با کد مشترک

اجزای Edge زیر کد مشترکی دارند. بنابراین، برای برگرداندن هر یک از این مؤلفه‌ها در یک گره، باید همه این مؤلفه‌ها را که در آن گره هستند، برگردانید.

  • edge-management-server (مدیریت سرور)
  • edge-message-processor (پردازنده پیام)
  • edge-router (روتر)
  • edge-postgres-server (سرور Postgres)
  • edge-qpid-server (سرور Qpid)

به عنوان مثال، اگر سرور مدیریت، روتر و پردازشگر پیام را روی گره نصب کرده اید، برای بازگرداندن هر یک از آنها باید هر سه را به عقب برگردانید.

عقبگرد کاساندرا

هنگامی که ارتقای عمده Cassandra روی یک گره خاص انجام می شود، Cassandra طرح واره داده های ذخیره شده در آن گره را تغییر می دهد. در نتیجه، بازگشت مستقیم در محل امکان پذیر نیست.

سناریوهای بازگشت

Cassandra 4.0.X، موجود با Edge for Private Cloud 4.53.01، با سایر اجزای Private Cloud 4.52.02 سازگار است.

لطفاً برای خلاصه ای از استراتژی های مختلف بازگشتی که می توانید استفاده کنید، به جدول زیر مراجعه کنید:

سناریو استراتژی بازگشت
تک DC، برخی از گره های کاساندرا ارتقا یافته اند از پشتیبان گیری استفاده کنید
تک DC، همه گره های کاساندرا ارتقا یافته اند کاساندرا را عقب نکشید. سایر اجزا را می توان به عقب برگرداند.
DC منفرد، همه گره ها (Cassandra و دیگران) ارتقا یافته اند کاساندرا را عقب نکشید. سایر اجزا را می توان به عقب برگرداند.
DC چندگانه، برخی از گره ها در یک DC ارتقا یافته اند بازسازی از DC موجود
DC چندگانه، تمام گره‌های Cassandra در برخی DCها ارتقا یافته‌اند بازسازی از DC موجود
چندین گره DC، Cassandra آخرین DC در حال ارتقاء سعی کنید ارتقا را تمام کنید. اگر امکان پذیر نیست، 1 DC را با استفاده از پشتیبان برگردانید . DCهای باقیمانده را از DC برگشتی بازسازی کنید .
DC چندگانه، همه گره‌های کاساندرا ارتقا یافته‌اند کاساندرا را عقب نکشید. سایر اجزا را می توان به عقب برگرداند.
DC چندگانه، همه گره ها (Cassandra و دیگران) ارتقا یافته اند کاساندرا را عقب نکشید. سایر اجزا را می توان به عقب برگرداند.

ملاحظات کلی

هنگام در نظر گرفتن یک بازگشت، موارد زیر را در نظر داشته باشید:

  • بازگشت اجزای زمان اجرا یا مدیریت: اگر می خواهید اجزایی مانند edge-management-server، edge-message-processor یا هر جزء غیر Cassandra را به Private Cloud نسخه 4.52.02 برگردانید، توصیه می شود Cassandra را به عقب برگردانید. Cassandra ارسال شده با Private Cloud 4.53.00 با تمام اجزای غیر Cassandra Edge برای Private Cloud 4.52.02 سازگار است. شما می توانید اجزای غیر کاساندرا را با استفاده از روشی که در اینجا ذکر شده است برگردانید در حالی که کاساندرا در نسخه 4.0.13 باقی می ماند.
  • بازگشت پس از ارتقای کل کلاستر Cassandra به 4.0.X: اگر کل خوشه Cassandra شما به نسخه 4.0.X به عنوان بخشی از ارتقاء به Private Cloud نسخه 4.53.00 ارتقا یافته است، توصیه می‌شود که به این راه‌اندازی خوشه ادامه دهید و نه کاساندرا را به عقب برگردانید. اجزایی مانند edge-management-server، edge-message-processor، edge-router و غیره نسخه 4.52.02 Private Cloud با نسخه 4.0.X Cassandra سازگار است.
  • بازگشت کاساندرا در حین ارتقاء کاساندرا: اگر در حین ارتقاء کاساندرا با مشکلاتی مواجه شدید، ممکن است بخواهید یک بازگشت را در نظر بگیرید. استراتژی‌های بازگشتی فهرست‌شده در این مقاله را می‌توان بر اساس وضعیتی که در طول فرآیند ارتقا در آن هستید دنبال کرد.
  • بازگشت با استفاده از پشتیبان‌گیری: نسخه‌های پشتیبان گرفته شده از Cassandra 4.0.X با نسخه‌های پشتیبان Cassandra 3.11.X سازگار نیستند. برای بازگرداندن کاساندرا با استفاده از بازیابی پشتیبان، باید قبل از اقدام به ارتقاء، از Cassandra 3.11.X نسخه پشتیبان تهیه کنید.

بازگشت کاساندرا با استفاده از بازسازی

پیش نیازها

  • شما در حال کارکردن یک خوشه Edge for Private Cloud 4.52.02 در چندین مرکز داده هستید.
  • شما در حال ارتقای Cassandra از 3.11.X به 4.0.X هستید و در حین ارتقا با مشکلاتی مواجه شده اید.
  • شما حداقل یک مرکز داده کاملاً کاربردی در خوشه دارید که هنوز نسخه قدیمی کاساندرا (Cassandra 3.11.X) را اجرا می کند.

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

مراحل سطح بالا

  1. یک مرکز داده (به طور جزئی یا به طور کامل ارتقا یافته) را که می خواهید به عقب برگردانید انتخاب کنید. ترافیک زمان اجرا را به یک مرکز داده با عملکرد متفاوت هدایت کنید.
  2. گره seed را در مرکز داده شناسایی کنید و با یکی از گره های seed شروع کنید.
  3. گره Cassandra را متوقف، حذف و پاکسازی کنید.
  4. نسخه قدیمی Cassandra را روی گره نصب کنید و آن را در صورت نیاز پیکربندی کنید.
  5. تنظیمات اضافی را که قبلا اضافه شده اند حذف کنید.
  6. مراحل بالا را برای تمام گره های seed در مرکز داده یک به یک تکرار کنید.
  7. مراحل بالا را برای تمام گره های کاساندرا باقی مانده در مرکز داده، یک به یک تکرار کنید.
  8. گره ها را از مرکز داده عملکردی موجود، یکی یکی بازسازی کنید.
  9. تمام اجزای edge-* را در مرکز داده که به Cassandra متصل هستند، مجددا راه اندازی کنید.
  10. تست کنید و ترافیک را به این مرکز داده بازگردانید.
  11. مراحل را برای هر مرکز داده، یکی یکی تکرار کنید.

مراحل دقیق

  1. یک مرکز داده را انتخاب کنید که در آن همه یا برخی از گره های Cassandra ارتقا یافته باشند. در حالی که گره‌های Cassandra در این مرکز داده در حال بازگرداندن هستند، تمام ترافیک پراکسی زمان اجرا و ترافیک مدیریتی را از این مرکز داده منحرف کنید. مطمئن شوید که تمام گره‌های Cassandra در حالت UN (Up/Normal) هستند، زمانی که فرمان nodetool ring روی گره‌ها اجرا می‌شود. اگر گره های خاصی خراب هستند، مشکل را عیب یابی کنید و قبل از ادامه، آن گره ها را پشتیبان بگیرید.

    مثال زیر را ببینید:

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    می توانید nodetool describecluster روی گره ها اجرا کنید تا وضعیت فعلی کل خوشه را درک کنید. به عنوان مثال، موارد زیر نمونه ای از یک خوشه مرکز داده 2 را نشان می دهد که در آن همه گره های DC-1 در نسخه 4 کاساندرا هستند، در حالی که همه گره های DC-2 در نسخه 3 کاساندرا هستند:

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    4.0.13: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    3.11.16: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. شناسایی گره های بذر در مرکز داده: به بخش نحوه شناسایی گره های بذر در پیوست مراجعه کنید. مراحل زیر را روی یکی از گره های بذر اجرا کنید:
  3. توقف، حذف، و پاک کردن داده ها از گره Cassandra. اولین گره بذر را در نسخه 4 کاساندرا در این مرکز داده انتخاب کنید. بس کن 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. نرم افزار قدیمی کاساندرا را بر روی گره نصب کنید و برخی از تنظیمات را تنظیم کنید. فایل بوت استرپ Edge را برای Private Cloud 4.52.02 اجرا کنید. 
    5. # Download bootstrap of 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u uName:pWord

# Execute bootstrap of 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

تنظیمات کاساندرا را تنظیم کنید

  1. فایل /opt/apigee/customer/application/cassandra.properties را ایجاد یا ویرایش کنید.
  2. مطالب زیر را به فایل اضافه کنید. ipOfNode آدرس IP گره ای است که Cassandra برای برقراری ارتباط با سایر گره های Cassandra استفاده می کند: 
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  3. اطمینان حاصل کنید که فایل متعلق به کاربر apigee و قابل خواندن است: 
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  4. Cassandra را نصب و راه اندازی کنید:
    • Cassandra نسخه 3.11.X را نصب کنید: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
    • Cassandra را با ارسال فایل پیکربندی استاندارد راه اندازی کنید: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
    • اطمینان حاصل کنید که Cassandra 3.11.X نصب شده است و سرویس در حال اجرا است: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  5. بررسی کنید که گره شروع شده است. دستور زیر را روی این گره و سایر گره های خوشه بررسی کنید. گره باید گزارش دهد که در حالت "UN" (بالا/عادی) است: 
    /opt/apigee/apigee-cassandra/bin/nodetool status
  6. تنظیمات اضافی اضافه شده قبلی را از فایل /opt/apigee/customer/application/cassandra.properties حذف کنید.
  7. مراحل 3 تا 6 را روی تمام گره‌های بذر کاساندرا در مرکز داده یک به یک تکرار کنید.
  8. مراحل 3 تا 6 را روی تمام گره های کاساندرا باقی مانده در مرکز داده، یک به یک تکرار کنید.
  9. تمام گره های مرکز داده را از یک مرکز داده که نسخه قدیمی کاساندرا را اجرا می کند، بازسازی کنید. این مرحله را یک نود انجام دهید:
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>
     این روش ممکن است کمی طول بکشد. در صورت لزوم می توانید streamingthroughput تنظیم کنید. وضعیت را با استفاده از: 
    /opt/apigee/apigee-cassandra/bin/nodetool netstats
  10. همه اجزای edge-* را در مرکز داده یک به یک راه اندازی مجدد کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  11. اعتبارسنجی و هدایت ترافیک به این مرکز داده. برخی از اعتبارسنجی‌ها را برای ترافیک زمان اجرا و APIهای مدیریتی در این مرکز داده اجرا کنید و مسیریابی مجدد پراکسی و ترافیک API مدیریت به آن را شروع کنید.
  12. مراحل بالا را برای هر مرکز داده ای که می خواهید به عقب برگردانید، تکرار کنید.

بازگشت کاساندرا با استفاده از پشتیبان‌گیری

پیش نیازها

  1. شما در حال ارتقای Cassandra از 3.11.X به 4.0.X هستید و در حین ارتقا با مشکلاتی مواجه شده اید.
  2. برای گره‌ای که در حال بازگرداندن آن هستید، نسخه‌های پشتیبان دارید. پشتیبان گیری قبل از ارتقاء از 3.11.X به 4.0.X گرفته شد.

مراحل

  1. یک گره را که می خواهید به عقب برگردانید انتخاب کنید. اگر با استفاده از پشتیبان‌گیری، تمام گره‌ها را در یک مرکز داده به عقب برگردانید، ابتدا با گره‌های اولیه شروع کنید. به بخش "نحوه شناسایی گره های بذر" در پیوست مراجعه کنید.

  2. گره Cassandra را متوقف، حذف و پاکسازی کنید: 

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. نرم افزار قدیمی Cassandra را روی گره نصب کرده و آن را پیکربندی کنید:

    • فایل بوت استرپ را برای Edge for Private Cloud 4.52.02 اجرا کنید: 
      • # Download bootstrap for 4.52.02
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh -u ‘uName:pWord’

# Execute bootstrap for 4.52.02
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
    • فایل /opt/apigee/customer/application/cassandra.properties را ایجاد یا ویرایش کنید: 
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • مطمئن شوید که فایل متعلق به کاربر apigee است و قابل خواندن است: 
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Cassandra را نصب و راه اندازی کنید: 
      • # Install Cassandra version 3.11.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    بررسی کنید که گره شروع شده است. دستور زیر را روی این گره و سایر گره های خوشه بررسی کنید. گره ها باید گزارش دهند که این گره در وضعیت "UN" است: 

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. سرویس Cassandra را متوقف کنید و نسخه پشتیبان را بازیابی کنید. برای جزئیات بیشتر به اسناد پشتیبان و بازیابی مراجعه کنید: 

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. پس از بازیابی نسخه پشتیبان، تنظیمات اضافی را حذف کنید:

    پیکربندی اضافه شده قبلی را از فایل /opt/apigee/customer/application/cassandra.properties حذف کنید.

  6. سرویس Cassandra را در گره راه اندازی کنید: 

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. مراحل را در هر گره Cassandra که می خواهید با استفاده از پشتیبان گیری به عقب برگردانید، یک به یک تکرار کنید.

  8. هنگامی که تمام گره های Cassandra بازیابی شدند، همه اجزای edge-* را یکی یکی مجدداً راه اندازی کنید: 

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

بهینه سازی های پشتیبان (گزینه پیشرفته)

اگر نسخه‌های مشابهی در دسترس دارید که حاوی آخرین داده‌ها هستند، می‌توانید هنگام بازیابی نسخه‌های پشتیبان از دست دادن داده‌ها را به حداقل برسانید (یا از بین ببرید). اگر نسخه‌های مشابه در دسترس هستند، پس از بازیابی نسخه پشتیبان، یک تعمیر را روی گره‌ای که بازیابی شده است اجرا کنید.

ضمیمه

نحوه شناسایی گره های بذر

در هر گره Cassandra در مرکز داده، دستور زیر را اجرا کنید: 

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

این دستور چندین خط خروجی می دهد. به دنبال آخرین خط خروجی باشید. آدرس های IP لیست شده در خط آخر گره های اولیه هستند. در مثال زیر، DC-1-IP1 ، DC-1-IP2 ، DC-2-IP1 ، و DC-2-IP2 IP های گره اولیه هستند: 

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

به روز رسانی Zookeeper 3.8.4 را برگردانید

بازگشت به عقب

در صورت نیاز به بازگشت:

  1. ابتدا مراحل بازگشت را روی ناظران و پیروان انجام دهید.
  2. بوت استرپ نسخه ای را که در حال بازگشت به آن هستید دانلود و اجرا کنید—چه 4.52.02 یا 4.53.00. بسته به اینکه گره اتصال اینترنت خارجی داشته باشد یا نصب آفلاین را دنبال می کنید، روند احتمالاً متفاوت خواهد بود.
  3. اگر Zookeeper روی گره اجرا می شود، آن را متوقف کنید: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. حذف نصب باغ وحش موجود: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. Zookeeper را طبق معمول نصب کنید: 
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. هنگامی که همه دنبال کنندگان و ناظران به عقب برگشتند، با دنبال کردن مراحل 2 تا 5 در گره رهبر، گره رهبر را به عقب برگردانید.
  7. بعد از اینکه همه گره ها به عقب برگشتند، سلامت خوشه را بررسی کنید و مطمئن شوید که یک گره رهبر در خوشه وجود دارد.

بازیابی نسخه پشتیبان

به بازیابی از پشتیبان مراجعه کنید. توجه داشته باشید که نسخه‌های پشتیبان Zookeeper از نسخه‌های قبلی Edge برای Private Cloud مانند 4.52.02 یا 4.53.00 باید با نسخه Zookeeper در Edge برای Private Cloud 4.53.01 سازگار باشد.

به روز رسانی Postgres 17 را به عقب برگردانید

اگر از نسخه 4.52.02 یا 4.53.00 به 4.53.01 ارتقاء داده اید، باید علاوه بر اجزای Edge، به روز رسانی Postgres خود را برگردانید.

برای بازگرداندن به‌روزرسانی Postgres هنگام به‌روزرسانی Postgres در پیکربندی اصلی آماده به کار:

  • گره آماده به کار جدید را برای تبدیل شدن به استاد Postgres تبلیغ کنید. Master جدید Postgres همان نسخه نصب قبلی Edge شما خواهد بود.
  • گره آماده به کار قدیمی را طوری پیکربندی کنید که یک گره آماده به کار استاد جدید باشد. گره آماده به کار قدیمی همان نسخه نصب قبلی Edge شما خواهد بود.
  • گره های اصلی و آماده به کار جدید را در گروه های تجزیه و تحلیل و مصرف کننده ثبت کنید.

پس از اتمام کار بازگشت، دیگر نیازی به گره اصلی قدیمی نخواهد بود. سپس می توانید گره اصلی قدیمی را از کار بیندازید.

  1. مطمئن شوید که گره آماده به کار جدید Postgres در حال اجرا است:
    /opt/apigee/apigee-service/bin/apigee-all status

    اگر Postgres در حال اجرا نیست، آن را شروع کنید: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. مطمئن شوید که Postgres در گره اصلی قدیمی و گره آماده به کار قدیمی متوقف شده است:
    /opt/apigee/apigee-service/bin/apigee-all status

    اگر Postgres در حال اجرا است، آن را متوقف کنید: 

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop > /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. در صورت نصب، Qpid را در گره آماده به کار قدیمی راه اندازی کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. گره آماده به کار جدید را به عنوان Master Postgres ارتقا دهید:
    1. گره آماده به کار جدید را به عنوان استاد جدید ارتقا دهید:
      apigee-service apigee-postgresql promote-standby-to-master new_standby_IP

      اگر از شما خواسته شد، رمز عبور Postgres را برای کاربر 'apigee' وارد کنید، که پیش فرض آن "postgres" است.

    2. فایل پیکربندی را که برای نصب نسخه فعلی Edge استفاده کردید، ویرایش کنید تا موارد زیر را مشخص کنید: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. استاد جدید را پیکربندی کنید: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. اگر قبلا گره آماده به کار قدیمی را به نسخه جدیدتر ارتقا داده اید، ابتدا باید نرم افزار Apigee را بر روی گره آماده به کار قدیمی دانگرید کنید. اگر هنوز نسخه قدیمی‌تر را در گره آماده به کار قدیمی دارید، می‌توانید این مرحله را رد کرده و با مرحله 6 ادامه دهید.
    1. Postgres را در گره آماده به کار قدیمی متوقف کنید: 
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. Postgres را از گره آماده به کار قدیمی حذف نصب کنید: 
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
    3. دایرکتوری داده Postgres را از گره آماده به کار قدیمی حذف کنید: 
      cd /opt/apigee/data/apigee-postgresql/pgdata > rm -rf *
    4. نسخه قدیمی بوت استرپ (برای نسخه Apigee که در حال بازگشت به آن هستید) را در گره آماده به کار قدیمی دانلود و اجرا کنید. مراحل دقیق ممکن است بسته به اینکه از نصب مبتنی بر اینترنت یا آفلاین استفاده می کنید متفاوت باشد. اجرای نسخه قدیمی بوت استرپ Apigee، مخازن yum را با داده های نسخه قدیمی Apigee راه اندازی می کند.
    5. کامپوننت های Postgres را در گره آماده به کار قدیمی تنظیم کنید: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. بررسی و تأیید کنید که اجزای Postgres در گره آماده به کار قدیمی به نسخه قدیمی تر بازگردانده شده اند: 
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. گره آماده به کار قدیمی را بازسازی کنید:
    1. فایل پیکربندی را که برای نصب نسخه فعلی Edge استفاده کردید، ویرایش کنید تا موارد زیر را مشخص کنید: 
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. دایرکتوری داده را در گره آماده به کار قدیمی حذف کنید: 
      cd /opt/apigee/data/apigee-postgresql/pgdata > rm -rf *
    3. گره آماده به کار قدیمی را دوباره پیکربندی کنید تا یک گره آماده به کار استاد جدید باشد: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. مطمئن شوید که Postgres در گره آماده به کار قدیمی اجرا می شود:
      /opt/apigee/apigee-service/bin/apigee-all status

      اگر Postgres در حال اجرا نیست، آن را شروع کنید: 

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. بررسی کنید که گره آماده به کار جدید با مشاهده فایل /opt/apigee/apigee-postgresql/conf/pg_hba.conf در اصلی جدید اضافه شده است.
  8. با اجرای دستور زیر در سرور مدیریت، تجزیه و تحلیل فعلی و اطلاعات گروه مصرف کننده را مشاهده کنید:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    این دستور نام گروه تحلیلی را در قسمت name و نام گروه مصرف کننده را در قسمت name در زیر consumer-groups برمی گرداند. همچنین UUID های اصلی Postgres و گره های آماده به کار را در قسمت postgres-server و در قسمت datastores برمی گرداند. شما باید خروجی را به شکل زیر ببینید: 

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. آدرس UUID استاد قدیمی را با اجرای دستور curl زیر در گره اصلی قدیمی دریافت کنید:
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    شما باید UUID گره را در انتهای خروجی به شکل زیر ببینید: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. مرحله قبل را تکرار کنید تا آدرس های IP گره آماده به کار قدیمی و اصلی جدید را دریافت کنید.
  11. گره های اصلی و آماده به کار قدیمی را از گروه مصرف کننده حذف کنید:
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    جایی که axgroup-001 و consumer-group-001 نام های پیش فرض گروه های تجزیه و تحلیل و مصرف کننده هستند. masterUUID,standbyUUID به همان ترتیبی هستند که هنگام مشاهده تجزیه و تحلیل فعلی و اطلاعات گروه مصرف کننده در بالا ظاهر شدند. ممکن است مجبور شوید آنها را به عنوان standbyUUID,masterUUID مشخص کنید.

    ویژگی datastores برای consumer-groups اکنون باید خالی باشد.

  12. گره های اصلی و آماده به کار قدیمی را از گروه تجزیه و تحلیل حذف کنید:
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    ویژگی postgres-server تحت uuids اکنون باید خالی باشد.

  13. نودهای جدید PG master و standby را با تجزیه و تحلیل و گروه های مصرف کننده ثبت کنید: 
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. اعتبار گروه تجزیه و تحلیل:
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    شما باید UUID گره های اصلی و آماده به کار جدید را در گروه تجزیه و تحلیل و گروه مصرف کننده مشاهده کنید.

  15. سرور Edge Management را مجددا راه اندازی کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. همه سرورهای Qpid را راه اندازی مجدد کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. همه سرورهای Postgres را راه اندازی مجدد کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. با صدور اسکریپت های زیر در هر دو سرور، وضعیت تکرار را تأیید کنید. برای اطمینان از تکرار موفقیت آمیز، سیستم باید نتایج یکسانی را در هر دو سرور نمایش دهد:

    در استاد جدید، اجرا کنید: 

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    بررسی کنید که استاد است. در گره آماده به کار قدیمی:

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    بررسی کنید که در حالت آماده به کار است.

  19. مرحله قبل را بعد از چندین درخواست API تکرار کنید تا مطمئن شوید که گره ها همگام هستند.
  20. مستر قدیمی Postgres را با استفاده از روش Decommissioning a Postgres node از کار خارج کنید.

    همچنین، می‌توانید Qpid را از اصلی قدیمی حذف کنید و Qpid را روی گره اصلی جدید نصب کنید . پس از حذف نصب Qpid، می توانید گره اصلی قدیمی را از کار بیندازید.

به روز رسانی LDAP 2.6 را برگردانید

این بخش یک راهنمای جامع و گام به گام برای بازگرداندن نصب LDAP به نسخه قبلی LDAP ارائه می دهد. بازگشت باید در کل خوشه LDAP انجام شود و تنها با استفاده از یک نسخه پشتیبان LDAP پیش از ارتقا معتبر امکان پذیر است.

هدف اصلی این است که کل خوشه LDAP را از یک پشتیبان خوب - شناخته شده به یک حالت ثابت بازگردانیم. این روش برای همه سناریوها یکسان است - سرور تک، فعال-فعال و فعال-غیرفعال.

پیش نیازها و ملاحظات

  • ناسازگاری پشتیبان‌گیری: از نسخه 2.4 LDAP قدیمی‌تر استفاده کنید که با Edge برای Private Cloud 4.52.02 یا 4.53.00 اجرا می‌کردید. این نسخه پشتیبان باید قبل از اقدام به ارتقاء گرفته شده باشد. پشتیبان‌گیری‌هایی که پس از ارتقاء گرفته می‌شوند ناسازگار هستند و قابل استفاده نیستند.
  • خرابی API مدیریت: در طول بازگشت LDAP، APIهای مدیریتی در دسترس نیستند، که ممکن است بر وظایف اداری تأثیر بگذارد. لطفاً قبل از ادامه دادن به عقب‌گرد LDAP، مطمئن شوید که همه سرورهای مدیریت لبه و رابط کاربری لبه را خاموش کرده‌اید.
  • خطر از دست دادن داده ها: ادامه بدون پشتیبان گیری معتبر و سازگار خطر از دست دادن غیرقابل برگشت داده ها را به همراه دارد.
  • پشتیبان گیری معتبر: یک نسخه پشتیبان LDAP پیش از ارتقاء معتبر لازم است.

رویه برگشت

  1. لطفاً قبل از ادامه ارتقاء LDAP، مطمئن شوید که همه سرورهای مدیریت لبه و رابط کاربری لبه را خاموش کرده‌اید. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. پشتیبان گیری از داده های LDAP موجود (قبل از توقف LDAP)

    تعداد کل رکورد را برای مرجع از همه سرورهای ldap دریافت کنید. (تعداد رکورد باید در تمام سرورهای LDAP مطابقت داشته باشد) 

          # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password. 
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. توقف و حذف LDAP جدید 2.6

    سرویس apigee-openldap را متوقف کنید و پیکربندی و دایرکتوری های داده آن را حذف کنید. این باید در تمام سرورهای LDAP، یک گره در یک زمان در خوشه انجام شود تا از سازگاری اطمینان حاصل شود. 

    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. نسخه قدیمی LDAP 2.4 را نصب کنید
    • نسخه قدیمی LDAP را نصب کنید: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • اعتبار سنجی نسخه LDAP: 
      source ~/.bash_profile
ldapsearch -VV

#Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46
    • مراحل بالا را در هر گره LDAP یک به یک تکرار کنید
  5. داده های باقیمانده را پاک کنید

    در تمام سرورهای LDAP، یکی یکی، سرویس تازه نصب شده را متوقف کنید و فهرست داده های آن را پاک کنید تا برای بازیابی از پشتیبان آماده شوید. 

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. بازیابی اطلاعات LDAP

    برای راه اندازی تک سرور، می توانید مستقیماً به مرحله 5b بروید. برای راه اندازی چند سرور، مرحله 5a را ادامه دهید.

    1. سرور LDAP فعال را شناسایی کنید

      قبل از بازیابی اطلاعات LDAP، با اجرای این دستور سرور فعال (ارائه دهنده) را شناسایی کنید. 

      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif

* **Note**:
* If this command returns output, the server is a passive server. 
* If it returns no output, the server is the active server.
    2. بازیابی اطلاعات LDAP (قبل از بازیابی، مطمئن شوید که مرحله 4 در تمام سرورها تکمیل شده است.)
      • در سرور LDAP منفرد و فعال (که در مرحله 5a تعیین شده است)، نسخه پشتیبان را بازیابی کنید. 
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00
# Note: If no timestamp is provided, the latest available backup will be restored by default.
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • سرویس apigee-openldap را راه اندازی کنید. 
        apigee-service apigee-openldap start
  7. سرورهای باقیمانده LDAP را شروع کنید

    اگر راه اندازی چند سرور دارید، در هر یک از سرورهای LDAP، سرویس را راه اندازی کنید: 

    apigee-service apigee-openldap start
  8. اعتبار سنجی نهایی
    • مرحله آخر این است که تأیید کنیم که بازگشت موفقیت آمیز بوده و داده ها در کل خوشه LDAP سازگار هستند.
    • دستور اعتبار سنجی را روی همه سرورهای LDAP اجرا کنید. تعداد رکوردها باید در همه سرورها یکسان باشد و باید با تعداد ثبت شده در مرحله 1 مطابقت داشته باشد. 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \ -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • هنگامی که تأیید کردید که داده ها صحیح و سازگار هستند، بازگشت LDAP شما کامل می شود. اکنون می‌توانید با راه‌اندازی edge-management-server ، edge-ui و هر مؤلفه وابسته دیگر طبق رویه ارتقای استاندارد سازمان خود ادامه دهید.

به نسخه اصلی یا فرعی قبلی برگردید

برای بازگشت به نسخه اصلی یا فرعی قبلی، موارد زیر را در هر گره ای که مؤلفه را میزبانی می کند انجام دهید:

  1. فایل bootstrap.sh را برای نسخه ای که می خواهید به آن برگردید دانلود کنید:

    • برای بازگشت به 4.52.02، bootstrap_4.52.02.sh دانلود کنید
  2. متوقف کردن مؤلفه برای برگشت به عقب:
    1. برای برگرداندن هر یک از مؤلفه‌های دارای کد مشترک در گره، باید همه آنها را متوقف کنید، همانطور که مثال زیر نشان می‌دهد: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. برای برگرداندن هر مؤلفه دیگری در گره، فقط آن مؤلفه را متوقف کنید: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. اگر می خواهید کسب درآمد را به عقب برگردانید، آن را از تمام گره های سرور مدیریت و پردازشگر پیام حذف نصب کنید: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. کامپوننت را حذف نصب کنید تا دوباره روی گره بازگردد:
    1. برای برگرداندن هر یک از مؤلفه‌های دارای کد مشترک در گره، باید همه آنها را با حذف نصب گروه مؤلفه edge-gateway و apigee-cassandra-client حذف نصب کنید، همانطور که در مثال زیر نشان داده شده است: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. برای برگرداندن هر مؤلفه دیگری در گره، فقط آن مؤلفه را حذف نصب کنید، همانطور که مثال زیر نشان می دهد:
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      جایی که component نام کامپوننت است.

    3. برای برگرداندن مسیریاب لبه، باید محتویات فایل /opt/nginx/conf.d را علاوه بر حذف نصب گروه مؤلفه edge-gateway حذف کنید: 
      cd /opt/nginx/conf.d
rm -rf *
  5. نسخه 4.53.01 apigee-setup را حذف نصب کنید: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. نسخه 4.52.02 ابزار apigee-service و وابستگی های آن را نصب کنید. مثال زیر نسخه 4.52.02 apigee-service را نصب می کند:
    sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

    جایی که uName و pWord نام کاربری و رمز عبوری است که از Apigee دریافت کرده‌اید. اگر pWord را حذف کنید، از شما خواسته می شود آن را وارد کنید.

    اگر با خطا مواجه شدید، مطمئن شوید که فایل bootstrap.sh را در مرحله 1 دانلود کرده اید.

  7. نصب apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. نسخه قدیمی کامپوننت را نصب کنید:
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    جایی که component کامپوننتی است که باید نصب شود و configFile فایل پیکربندی شما برای نسخه قدیمی است.

  9. اگر Qpid را به عقب برگردانید، iptables را فلاش کنید: 
    sudo iptables -F
  10. این فرآیند را برای هر گره ای که میزبان مؤلفه ای است که در حال بازگرداندن آن هستید، تکرار کنید.

mTLS را به عقب برگردانید

برای بازگرداندن به‌روزرسانی mTLS، مراحل زیر را در همه میزبان‌ها انجام دهید:

  1. توقف Apigee: 
    apigee-all stop
  2. توقف mTLS: 
    apigee-service apigee-mtls uninstall
  3. نصب مجدد mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf