MySQL之PXC集群搭建的方法步骤

一、PXC 介绍

1.1 PXC 简介

PXC是一套 MySQL 高可用集群解决方案,与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。PXC 最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证 MySQL 集群的数据一致性;

1.2 PXC特性和优点

  • 完全兼容 MySQL。
  • 同步复制,事务要么在所有节点提交或不提交。
  • 多主复制,可以在任意节点进行写操作。
  • 在从服务器上并行应用事件,真正意义上的并行复制。
  • 节点自动配置,数据一致性,不再是异步复制。
  • 故障切换:因为支持多点写入,所以在出现数据库故障时可以很容易的进行故障切换。
  • 自动节点克隆:在新增节点或停机维护时,增量数据或基础数据不需要人工手动备份提供,galera cluster会自动拉取在线节点数据,集群最终会变为一致;

PXC最大的优势:强一致性、无同步延迟

1.3 PXC的局限和劣势

  • 复制只支持InnoDB 引擎,其他存储引擎的更改不复制
  • 写入效率取决于节点中最慢的一台

1.4 PXC与Replication的区别

Replication PXC
数据同步是单向的,master负责写,然后异步复制给slave;如果slave写入数据,不会复制给master。 数据同步时双向的,任何一个mysql节点写入数据,都会同步到集群中其它的节点。
异步复制,从和主无法保证数据的一致性 同步复制,事务在所有集群节点要么同时提交,要么同时不提交

1.5 PXC 常用端口

  • 3306:数据库对外服务的端口号。
  • 4444:请求SST的端口。
  • 4567:组成员之间进行沟通的一个端口号
  • 4568:用于传输IST。

名词解释:

  • SST(State Snapshot Transfer): 全量传输
  • IST(Incremental state Transfer):增量传输

二、实践

2.1 搭建 PXC 集群

与 MySQL 不同的是 PXC 官方提供了 Docker 镜像,所以我们可以很方便的搭建 PXC 集群。

1)下载 Docker 镜像

docker pull percona/percona-xtradb-cluster:5.7

重命名镜像名称

docker tag percona/percona-xtradb-cluster:5.7 pxc:5.7

3)删除原始镜像

docker rmi percona/percona-xtradb-cluster:5.7

创建 Docker 网络,用于 PXC 集群独立使用

docker network create pxc-network

创建数据卷用于之后挂载

docker volume create --name v1
docker volume create --name v2
docker volume create --name v3

注:PXC容器只支持数据卷挂载方式,不支持目录挂载

创建第一个节点

docker run -di --name=pn1 --net=pxc-network -p 9000:3306 -v v1:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456 -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456  pxc:5.7

因为后续节点的添加需要关联到第一个节点,所以需要等待数据库启动完成。通过 docker logs pn1 查看日志,如果出现下面的输出,证明启动成功:

2019-09-04T06:27:30.085880Z 0 [Note] InnoDB: Buffer pool(s) load completed at 190904  6:27:30

注:CLUSTER_NAME 名称不要用关键字PXC,否则无法启动。

加入第二个节点

docker run -di --name=pn2 --net=pxc-network -p 9001:3306 -v v2:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn1 pxc:5.7

需要注意是第二个节点开始需要增加 e CLUSTER_JOIN=pn1 参数,表示与 pn1 节点同步,否则 pn1 容器会自动关闭。

当 PXC集群中存在两个节点以上之后就没有主节点的概念了。集群中最后一个退出的节点就会变为主节点,在 /var/lib/mysql/grastate.dat 文件中属性 safe_to_bootstrap 的值 会从 0 被设置为 1 表示该节点是主节点。

8)加入第三个节点

docker run -di --name=pn3 --net=pxc-network -p 9002:3306 -v v3:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn2 pxc:5.7

可以看到我们这次我们 CLUSTER_JOIN 的是 pn2 容器,可以证明我们刚刚说的 当 PXC 集群存在两个节点以上之后就没有主节点的概念了 这个说法是正确的。

9)进入 pn1 节点

docker exec -it pn1 /usr/bin/mysql -uroot -p123456

查看状态

mysql> show status like 'wsrep%';
+----------------------------------+-------------------------------------------------+
| Variable_name                    | Value                                           |
+----------------------------------+-------------------------------------------------+
| wsrep_local_state_uuid           | 068dd5e8-cedd-11e9-904d-466e75bd8fe1            |
| wsrep_protocol_version           | 9                                               |
| wsrep_last_applied               | 16                                              |
| wsrep_last_committed             | 16                                              |
| wsrep_replicated                 | 0                                               |
| wsrep_replicated_bytes           | 0                                               |
| wsrep_repl_keys                  | 0                                               |
| wsrep_repl_keys_bytes            | 0                                               |
| wsrep_repl_data_bytes            | 0                                               |
| wsrep_repl_other_bytes           | 0                                               |
| wsrep_received                   | 10                                              |
| wsrep_received_bytes             | 800                                             |
| wsrep_local_commits              | 0                                               |
| wsrep_local_cert_failures        | 0                                               |
| wsrep_local_replays              | 0                                               |
| wsrep_local_send_queue           | 0                                               |
| wsrep_local_send_queue_max       | 1                                               |
| wsrep_local_send_queue_min       | 0                                               |
| wsrep_local_send_queue_avg       | 0.000000                                        |
| wsrep_local_recv_queue           | 0                                               |
| wsrep_local_recv_queue_max       | 2                                               |
| wsrep_local_recv_queue_min       | 0                                               |
| wsrep_local_recv_queue_avg       | 0.100000                                        |
| wsrep_local_cached_downto        | 0                                               |
| wsrep_flow_control_paused_ns     | 0                                               |
| wsrep_flow_control_paused        | 0.000000                                        |
| wsrep_flow_control_sent          | 0                                               |
| wsrep_flow_control_recv          | 0                                               |
| wsrep_flow_control_interval      | [ 173, 173 ]                                    |
| wsrep_flow_control_interval_low  | 173                                             |
| wsrep_flow_control_interval_high | 173                                             |
| wsrep_flow_control_status        | OFF                                             |
| wsrep_cert_deps_distance         | 0.000000                                        |
| wsrep_apply_oooe                 | 0.000000                                        |
| wsrep_apply_oool                 | 0.000000                                        |
| wsrep_apply_window               | 0.000000                                        |
| wsrep_commit_oooe                | 0.000000                                        |
| wsrep_commit_oool                | 0.000000                                        |
| wsrep_commit_window              | 0.000000                                        |
| wsrep_local_state                | 4                                               |
| wsrep_local_state_comment        | Synced                                          |
| wsrep_cert_index_size            | 0                                               |
| wsrep_cert_bucket_count          | 22                                              |
| wsrep_gcache_pool_size           | 1592                                            |
| wsrep_causal_reads               | 0                                               |
| wsrep_cert_interval              | 0.000000                                        |
| wsrep_open_transactions          | 0                                               |
| wsrep_open_connections           | 0                                               |
| wsrep_ist_receive_status         |                                                 |
| wsrep_ist_receive_seqno_start    | 0                                               |
| wsrep_ist_receive_seqno_current  | 0                                               |
| wsrep_ist_receive_seqno_end      | 0                                               |
| wsrep_incoming_addresses         | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306|
| wsrep_cluster_weight             | 3                                               |
| wsrep_desync_count               | 0                                               |
| wsrep_evs_delayed                |                                                 |
| wsrep_evs_evict_list             |                                                 |
| wsrep_evs_repl_latency           | 0/0/0/0/0                                       |
| wsrep_evs_state                  | OPERATIONAL                                     |
| wsrep_gcomm_uuid                 | 11ed51e2-cedd-11e9-b362-af453a7ac074            |
| wsrep_cluster_conf_id            | 3                                               |
| wsrep_cluster_size               | 3                                               |
| wsrep_cluster_state_uuid         | 068dd5e8-cedd-11e9-904d-466e75bd8fe1            |
| wsrep_cluster_status             | Primary                                         |
| wsrep_connected                  | ON                                              |
| wsrep_local_bf_aborts            | 0                                               |
| wsrep_local_index                | 0                                               |
| wsrep_provider_name              | Galera                                          |
| wsrep_provider_vendor            | Codership Oy <info@codership.com>               |
| wsrep_provider_version           | 3.37(rff05089)                                  |
| wsrep_ready                      | ON                                              |
+----------------------------------+-------------------------------------------------+
71 rows in set (0.06 sec)

可以看到 wsrep_incoming_addresses 的值就是我们三个容器的IP地址

| wsrep_incoming_addresses         | 172.19.0.2:3306,172.19.0.3:3306,172.19.0.4:3306 |

集群完整性检查:

属性 含义
wsrep_cluster_state_uuid 在集群所有节点的值应该是相同的,有不同值的节点,说明其没有连接入集群.
wsrep_cluster_conf_id 正常情况下所有节点上该值是一样的.如果值不同,说明该节点被临时”分区”了.当节点之间网络连接恢复 的时候应该会恢复一样的值.
wsrep_cluster_size 如果这个值跟预期的节点数一致,则所有的集群节点已经连接.
wsrep_cluster_status 集群组成的状态.如果不为”Primary”,说明出现”分区”或是”split-brain”脑裂状况.

节点状态检查:

属性 含义
wsrep_ready 该值为 ON,则说明可以接受 SQL 负载.如果为 Off,则需要检查 wsrep_connected
wsrep_connected 如果该值为 Off,且 wsrep_ready 的值也为 Off,则说明该节点没有连接到集群.(可能是 wsrep_cluster_address 或 wsrep_cluster_name 等配置错造成的.具体错误需要查看错误日志)
wsrep_local_state_comment 如果 wsrep_connected 为 On,但 wsrep_ready 为 OFF,则可以从该项查看原因

复制健康检查:

属性 含义
wsrep_flow_control_paused 表示复制停止了多长时间.即表明集群因为 Slave 延迟而慢的程度.值为 0~1,越靠近 0 越好,值为 1 表示 复制完全停止.可优化 wsrep_slave_threads 的值来改善
wsrep_cert_deps_distance 有多少事务可以并行应用处理.wsrep_slave_threads 设置的值不应该高出该值太多
wsrep_flow_control_sent 表示该节点已经停止复制了多少次
*wsrep_local_recv_queue_avg 表示 slave 事务队列的平均长度.slave 瓶颈的预兆. 最慢的节点的 wsrep_flow_control_sent 和 wsrep_local_recv_queue_avg 这两个值最高.这两个值较低的话,相对更好

检测慢网络问题:

属性 含义
wsrep_local_send_queue_avg 网络瓶颈的预兆.如果这个值比较高的话,可能存在网络瓶颈

冲突或死锁的数目:

属性 含义
wsrep_last_committed 最后提交的事务数目
wsrep_local_cert_failures 和 wsrep_local_bf_aborts 回滚,检测到的冲突数目

2.2 集群同步验证

在节点一上创建数据库 test

mysql> create database test;
Query OK, 1 row affected (0.02 sec)

节点二上查看:

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.00 sec)

在节点二上创建表

mysql> use test;
Database changed
mysql> create table sys_user(id int ,name varchar(30));
Query OK, 0 rows affected (0.11 sec)

4)在节点三上查看表结构

mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| sys_user       |
+----------------+
1 row in set (0.00 sec)

在节点三上插入数据

mysql> insert into sys_user values(1,'a');
ERROR 1105 (HY000): Percona-XtraDB-Cluster prohibits use of DML command on a table (test.sys_user) without an explicit primary key with pxc_strict_mode = ENFORCING or MASTER

看到没有显示的主键就无法插入数据,我们修改下表结构:

alter table sys_user add primary key (id);

插入数据:

mysql> insert into sys_user values(1,'a');
Query OK, 1 row affected (0.05 sec)

6)在节点一查看表数据

mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)

可以看到三个节点数据正常同步,并且都可读可写。

2.3 新增数据库节点操作

当数据库不够用时,我们通常需要增加数据库节点来分担压力,我们来演示一下新增节点的操作。

创建数据卷

docker volume create --name v4

2)新增容器

docker run -di --name=pn4 --net=pxc-network -p 9003:3306 -v v4:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn3 pxc:5.7

要注意的是,这次 CLUSTER_JOIN 连的是 pn3。

进入节点4查看数据

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| test               |
+--------------------+
5 rows in set (0.00 sec)
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+----------------+
| Tables_in_test |
+----------------+
| sys_user       |
+----------------+
1 row in set (0.00 sec)
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | a    |
+----+------+
1 row in set (0.00 sec)

可以看到之前的数据也自动同步过来了。

2.4 宕机操作

将节点pn4容器关闭,造成宕机现象

docker stop pn4

在节点 pn2 上做查看集群状态

mysql> show status like 'wsrep%';
......
| wsrep_local_state                | 4                                               |
| wsrep_local_state_comment        | Synced                                          |
| wsrep_cert_index_size            | 3                                               |
......
| wsrep_incoming_addresses         | 172.19.0.4:3306,172.19.0.3:3306,172.19.0.2:3306 |

可以看到集群应该有4个节点,但是现在只有3个正常连接。

3)在节点 pn2 上做修改操作

mysql> update sys_user set name='b' where id=1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

将节点 pn4 容器启动

[root@VM_0_15_centos ~]# docker start pn4

进入容器 pn4 查看修改操作是否同步

docker exec -it pn4 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
+----+------+
1 row in set (0.00 sec)

可以看到节点正常加入集群,并且数据也同步了。

pn4 是以指定主节点形式进入 PXC 集群创建的容器,那么 pn1直接以自身为主节点启动的容器会怎么样呢?我们来演示一下:

关闭 pn1 节点

docker stop pn1

在 pn2 节点上插入一条数据

mysql> insert into sys_user values('2','c');
Query OK, 1 row affected (0.01 sec)

启动 pn1节点

docker start pn1

等待一分钟,查看容器启动列表

docker ps -a

发现 pn1 节点并没有启动

CONTAINER ID        IMAGE    ......   STATUS                           NAMES
fa123563e787        pxc:5.7  ......   Exited (1) About a minute ago    pn1

查看下错误日志:

docker logs pn1

异常信息如下:

2019-09-04T07:21:56.412918Z 0 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .
2019-09-04T07:21:56.412922Z 0 [ERROR] WSREP: Provider/Node (gcomm://) failed to establish connection with cluster (reason: 7)
2019-09-04T07:21:56.412929Z 0 [ERROR] Aborting

翻译成中文:

2019-09-04T07:21:56.412918Z 0 [错误] WSREP:从此节点引导群集可能不安全。 它不是离开群集的最后一个,可能不包含所有更新。 要使用此节点强制群集引导,请手动编辑grastate.dat文件并将safe_to_bootstrap设置为1。
2019-09-04T07:21:56.412922Z 0 [错误] WSREP:提供者/节点(gcomm://)无法与群集建立连接(原因:7)
2019-09-04T07:21:56.412929Z 0 [错误]中止

错误提示很明显了,因为 pn1 节点不是最后一个离开集群的不能再以主节点的形式启动了,如果要以主节点的形式启动必须调整 grastate.dat文件中的 safe_to_bootstrap 参数为 1。

但是要注意的是因为集群中其他节点并没有关闭,这样启动的容器跟之前的集群就没有关系了数据也不会同步,我们来验证下看看:

查看数据卷存放的路径

docker volume inspect v1
[
    {
        "CreatedAt": "2019-09-05T09:22:22+08:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/v1/_data",
        "Name": "v1",
        "Options": {},
        "Scope": "local"
    }
]

进入数据卷目录,查看是否存在 grastate.dat文件

[root@VM_0_15_centos ~]# cd /var/lib/docker/volumes/v1/_data
[root@VM_0_15_centos _data]# ll
total 323444
-rw-r----- 1 1001 1001        56 Sep  5 08:34 auto.cnf
-rw------- 1 1001 1001      1680 Sep  5 08:34 ca-key.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 ca.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 client-cert.pem
-rw------- 1 1001 1001      1676 Sep  5 08:34 client-key.pem
-rw-r----- 1 1001 1001         2 Sep  5 08:34 fa123563e787.pid
-rw-r----- 1 1001 1001 134219048 Sep  5 09:22 galera.cache
-rw-r----- 1 1001 1001       113 Sep  5 09:21 grastate.dat
-rw-r----- 1 1001 1001      1300 Sep  5 08:34 ib_buffer_pool
-rw-r----- 1 1001 1001  79691776 Sep  5 09:15 ibdata1
-rw-r----- 1 1001 1001  50331648 Sep  5 09:15 ib_logfile0
-rw-r----- 1 1001 1001  50331648 Sep  5 08:34 ib_logfile1
-rw-r----- 1 1001 1001  12582912 Sep  5 08:38 ibtmp1
-rw-r----- 1 1001 1001     34751 Sep  5 08:38 innobackup.backup.log
drwxr-x--- 2 1001 1001      4096 Sep  5 08:34 mysql
drwxr-x--- 2 1001 1001      4096 Sep  5 08:34 performance_schema
-rw------- 1 1001 1001      1676 Sep  5 08:34 private_key.pem
-rw-r--r-- 1 1001 1001       452 Sep  5 08:34 public_key.pem
-rw-r--r-- 1 1001 1001      1120 Sep  5 08:34 server-cert.pem
-rw------- 1 1001 1001      1676 Sep  5 08:34 server-key.pem
drwxr-x--- 2 1001 1001     12288 Sep  5 08:34 sys
drwxr-x--- 2 1001 1001      4096 Sep  5 09:07 test
-rw-r--r-- 1 1001 1001       143 Sep  5 09:22 version_info
-rw-r----- 1 1001 1001   3932160 Sep  5 09:15 xb_doublewrite

编辑文件

vim grastate.dat

将 safe_to_bootstrap 参数值修改为1,保存退出

# GALERA saved state
version: 2.1
uuid:    068dd5e8-cedd-11e9-904d-466e75bd8fe1
seqno:   20
safe_to_bootstrap: 1

重启 pn1 容器

docker start pn1

进入容器,查看数据

docker exec -it pn1 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
+----+------+
1 row in set (0.01 sec)

发现数据并没有同步,那么要怎么将 pn1 节点加入到集群中呢?

我们可以直接将 pn1 容器删除,以加入节点的形式重新创建容器,并且因为我们之前已经将容器的数据挂载到数据卷了,所以数据也不会存在丢失的风险,我们来操作下:

删除 pn1容器

docker stop pn1
docker rm pn1

以从节点方式加入集群

docker run -di --name=pn1 --net=pxc-network -p 9000:3306 -v v1:/var/lib/mysql --privileged -e MYSQL_ROOT_PASSWORD=123456  -e CLUSTER_NAME=cluster1 -e XTRABACKUP_PASSWORD=123456 -e CLUSTER_JOIN=pn2 pxc:5.7

等待容器初始化完毕

3)进入容器,查看数据是否同步

docker exec -it pn1 /usr/bin/mysql -uroot -p123456
mysql> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from sys_user;
+----+------+
| id | name |
+----+------+
|  1 | b    |
|  2 | c    |
+----+------+
2 rows in set (0.00 sec)

发现数据已经同步了。

到此这篇关于MySQL之PXC集群搭建的方法步骤的文章就介绍到这了,更多相关MySQL PXC集群搭建 内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • docker 搭建Mysql集群的方法示例

    docker基本指令: 更新软件包 yum -y update 安装Docker虚拟机(centos 7) yum install -y docker 运行.重启.关闭Docker虚拟机 service docker start service docker stop 搜索镜像 docker search 镜像名称 下载镜像 docker pull 镜像名称 查看镜像 docker images 删除镜像 docker rmi 镜像名称 运行容器 docker run 启动参数 镜像名称 查看容

  • 基于mysql+mycat搭建稳定高可用集群负载均衡主备复制读写分离操作

    数据库性能优化普遍采用集群方式,oracle集群软硬件投入昂贵,今天花了一天时间搭建基于mysql的集群环境. 主要思路 简单说,实现mysql主备复制-->利用mycat实现负载均衡. 比较了常用的读写分离方式,推荐mycat,社区活跃,性能稳定. 测试环境 MYSQL版本:Server version: 5.5.53,到官网可以下载WINDWOS安装包. 注意:确保mysql版本为5.5以后,以前版本主备同步配置方式不同. linux实现思路类似,修改my.cnf即可. A主mysql.19

  • 详解MySQL集群搭建

    概述 MySQL Cluster 是MySQL 适合于分布式计算环境的高实用.可拓展.高性能.高冗余版本,其研发设计的初衷就是要满足许多行业里的最严酷应用要求,这些应用中经常要求数据库运行的可靠性要达到99.999%.MySQL Cluster允许在无共享的系统中部署"内存中"数据库集群,通过无共享体系结构,系统能够使用廉价的硬件,而且对软硬件无特殊要求.此外,由于每个组件有自己的内存和磁盘,不存在单点故障. 实际上,MySQL集群是把一个叫做NDB的内存集群存储引擎集成与标准的MyS

  • MySQL之PXC集群搭建的方法步骤

    一.PXC 介绍 1.1 PXC 简介 PXC是一套 MySQL 高可用集群解决方案,与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步.而且节点与节点之间,他们相互的关系是对等的.PXC 最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证 MySQL 集群的数据一致性: 1.2 PXC特性和优点 完全兼容 MySQL. 同步复制,事务

  • docker实现redis集群搭建的方法步骤

    目录 一.创建redis docker基础镜像 二.制作redis节点镜像 三.运行redis集群 引用: 摘要:接触docker以来,似乎养成了一种习惯,安装什么应用软件都想往docker方向做,今天就想来尝试下使用docker搭建redis集群. 首先,我们需要理论知识:Redis Cluster是Redis的分布式解决方案,它解决了redis单机中心化的问题,分布式数据库--首要解决把整个数据集按照分区规则映射到多个节点的问题. 这边就需要知道分区规则--哈希分区规则.Redis Clus

  • Redis的Cluster集群搭建的实现步骤

    目录 一.引言 二.Redis的Cluster模式介绍 1.Redis群集101 2.Redis群集TCP端口 3.Redis集群和Docker 4.Redis集群数据分片 5.Redis集群之主从模型 6.Redis集群一致性保证 7.Redis群集配置参数 三.创建和使用Redis群集 四.使用创建群集脚本创建Redis群集 五.测试故障转移 六.手动故障转移 七.总结 一.引言 本文档只对Redis的Cluster集群做简单的介绍,并没有对分布式系统的所涉及到的概念做深入的探讨.本文只是针

  • spring boot + quartz集群搭建的完整步骤

    quartz集群能力: quartz集群分为水平集群和垂直集群,水平集群即将定时任务节点部署在不同的服务器,水平集群最大的问题就是时钟同步问题, quartz集群强烈要求时钟同步,若时钟不能同步,则会导致集群中各个节点状态紊乱,造成不可预知的后果,请自行搜索服务器时钟同步, 若能保证时钟同步,水平集群能保证服务的可靠性,其中一个节点挂掉或其中一个服务器宕机,其他节点依然正常服务:垂直集群则是集群各节点部署在同一台服务器, 时钟同步自然不是问题,但存在单点故障问题,服务器宕机会严重影响服务的可用性

  • Nginx+Tomcat搭建高性能负载均衡集群的实现方法

    一.    目标实现高性能负载均衡的Tomcat集群: 二.步骤 1.首先下载Nginx,要下载稳定版: 2.然后解压两个Tomcat,分别命名为apache-tomcat-6.0.33-1和apache-tomcat-6.0.33-2: 3.然后修改这两个Tomcat的启动端口,分别为18080和28080,下面以修改第一台Tomcat为例,打开Tomcat的conf目录下的server.xml: 共需修改3处端口: 当然第二台Tomcat也一样,如下图: 4.然后启动两个Tomcat,并访问

  • Redis6.0搭建集群Redis-cluster的方法

    此处以三台服务器部署为例,IP地址分别为192.168.124.23,192.168.124.24,192.168.124.25 使用普通用户ubuntu登录 总共三个主节点和三个从节点.每台服务器分配槽位不同的一主一从 从官网https://redis.io/download下载Redis6.0 Stable版安装包到/usr/local/redis-6.0.x.tar.gz(文件位置可自定义) 将安装包解压tar -zxvf redis-6.0.x.tar.gz 进入redis文件夹(cd

  • Docker-Compose搭建Spark集群的实现方法

    目录 一.前言 二.docker-compose.yml 三.启动集群 四.结合hdfs使用 一.前言 在前文中,我们使用Docker-Compose完成了hdfs集群的构建.本文将继续使用Docker-Compose,实现Spark集群的搭建. 二.docker-compose.yml 对于Spark集群,我们采用一个mater节点和两个worker节点进行构建.其中,所有的work节点均分配1一个core和 1GB的内存. Docker镜像选择了bitnami/spark的开源镜像,选择的s

  • ubuntu docker搭建Hadoop集群环境的方法

    spark要配合Hadoop的hdfs使用,然而Hadoop的特点就是分布式,在一台主机上搭建集群有点困难,百度后发现可以使用docker构建搭建,于是开搞: github项目:https://github.com/kiwenlau/hadoop-cluster-docker 参考文章://www.jb51.net/article/109698.htm docker安装 文章中安装的是docker.io 但是我推荐安装docker-ce,docker.io版本太老了,步骤如下: 1.国际惯例更新

  • docker安装pxc集群的详细教程

    前言 现在mysql自建集群方案有多种,keepalived.MHA.PXC.MYSQL主备等,但是目前根据自身情况和条件,选择使用pxc的放来进行搭建,最大的好处就是,多主多备,即主从一体,没有同步延时问题,方便易用. 本人使用过,直接安装pxc和docker容器方式的安装,个人觉得docker下安装更为方便,也更易维护,所以也推荐大家使用此方式. 搭建环境 环境 centos7 pxc版本镜像:最新版,目前为8.0+ 主机ip 部署 swarm 172.16.9.40 pxc1 manage

随机推荐