8.3.?MX特性

8.3.1. 概述
8.3.2. 技术方案
8.3.3. 注意事项

8.3.1.?概述

uxmpp的架构中正常只有1个CN节点,有时候CN会成为性能瓶颈。澳门游戏平台注册网站可以通过减少分片数,垂直扩容CN节点等手段缓解CN的性能问题,但这些都不能治本。某些业务场景部署多个CN节点是非常必要的。

8.3.2.?技术方案

如果CN上主要的负载来自查询,可以为CN节点配置多个备机,做读写分离,这些备机可以分担读负载。但是这种方案不能称为多CN,它不具有均衡写负载的能力。

在uxmpp的具体实现中,CN和worker的区别就在于是否存储了相关的元数据,如果把CN的元数据拷贝一份到worker上,那么worker也可以向CN一样工作,这个多CN的模式早期被称做masterless。

对于当前的uxmpp版本,有一个开关,打开后,会自动拷贝CN的元数据到Worker上,让worker也可以当CN用。下面进行验证。

在CN节点的uxsinodb.conf中添加下面的参数:

uxmpp.replication_model='streaming'

在CN节点上添加worker节点:

SELECT * from master_add_node('wk1', 5432);
SELECT * from master_add_node('wk2', 5432);

从CN复制元数据到第一个worker节点:

SELECT start_metadata_sync_to_node('wk1', 5432);

执行上面的函数后,uxmpp CN上的元数据会被拷贝到指定的worker上,并且ux_dist_node表中对应worker的hasmetadata字段值为true,标识这个Worker存储了元数据,以后创建新的分片时,新产生的元数据也会自动同步到这个worker上。

uxdb=# select * from ux_dist_node;
 nodeid | groupid | nodename | nodeport | noderack | hasmetadata | isactive | noderole | nodecluster 
--------+---------+----------+----------+----------+-------------+----------+----------+-------------
      1 |       1 |      wk1 |     5432 | default  | t           | t        | primary  | default
      2 |       2 |      wk2 |     5432 | default  | f           | t        | primary  | default
(2 rows)

在CN节点上创建一个测试分片表:

create table tb1(id int primary key, c1 int);
set uxmpp.shard_count=8;
select create_distributed_table('tb1','id');
insert into tb1 select id,random()*1000 from generate_series(1,100)id;

因为wk1带了元数据,可以当CN用,下面这个SQL可以在wk1上执行:

uxdb=# explain select * from tb1;
                                  QUERY PLAN                                  
------------------------------------------------------------------------------
 Custom Scan (Uxmpp Real-Time)  (cost=0.00..0.00 rows=0 width=0)
   Task Count: 8
   Tasks Shown: One of 8
   ->  Task
         Node: host=wk1 port=5432 dbname=uxdb
         ->  Seq Scan on tb1_102092 tb1  (cost=0.00..32.60 rows=2260 width=8)
(6 rows)

为了说明方便,后面把这种带了元数据的worker称之为“扩展worker”。uxmpp会限制某些SQL在扩展worker上执行,比如DDL。

8.3.3.?注意事项

扩展Worker其实把Worker和CN两个角色混在一个节点里,维护上不是很方便。有下面几个表现:

  1. 扩展Worker上的负载可能不均衡

  2. 如果出现性能问题增加了故障排查的难度

  3. CN和Worker将不能独立扩容

  4. 扩大了插件兼容问题的影响

在扩展worker上尽量避免会产生分布式事务或死锁的操作。建议只执行这几类SQL,并且不使用事务。

  • SELECT

  • INSERT

  • 条件中带分片字段的SQL

XML 地图 | Sitemap 地图