You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For most deployments, installing official packages or a [binary tarball](tarball.md) is simpler than building from source. Use this procedure when you are packaging Percona XtraDB Cluster, applying custom patches, or developing the server.
4
+
5
+
The source code is on [GitHub :octicons-link-external-16:](https://github.com/percona/percona-xtradb-cluster).
5
6
Before you begin, make sure that the following packages are installed:
You may have already installed most of the packages. Run one of the following commands to install any missing
29
30
dependencies:
@@ -46,17 +47,13 @@ dependencies:
46
47
47
48
### glibc version
48
49
49
-
The glibc (GNU C Library) version can differ across software builds due to several key factors:
50
+
Binary tarballs (including the Percona XtraBackup archives you unpack below) embed a `glibc2.xx` segment in the filename; substitute the suffix from your downloaded file (for example `glibc2.28`), not the literal text `glibc2.xx`. Use archives built for a glibc that matches your build host, or the host where you will run the server. To see your system's GNU C Library version:
| Operating system variation | When you build software on different Linux distributions or versions, each may ship with a different default glibc version. For example, Red Hat Enterprise Linux or Ubuntu might have distinct system library versions that impact compilation. |
54
-
| Backward compatibility considerations | Some applications are compiled to support multiple glibc versions. <br> - Developers often create builds that can run on older systems. <br> - This means intentionally targeting a slightly older glibc version for wider compatibility. |
55
-
| System architecture differences | 32-bit and 64-bit systems might require different glibc implementations. <br> - ARM, x86, and other processor architectures can have unique library requirements. |
56
-
| Security and patch levels | Distributions backport security patches at different rates. <br> - A system's glibc version reflects its current security update status. <br> - Critical security updates can prompt version changes. |
57
-
| Compilation environment | The specific development environment and build tools used can directly influence which glibc version gets linked during compilation. Container environments, cross-compilation setups, and build servers might have unique library configurations. |
52
+
```shell
53
+
ldd --version
54
+
```
58
55
59
-
Practical Tip: Use `ldd --version` to check your current glibc version and understand potential compatibility constraints in your software ecosystem.
56
+
If you compile on one system and deploy on another, target the same architecture and a compatible glibc, or build on an environment that matches production.
60
57
61
58
## Compile
62
59
@@ -78,34 +75,48 @@ To compile Percona XtraDB Cluster from source code:
78
75
```
79
76
80
77
81
-
3. Download **both** Percona XtraBackup {{vers}} and Percona XtraBackup 8.0 tarballs (*.tar.gz) for your operating system from [Percona Software Downloads :octicons-link-external-16:](https://www.percona.com/downloads/).
78
+
3. Download both Percona XtraBackup {{vers}} and Percona XtraBackup 8.4 tarballs (*.tar.gz) for your operating system from [Percona Software Downloads :octicons-link-external-16:](https://www.percona.com/downloads/).
82
79
83
-
Both XtraBackup versions are required:
80
+
The source tree does not ship XtraBackup binaries; the build copies them from the directories you place under `pxc-build/pxc_extra`. You need two unpacked trees because the build script expects each in its own `pxb-*` subdirectory and the running server uses one tree for backup and restore tooling and the other for SST:
84
81
85
82
* Percona XtraBackup {{vers}} is used for backup and restore operations
86
-
* Percona XtraBackup 8.0 is required for State Snapshot Transfer (SST)
83
+
* Percona XtraBackup 8.4 is required for State Snapshot Transfer (SST)
84
+
85
+
The following commands use `Linux-x86_64`in the tarball names as an example. On ARM64, use the downloads whose filenames match your architecture (for example an `aarch64` or `arm64` build)—do not copy the example paths if they do not match the archives you fetched.
87
86
88
-
Extract the tarballs into the `pxc-build/pxc_extra` directory and ensure the directories are named exactly as shown below:
87
+
Extract the tarballs into the `pxc-build/pxc_extra` directory and ensure the directories are named exactly as shown below. In the commands, replace `glibc2.xx` with the glibc segment from each tarball's filename. Replace `8.4.x` with the version segment from the Percona XtraBackup 8.4 archive you downloaded (for example `8.4.0-3`). The `tar` and `mv` paths must match the top-level directory name produced when you unpack each file.
89
88
90
89
```shell
91
90
mkdir -p ./pxc-build/pxc_extra
92
91
93
92
tar -xvf percona-xtrabackup-{{vers}}-Linux-x86_64.glibc2.xx.tar.gz -C ./pxc-build
4. Run the build script `./build-ps/build-binary.sh`. By default, it attempts to build into the current directory. Specify the target output directory, such as `./pxc-build`:
101
100
102
101
```shell
103
-
mkdir ./pxc-build
102
+
mkdir -p ./pxc-build
104
103
./build-ps/build-binary.sh ./pxc-build
105
104
```
106
105
107
-
When the compilation completes, `pxc-build` contains a tarball, such as `Percona-XtraBackup-{{vers}}.tar.gz`, that you can deploy on your system.
106
+
When the compilation completes, `pxc-build` contains a tarball whose name follows the pattern `Percona-XtraDB-Cluster_<version-number>-Linux.x86_64.glibc2.xx.tar.gz` (minimal and full variants may both appear). Substitute `<version-number>` and `glibc2.xx` with the segments from the file the build produced.
108
107
109
108
!!! note
110
109
111
-
The exact version and release numbers may differ.
110
+
The exact version, glibc tag, and archive names may differ.
111
+
112
+
## Install and next steps
113
+
114
+
Treat the build output like the [binary tarball](tarball.md#install-from-binary-tarball) described in that topic: full and minimal archives contain binaries, libraries, and supporting files under one base directory (see the table there).
115
+
116
+
1. Unpack the archive on each node to the path you will use as the server installation directory.
117
+
2. Install the OS packages required at runtime (see the Debian or Ubuntu and Red Hat sections in [Install from Binary Tarball](tarball.md)).
118
+
3. Create a data directory and a MySQL option file. Set `basedir` and `datadir` (and related paths) to match your layout, and add [cluster and Galera options](configure-nodes.md#configure-nodes-for-write-set-replication) for your environment.
119
+
4. Initialize the data directory before the first server start (for example run `bin/mysqld --initialize` from the unpacked tree, following your security and file-ownership conventions).
120
+
5. Bring the cluster online: [bootstrap the first node](bootstrap.md#bootstrap-the-first-node), then [add the other nodes](add-node.md#add-nodes-to-cluster).
121
+
122
+
Examples in the manual often assume packages under `/usr` and `systemctl`. With a tarball or a tree you built yourself, paths and service units differ, but the same `wsrep` configuration and bootstrap order apply. For an overview of the full flow, see [Get started with Percona XtraDB Cluster](get-started-cluster.md#get-started-with-percona-xtradb-cluster) and [Install Percona XtraDB Cluster](install-index.md#install-percona-xtradb-cluster).
0 commit comments