openstack/openstack-ansible
Code Issues Proposed changes
Files
9412d4419006c0d6444392051260126e491aef9c
openstack-ansible/doc/source/admin/scaling-swift.rst
Dmitriy Rabotyagov 443e946c6d [doc] Reffer to mariadb instead of mysql as client 
With latest used MariaDB-client, it has dropped linking to `mysql`
leaving only `mariadb` as an option. So we need to reflect these
changes in our documentation

Closes-Bug: #2099771
Change-Id: Ibf8c65a40c7cc7421f322f5bbf559153b845ef78
2025-02-24 11:49:39 +01:00

2.5 KiB
Raw Blame History

Accessibility for multi-region Object Storage

In multi-region Object Storage utilizing separate database backends, objects are retrievable from an alternate location if the default_project_id for a user in the keystone database is the same across each database backend.

Important

It is recommended to perform the following steps before a failure occurs to avoid having to dump and restore the database.

If a failure does occur, follow these steps to restore the database from the Primary (failed) Region:

  1. Record the Primary Region output of the default_project_id for the specified user from the user table in the keystone database:

    Note

    The user is admin in this example.

    # mariadb -e "SELECT default_project_id from keystone.user WHERE \
  name='admin';"

+----------------------------------+
| default_project_id               |
+----------------------------------+
| 76ef6df109744a03b64ffaad2a7cf504 |
+-----------------—————————————————+

  2. Record the Secondary Region output of the default_project_id for the specified user from the user table in the keystone database:

    # mariadb -e "SELECT default_project_id from keystone.user WHERE \
  name='admin';"

+----------------------------------+
| default_project_id               |
+----------------------------------+
| 69c46f8ad1cf4a058aa76640985c     |
+----------------------------------+

  3. In the Secondary Region, update the references to the project_id to match the ID from the Primary Region:

    # export PRIMARY_REGION_TENANT_ID="76ef6df109744a03b64ffaad2a7cf504"
# export SECONDARY_REGION_TENANT_ID="69c46f8ad1cf4a058aa76640985c"

# mariadb -e "UPDATE keystone.assignment set \
target_id='${PRIMARY_REGION_TENANT_ID}' \
WHERE target_id='${SECONDARY_REGION_TENANT_ID}';"

# mariadb -e "UPDATE keystone.user set \
default_project_id='${PRIMARY_REGION_TENANT_ID}' WHERE \
default_project_id='${SECONDARY_REGION_TENANT_ID}';"

# mariadb -e "UPDATE keystone.project set \
id='${PRIMARY_REGION_TENANT_ID}' WHERE \
id='${SECONDARY_REGION_TENANT_ID}';"

The user in the Secondary Region now has access to objects PUT in the Primary Region. The Secondary Region can PUT objects accessible by the user in the Primary Region.