Merge pull request #32730 from github/repo-sync

Repo sync

content/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding.md

@@ -0,0 +1,58 @@
+---
+title: Deferring database seeding
+intro: "You can speed up the process of adding a new MySQL replica node to your cluster by opting to defer database seeding."
+product: "{% data reusables.gated-features.cluster %}"
+versions:
+  ghes: '*'
+type: how_to
+topics:
+  - Clustering
+  - Enterprise
+---
+
+## About deferring database seeding of a MySQL replica node
+
+>[!NOTE]
+>The ability to defer database seeding{% ifversion ghes < 3.13 %} was added in patch release
+{%- ifversion ghes = 3.12 %} 3.12.1{%- endif %}
+{%- ifversion ghes = 3.11 %} 3.11.7{%- endif %}
+{%- ifversion ghes = 3.10 %} 3.10.10{%- endif %}
+{%- ifversion ghes = 3.9  %} 3.9.13{%- endif %} and{% endif %} is available as a public beta.
+
+Adding a new MySQL replica node to your cluster when your primary node has more than seven days of data will normally trigger database seeding which can take several hours depending on the amount of data. You can choose to defer database seeding, allowing the config apply run to complete sooner, resulting in being able to open your appliance to traffic sooner.
+
+You should only defer database seeding if you have already configured at least one MySQL replica, and you are adding an additional MySQL replica. Otherwise, there is no MySQL redundancy until the seeding is complete.
+
+When you defer database seeding, the new MySQL replica will not be configured for replication nor have a copy of the data on your MySQL primary node until seeding is manually completed later.
+
+## Configuring deferral of MySQL seeding when adding a new MySQL node
+
+{% data reusables.enterprise_clustering.replacing-a-cluster-node-provision %}
+{% data reusables.enterprise_clustering.replacing-a-cluster-node-admin-configure-ip %}
+1. Create the `cluster.conf` entry for the new MySQL node and include the `skip-data-setup = true` field. The example below adds a new node with the hostname `ghe-data-node-3` and the `mysql-server` role.
+
+    <pre>
+    ...
+    [cluster "ghe-data-node-3"]
+      hostname = ghe-data-node-3
+      ipv4 = 192.168.0.9
+      # ipv6 = fd12:3456:789a:1::7
+      mysql-server = true
+      <strong>skip-data-setup = true</strong>
+    ...
+    </pre>
+
+1. To initialize the new node in the cluster, from the administrative shell of the node with the modified `cluster.conf`, run `ghe-cluster-config-init`.
+1. To validate the configuration file, and also copy and configure each node according to the modified `cluster.conf` file, run `ghe-cluster-config-apply`.
+
+## Manually seeding the data
+
+Once you have run `ghe-cluster-config-apply`, the MySQL service will be running on your new node but will not be configured as a replica nor will it be seeded with data from the MySQL primary node. To seed data from the MySQL primary node, you will need to configure replication manually.
+
+1. From the new node, to start manual replication of the MySQL primary node data, run the following command, replacing `PRIMARY_IP` with the IP address of the node running the MySQL primary.
+
+    ```shell
+    /usr/local/share/enterprise/ghe-mysql-repl-start PRIMARY_IP
+    ```
+
+The time required for database seeding is dependent on the size of data. For large datasets, we recommend running the above command in a `screen` session to ensure it survives SSH disconnects.

content/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/index.md

@@ -18,6 +18,7 @@ children:
   - /about-cluster-nodes
   - /cluster-network-configuration
   - /initializing-the-cluster
+  - /deferring-database-seeding
   - /upgrading-a-cluster
   - /monitoring-the-health-of-your-cluster
   - /monitoring-the-health-of-your-cluster-nodes-with-node-eligibility-service

data/release-notes/enterprise-server/3-10/9.yml

@@ -64,7 +64,7 @@ sections:
     - |
       People deploying a GitHub Enterprise Server instance in AWS can now deploy in an environment that uses Instance Metadata Service Version 2 (IMDSv2).
     - |
-      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding.
+      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding. For more information, see "[AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding)."  
     - |
       The payload for the `push` webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see "[AUTOTITLE](/webhooks/webhook-events-and-payloads#push)" and "[AUTOTITLE](/rest/commits)."
   known_issues:

data/release-notes/enterprise-server/3-11/7.yml

@@ -60,7 +60,7 @@ sections:
     - |
       On an instance with a GitHub Advanced Security license, in some cases, when a user deleted a custom pattern for secret scanning, GitHub Enterprise Server failed to close or delete the patterns alerts.
     - |
-      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding.
+      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding. For more information, see "[AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding)."
     - |
       The payload for the `push` webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see "[AUTOTITLE](/webhooks/webhook-events-and-payloads#push)" and "[AUTOTITLE](/rest/commits)."
     - |

data/release-notes/enterprise-server/3-12/1.yml

@@ -88,8 +88,7 @@ sections:
     - |
       People deploying a GitHub Enterprise Server instance in AWS can now deploy in an environment that uses Instance Metadata Service Version 2 (IMDSv2).
     - |
-      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding.
-    - |
+      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding. For more information, see "[AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding)."
       Gists can be deleted using the **Purge Gist** button on the Deleted Gists page in Staff Tools.
     - |
       The payload for the `push` webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see "[AUTOTITLE](/webhooks/webhook-events-and-payloads#push)" and "[AUTOTITLE](/rest/commits)."

data/release-notes/enterprise-server/3-9/12.yml

@@ -59,8 +59,6 @@ sections:
       Gists can be deleted using the **Purge Gist** button on the Deleted Gists page in Staff Tools.
     - |
       People deploying a GitHub Enterprise Server instance in AWS can now deploy in an environment that uses Instance Metadata Service Version 2 (IMDSv2).
-    - |
-      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding.
     - |
       The payload for the `push` webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see "[AUTOTITLE](/webhooks/webhook-events-and-payloads#push)" and "[AUTOTITLE](/rest/commits)."
   known_issues:

data/release-notes/enterprise-server/3-9/13.yml

@@ -45,6 +45,8 @@ sections:
   changes:
     - |
       On an instance hosted on Azure, administrators can set and reset SSH keys and passwords via the Azure Agent.
+    - |
+      On an instance in a cluster configuration, MySQL replica nodes can be configured to skip database seeding. For more information, see "[AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding)."
     - |
       As a result of a security vulnerability, the editor role for a Management Console user has been deprecated. For details, see the "Security fixes" section of these release notes. Existing users with the editor role will be unable to log in to the Management Console, and should contact their site administrator requesting that access be reinstated by updating the user to the operator role if appropriate.
   known_issues:

data/reusables/enterprise_clustering/replacing-a-cluster-node-modify-cluster-conf.md

@@ -14,3 +14,5 @@
      metrics-server = true
      storage-server = true
    </pre>
+
+   You can choose to defer database seeding of a new MySQL replica node, resulting in being able to open your appliance to traffic sooner. For more information, see "[AUTOTITLE](/admin/monitoring-managing-and-updating-your-instance/configuring-clustering/deferring-database-seeding)."