This is interesting @z_painter 🤔

I can see in the brand new 18.10 docs, there is a section where the -u registry is used: https://docs.gitlab.com/administration/packages/container_registry_metadata_database/#check-the-health-of-online-garbage-collection

Those are all for running gitlab-ctl commands as the registry user when the DB is internal.

There is a note in the configuration steps section that says:

When using an external database, omit the -u registry option from the commands throughout this documentation.

So I feel like this setting will change depending on whether the DB is internal or external and also what username the DB is configured with?

Let's ask one of the engineers from the container registry team?

@jaime could you help please?

@luciezhao, @tmike and I had an internal conversation around this based on questions from a customer (ZD - internal).

I used DAP to generate this docs MR and it looks solid to me but could you please ask a Geo Engineer to review as well?

What does this MR do?

This MR adds critical documentation warnings about the risk of data loss when promoting a Geo secondary site that has selective synchronization enabled.

When selective synchronization is configured on a secondary site, only a subset of data is replicated (specific groups, shards, or organizations). Currently:

1. There is no validation in the promotion code (ee/lib/gitlab/geo/geo_tasks.rb) to check if selective sync is enabled
2. There is no warning in the documentation about the permanent data loss that occurs when promoting such a secondary
3. Administrators may unknowingly promote a secondary with selective sync, resulting in permanent loss of all non-replicated data

This MR adds:

1. A new section in doc/administration/geo/replication/selective_synchronization.md titled "Promoting a secondary site with selective synchronization enabled" that:
   • Clearly warns about permanent data loss
   • Explains what data will be lost
   • Provides recommendations for safe promotion
   • Offers guidance for emergency scenarios

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Alvin Gounder (529b5909) at 18 Mar 03:12

What does this MR do?

This change adds a helpful instruction on how to connect to the registry metadata database in the documentation section for monitoring GitLab's container registry.

Related issues

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Alvin Gounder (f60d8942) at 17 Mar 08:12

Add new workflow for investigating DB perf issues (gitlab-com/content-sites/handbook!18764 - merged) has been merged 🎉

Will ask for feedback from colleagues and iterate...

Alvin Gounder (302b5a67) at 17 Mar 05:35

Alvin Gounder (c61c3bf6) at 17 Mar 05:35

... and 1 more commit

Why is this change being made?

From RFC: Process for Cross-Referencing Self-Managed Performance Issues with GitLab.com and GitLab Dedicated:

When customers report performance issues on self-managed instances, Support Engineers often investigate these issues in isolation without checking if similar problems have been identified or resolved in GitLab.com or GitLab Dedicated environments.

This workflow will help to investigate and drive resolution of database-related performance issues reported by customers through collaboration with Engineering teams.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

• Add new workflow for investigating DB perf issues

---

Alvin Gounder (302b5a67) at 17 Mar 04:40

Alvin Gounder (d938b560) at 17 Mar 03:58

Alvin Gounder (88c8aea1) at 17 Mar 03:08

This workflow MR is related to this RFC: gitlab-com/support/support-team-meta#7411