Percona XtraDB Cluster 5.6官方文档：高可用与多主复制指南

需积分: 0 17 浏览量更新于2024-07-20 收藏 1.31MB PDF 举报

Percona-XtraDBCluster-5.6 是一款由 Percona LLC 及其关联公司开发的 MySQL 兼容数据库集群解决方案，适用于高可用性和多主复制场景。该版本于2016年6月10日发布，包含了详细的文档内容，如安装指南、功能特性、用户手册以及实用操作技巧。在1.1节中，关于Percona XtraDB Cluster的介绍，它强调了该集群的高可用性设计，能够提供数据冗余和故障转移的能力，确保在节点故障时仍能维持服务。1.2节列出了其局限性，可能包括特定的硬件或软件兼容性要求，以及与MySQL社区版相比可能存在的差异。安装部分详述了两种主要方式：从预编译二进制包安装（2.1节）和从源代码编译安装（2.2节），后者适合对定制化需求较高的用户。2.3节还提供了从5.5版本升级到5.6版本的指导，以便用户逐步迁移至新版本。在核心功能方面，3.1节深入解析了高可用性技术，包括如何配置和管理多个节点以实现数据复制和故障恢复。3.2节介绍了多主复制机制，即多个节点可以同时处理读写请求，增强了系统的并发性能和可扩展性。用户手册从4.1开始，涉及集群的初始化（bootstrapping），包括状态快照传输（State Snapshot Transfer）和Percona XtraBackup的配置。4.2至4.4章节分别讲解了重启集群节点、故障转移（Cluster Failover）以及监控集群的健康状况。此外，4.7节提到了Percona XtraDBCluster的认证管理和安全性，4.8节则深入解析了其线程模型，帮助用户优化资源利用。 5.1至5.4节是实用操作指南，包括在CentOS和Ubuntu上安装的步骤，以及如何在一个物理机上搭建3节点集群的详细过程，这些都是实际部署和维护中非常重要的内容。 Percona-XtraDBCluster-5.6是一个功能强大且实用的数据库集群解决方案，不仅关注性能提升，还注重易用性和故障恢复能力。用户可以根据这些文档快速上手，并根据具体需求进行定制和调整。

Percona XtraDB Cluster Documentation, Release 5.6.30-25.16

$ cd percona-xtradb-cluster

$ git clone https://github.com/percona/galera percona-xtradb-cluster-galera

Note: The directory for Galera repository must be named percona-xtradb-cluster-galera.

3. Run the build script ./build-ps/build-binary.sh. By default, it will build into the current directory,

but you can specify another target output directory. For example, if you want to build into ./pxc-build, run

the following:

$ mkdir ./pxc-build

$ ./build-ps/build-binary.sh ./pxc-build

2.3 Percona XtraDB Cluster In-Place Upgrading Guide: From 5.5 to

5.6

Warning:

• Some variables (possibly deprecated) in PS 5.5 may have been removed in PS 5.6 (hence in PXC 5.6), please

check that the variable is still valid before upgrade.

• Also, make sure to avoid SST during upgrade since a SST between nodes with 5.5 and 5.6 may not

work as expected (especially, if 5.5 is donor and 5.6 is joiner, mysql_upgrade will be required on joiner;

vice-versa, package upgrade will be required on joiner). You can also avoid automatic SST for the du-

ration of upgrade by setting ‘wsrep-sst-method‘ to ‘skip’ for the duration of upgrade. (Note that

‘wsrep-sst-method‘ is a dynamic variable.) Having a large enough gcache helps here. Also, setting

it to skip ensures that you can handle SST manually if and when required.

Upgrading cluster involves following major stages:

1. Upgrade a single node.

2. Upgrade the whole cluster while not breaking replication.

3. [Optional] Restarting nodes with non-compat options.

Note: Following upgrade process is for a rolling upgrade, ie. an upgrade without downtime for the cluster. If you

intend to allow for downtime - bring down all nodes, upgrade them, bootstrap and start nodes - then you can just follow

Stage I sans the compatibility variables part. Make sure to bootstrap the ﬁrst node in the cluster after upgrade.

2.3.1 Following is the upgrade process on CentOS 6.4

Step #1 Make sure all the nodes in cluster are upgraded to the latest 5.5 version and are in synced state.

Stage I

Assuming we are going to upgrade node A, (and other nodes B and C are on 5.5)

Step #2 On node A stop the mysql process and remove the old packages:

# service mysql stop

# yum remove ’Percona

’

12 Chapter 2. Installation

Percona XtraDB Cluster Documentation, Release 5.6.30-25.16

Step #3 Install the new packages:

# yum install Percona-XtraDB-Cluster-56

Note: For more details on installation, refer to Installing Percona XtraDB Cluster from Binaries guide. You may also

want to install Percona-XtraDB-Cluster-full-56 which installs other ancillary packages like ‘-shared-56’, ‘-test-56’,

debuginfos and so on.

Step #4 Fix the variables in the MySQL conﬁguration ﬁle my.cnf which are not compatible with Percona Server 5.6.

Detailed list can be checked in Changed in Percona Server 5.6 documentation. In case you are not sure after this, you

can also do following:

# mysqld --user=mysql --wsrep-provider=’none’

If there are any invalid variables, it will print it there without affect galera grastate or any other things.

Note: It may also be worthwhile to backup the grastate.dat to use it if it gets zeroed (or sequence number to -1)

accidentally (or due to network issues) since this can avoid SST.

Step #5 Add the following to my.cnf for compatibility with 5.5 replication for the duration of upgrade, and set the

following options:

# Required for compatibility with galera-2

# Append socket.checksum=1 to other options if others are in wsrep_provider_options. Eg.: "gmcast.listen_addr=tcp://127.0.0.1:15010; socket.checksum=1"

wsrep_provider_options="socket.checksum=1"

# Required for replication compatibility

log_bin_use_v1_row_events=1

avoid_temporal_upgrade=ON # Available in 5.6.24 and up

gtid_mode=0

binlog_checksum=NONE

# Required under certain conditions

read_only=ON

Step #5.1 “read_only=ON” is required only when the tables you have contain timestamp/datetime/time data types as

those data types are incompatible across replication from higher version to lower. This is currently a limitation of

mysql itself. Also, refer to Replication compatibility guide. Any DDLs during migration are not recommended for the

same reason.

Note: read_only does not apply to root connections (as per mysql speciﬁcations).

Step #5.2 To ensure 5.6 read-only nodes are not written to during migration, clustercheck (usually used with xinetd

and HAProxy) distributed with PXC has been modiﬁed to return 503 when the node is read-only so that HAProxy

doesn’t send writes to it. Refer to clustercheck script for more details. Instead, you can also opt for read-write splitting

at load-balancer/proxy level or at application level.

Note: On the last 5.5 node to upgrade to 5.6, the compatibility options of Step #5 are not required since all other

nodes will already be upgrade and their compat. options are compatible with a 5.6 node without them.

Step #6 Next, start the node with the variable wsrep_provider set to none:

# mysqld --skip-grant-tables --user=mysql --wsrep-provider=’none’

This is to ensure that other hosts are not affected by this upgrade (hence provider is none here).

Step #7 While Step #5 is running, in the background or in another session run:

2.3. Percona XtraDB Cluster In-Place Upgrading Guide: From 5.5 to 5.6 13

Percona XtraDB Cluster Documentation, Release 5.6.30-25.16

# mysql_upgrade

Other options like socket, user, pass may need to provided here if not defined in my.cnf.

Step #8 Step #7 must complete successfully, upon which, process started in Step #6 can be stopped/killed.

Step #9 If all the steps above have completed successfully node can be started with:

# service mysql start

Note: If this is the ﬁrst node of cluster, then replace start with bootstrap-pxc. This shouldn’t apply to rolling

upgrade in general (since other nodes are up during this) but only for downtime-based upgrades (where you bring up

nodes one by one).

Step #10 At this point, other nodes (B, C) should acknowledge that this node is up and synced!

Stage II

Step #11 After this has been set up all 5.5 nodes can be upgraded, one-by-one, as described in the Stage I.

1. If read_only was turned on in Step #5.1, then after all nodes in the cluster are upgraded to 5.6 or equivalently,

after the last 5.5 has been take down for upgrade, option read_only can be set to OFF (since this is a dynamic

variable, it can done without restart).

2. If read-write splitting was done in applications and/or in load-balancer then in previous step, instead of

read_only, writes need to be directed to 5.6 nodes.

Stage III [Optional]

Step #12 This step is required to turn off the options added in #Step 5. Note, that this step is not required imme-

diately after upgrade and can be done at a latter stage. The aim here is to turn off the compatibility options for

performance reasons (only socket.checksum=1 ﬁts this). This requires restart of each node. Hence, following can be

removed/commented-out:

# Remove socket.checksum=1 from other options if others are in wsrep_provider_options. Eg.: "gmcast.listen_addr=tcp://127.0.0.1:15010"

# Removing this makes socket.checksum=2 which uses hardware accelerated CRC32 checksumming.

wsrep_provider_options="socket.checksum=1"

# Options added for replication compatibility, being removed here.

# You can keep some of these if you wish.

log_bin_use_v1_row_events=1

avoid_temporal_upgrade=ON # Available in 5.6.24 and up

# You can keep if you are not adding async-slaves.

# Apropos, you may need to enable this if you are adding async-slaves, refer to MySQL 5.6 gtid_mode documentation for more details on this variable.

gtid_mode=0

# Galera already has full writeset checksumming, so

# you can keep this if async-slaves are not there and

# binlogging is not turned on.

binlog_checksum=NONE

# Remove it from cnf even though it was turned off at runtime in Step #11.

read_only=ON

14 Chapter 2. Installation

Percona XtraDB Cluster Documentation, Release 5.6.30-25.16

2.3.2 Following is the upgrade process on Ubuntu 12.04 (precise)

Step #1 Make sure all the nodes in cluster are upgraded to the latest 5.5 version and are in synced state.

Stage I

Assuming we are going to upgrade node A, (and other nodes B and C are on 5.5)

Step #2 On node A stop the mysql process and remove the old packages:

# /etc/init.d/mysql stop

# apt-get remove percona-xtradb-cluster-server-5.5 percona-xtradb-cluster-galera-2.x percona-xtradb-cluster-common-5.5 percona-xtradb-cluster-client-5.5

Step #3 Fix the variables in the MySQL conﬁguration ﬁle my.cnf which are not compatible with Percona

Server 5.6. Detailed list can be checked in Changed in Percona Server 5.6 documentation. Add the following

to my.cnf for compatibility with 5.5 replication for the duration of upgrade, add ‘socket.checksum=1’ to the

wsrep_provider_options variable and set wsrep_provider set to none

# Required for compatibility with galera-2

# Append socket.checksum=1 to other options if others are in wsrep_provider_options. Eg.: "gmcast.listen_addr=tcp://127.0.0.1:15010; socket.checksum=1"

wsrep_provider_options="socket.checksum=1"

# Required for replication compatibility

log_bin_use_v1_row_events=1

avoid_temporal_upgrade=ON # Available in 5.6.24 and up

gtid_mode=0

binlog_checksum=NONE

# Required under certain conditions

read_only=ON

wsrep_provider=none

Step #3.1 “read_only=ON” is required only when the tables you have contain timestamp/datetime/time data types as

those data types are incompatible across replication from higher version to lower. This is currently a limitation of

mysql itself. Also, refer to Replication compatibility guide. Any DDLs during migration are not recommended for the

same reason.

Note: read_only does not apply to root connections (as per mysql speciﬁcations).

Step #3.2 To ensure 5.6 read-only nodes are not written to during migration, clustercheck (usually used with xinetd

and HAProxy) distributed with PXC has been modiﬁed to return 503 when the node is read-only so that HAProxy

doesn’t send writes to it. Refer to clustercheck script for more details. Instead, you can also opt for read-write splitting

at load-balancer/proxy level or at application level.

Note: It may also be worthwhile to backup the grastate.dat to use it if it gets zeroed (or sequence number to -1)

accidentally (or due to network issues).

Note: On the last 5.5 node to upgrade to 5.6, the compatibility options of Step #3 are not required since all other

nodes will already be upgrade and their conﬁguration options are compatible with a 5.6 node without them.

Step #4 Install the new packages:

# apt-get install percona-xtradb-cluster-56

Note: For more details on installation, refer to Installing Percona XtraDB Cluster from Binaries guide. You may

2.3. Percona XtraDB Cluster In-Place Upgrading Guide: From 5.5 to 5.6 15

Percona XtraDB Cluster Documentation, Release 5.6.30-25.16

also want to install percona-xtradb-cluster-full-56 which installs other ancillary packages like ‘-shared-56’, ‘-test-56’,

debuginfos and so on.

Step #5 After node has been started you’ll need to run mysql_upgrade:

# mysql_upgrade

Other options like socket, user, pass may need to provided here if not defined in my.cnf.

Step #6 If all the steps above have completed successfully, shutdown the server, set the wsrep_provider to the

location of the Galera library (from ‘none’ to something like /usr/lib/libgalera_smm.so) in my.cnf, and node can be

started with:

# service mysql start

Note: If this is the ﬁrst node of cluster, then replace start with bootstrap-pxc. This shouldn’t apply to rolling

upgrade in general (since other nodes are up during this) but only for downtime-based upgrades (where you bring up

nodes one by one).

Step #7 At this point, other nodes (B, C) should acknowledge that this node is up and synced!

Stage II

Step #8 After this has been set up all 5.5 nodes can be upgraded, one-by-one, as described in the Stage I.

1. If read_only was turned on in Step #3.1, then after all nodes in the cluster are upgraded to 5.6 or equivalently,

after the last 5.5 has been take down for upgrade, option read_only can be set to OFF (since this is a dynamic

variable, it can done without restart).

2. If read-write splitting was done in applications and/or in load-balancer then in previous step, instead of

read_only, writes need to be directed to 5.6 nodes.

Stage III [Optional]

Step #9 This step is required to turn off the options added in #Step 3. Note, that this step is not required imme-

diately after upgrade and can be done at a latter stage. The aim here is to turn off the compatibility options for

performance reasons (only socket.checksum=1 ﬁts this). This requires restart of each node. Hence, following can be

removed/commented-out:

# Remove socket.checksum=1 from other options if others are in wsrep_provider_options. Eg.: "gmcast.listen_addr=tcp://127.0.0.1:15010"

# Removing this makes socket.checksum=2 which uses hardware accelerated CRC32 checksumming.

wsrep_provider_options="socket.checksum=1"

# Options added for replication compatibility, being removed here.

# You can keep some of these if you wish.

log_bin_use_v1_row_events=1

avoid_temporal_upgrade=ON # Available in 5.6.24 and up

# You can keep if you are not adding async-slaves.

# Apropos, you may need to enable this if you are adding async-slaves, refer to MySQL 5.6 gtid_mode documentation for more details on this variable.

gtid_mode=0

# Galera already has full writeset checksumming, so

# you can keep this if async-slaves are not there and

# binlogging is not turned on.

16 Chapter 2. Installation

剩余130页未读，继续阅读

tiancaifjx

粉丝: 7
资源: 3

Percona XtraDB Cluster 5.6官方文档：高可用与多主复制指南

MySQL DBA Percona Xtradb Cluster安装

安装Percona-XtraDB-Cluster软件包时报错file /usr/bin/mysql from install of Percona-XtraDB-Cluster-client-57-5.7.25-31.35.1.el7.x86_64 conflicts with file from package mysql-community-client-5.7.17-1.el7.x86_64

如何通过二进制文件安装percona-xtradb-cluster5.7.40

centos7安装percona-xtrabackup

Package percona-xtrabackup is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'percona-xtrabackup' has no installation candidate

percona-xtrabackup-2.4.28 源码安装到centos6.7，请给出详细步骤。注意：该机器已经安装了xtrabackup8.0版本，希望能够版本共存。

ubuntu16.04 percona-toolkit安装

E: Package 'percona-xtrabackup' has no installation candidate

percona-toolkit-3.0.12-1.el7.x86_64.rpm

最新资源