სუვერენული მიგრაციის გადამოწმება

Ultimate Multisite: Multi-Tenancy 1.2.0 შეიცავს WP-CLI დადასტურების ბრძანებებს სუვერენული ტენანტების მიგრაციებისთვის. გამოიყენეთ ისინი, როდესაც ტენანტის მიგრაცია, SSO ვიზიტი ან იზოლირებული ინსტალაცია არ იქცევა მოსალოდნელად.

შესასრულებელი ბრძანებები

გაუშვით გადამოწმება ქსელის WordPress ინს stall-ზე:

wp tenant verify-no-legacy --site=<site-id>
wp tenant verify-sovereign-push --site=<site-id>

გამოიყენეთ ტენანტის ID, რომლის მიგრაციასაც ახორციელებთ. პირველი ბრძანება იტყობინებს, რომ ტენანტმა აღარ უნდა დამოკიდებული იყოს ძველ ქსელის მონაცემებზე. მეორე ბრძანება ადასტურებს, რომ სუვერენული push ამოცანები შეიძლება დამუშავდნენ და გამოწურულ იქნას (drain).

გავრცელებული შეცდომები

მონაცემთა ბაზის უფლებები არ ემთხვევა ჰოსტს

თუ გადამოწმება აჩვენებს უფლებების ან writer-user-ის შეცდომებს, შეამოწმეთ კონფიგურირებული მონაცემთა ბაზის ჰოსტი. localhost, 127.0.0.1 და კონტეინერის სერვისის სახელი განსხვავებულია MySQL-ის უფლებების ჰოსტებისთვის. განაახლეთ ტენანტის ჰოსტის მიბმა ან მონაცემთა ბაზის უფლებები, შემდეგ ხელახლა გაუშვით გადამოწმება.

Bedrock-ზე ან ადგილობრივ ინს stall-ებზე არ შეიძლება დაუკავშირდეს

Bedrock-სა და ადგილობრივი სოკეტის (socket) ინსstallაციები შეიძლება მონაცემთა ბაზას localhost-ად აჩვენებდნენ, მაშინ როდესაც runtime-მა კავშირი ჩაატარებს ნორმალიზებულ მისამართზე. ვერსია 1.2.0 ახდენს ერთი და იმავე მანქანის ჰოსტის სტრიქონების ნორმალიზაციას, მაგრამ მორგებული ჰოსტის გადაფარვები შეიძლება კვლავ კონფლიქტში შევიდეს მონაცემთა ბაზის უფლებებთან.

ასინქრო push-ის რიგი არ გამოწურულია (does not drain)

თუ verify-sovereign-push არ დასრულდება, შეამოწმეთ Action Scheduler ან კონფიგურირებული async runner. შეარჩიეთ წარუმატებელი ამოცანების წაშლა მხოლოდ იმ შემთხვევაში, თუ დაადასტურებთ, რომ ისინი უსაფრთხოა ხელახლა ცდადენისთვის ან გადადება.

ტენანტის მომხმარებლების რაოდენობა არასწორია

მიგრაციის დროს უნდა შეიქმნას მომხმარებლები სუვერენული ტენანტისთვის. თუ მოსალოდნელი ინს stall-ის მომხმარებელი აკლია, ხელახლა გაუშვით მომხმარებლის პროვიზიციის ნაბიჯი სანამ SSO-ს ხელახლა ცდადებით.

SSO ვიზიტი უარდება

ステートレスなテナントის ავτοლოგინებისთვის საჭიროა ტენანტის დომენი, ორიგინალური პინი (origin pin), ტოკენის მიზანი (token purpose), nonce და ვადის გასვლის თარიღი ერთმანეთთან შესაბამისობაში იყოს. დარწმუნდით, რომ ტენანტის URL სწორია და შეტყობინების (SSO visit) გენერირებისთანავე ხდება ლოგინის მცდელობა.

როდის უნდა ხელახლა სცადოთ

ინფრასტრუქტურის ნებისმიერი ცვლილების შემდეგ გადაამოწმეთ ვერიფიკაცია. სანამ ყველა ვერიფიკაციის შემოწმება წარმატებით დასრულდება, არ გადაიტანოთ პროდუქციური ტრაფიკი, არ წაშალოთ წყაროს მონაცემები ან არ მოაშოროთ მიგრაციის საკრედenco (migration credentials).