mysql跟pg集群_pg原生和mysql中间件分布式之间路由操作对比

文章转载自公众号：DB印象

从元数据和全局资源管理角度来看，目前分布数据库可分为：原生路由和中间件路由两种方式。比如TBase(基于PostgreSQL内核)和TDSQL(基于MySQL内核)，前者是原生pgxl分布式，后者是借助proxy实现的中间件分布式。

温馨提示：文章观点不代表官方。

不同的实现方式会对路由的操作有不同的影响，稍不注意可能会在使用过程中不知不觉留下隐患，文章简单记录一下两者的使用区别。

中间件分布式

场景一：通过DN删除CN创建的表

--1.通过CN建表：成功

mysql -h 192.168.8.1 -P 15260 -u dbmgr -p -D testdb

create table testdb.akentab02

( a int, b int, c char(20),primary key (a,b),unique key u_1(a,c) );

--2.通过DN删表：成功

mysql -h 192.168.8.2 -P 4005 -u dbmgr -D -d testdb

drop table testdb.akentab02;

--3.通过CN重建表、访问表：异常。

mysql -h 192.168.8.1 -P 15260 -u dbmgr -p -D testdb

MySQL [testdb]> show tables; --路由查看表已不存在

Empty set (0.03 sec)

MySQL [testdb]> create table testdb.akentab02 ( a int, b int, c char(20),primary key (a,b),unique key u_1(a,c) );

ERROR 687 (HY000): Proxy ERROR:Table already exists --重建同名表失败，路由信息依旧存在

MySQL [testdb]> select * from akentab02; --但该表无法访问、无法drop

ERROR 1051 (42S02): Unknown table 'testdb.akentab'

MySQL [testdb]> drop table akentab02;

ERROR 1051 (42S02): Unknown table 'testdb.akentab'

MySQL [testdb]>

场景二：通过CN访问DN创建的表

--1.通过DN建表：成功

mysql -h 192.168.8.2 -P 4005 -u dbmgr -D -d testdb -A -c

create table testdb.akentab ( a int, b int, c char(20),primary key (a,b),unique key u_1(a,c) );

--2.通过CN访问表：异常

mysql -h 192.168.8.1 -P 15260 -u dbmgr -p -D testdb -A -c

MySQL [testdb]> show tables;

+------------------+

| Tables_in_testdb |

+------------------+

| akentab |

+------------------+

1 row in set (0.02 sec)

MySQL [testdb]> select * from testdb.akentab01; ---无法读取到表的路由信息

ERROR 660 (HY000): Proxy ERROR:Table:'testdb.akentab01' does not exist

MySQL [testdb]>

原生路由分布式

--CN连接，进行建表：成功

[tbase@ ~]$ psql -h 192.168.8.1 -p 11345 akendb

psql (10.6, server 10.0 TBase V2)

Type "help" for help.

akendb=# create table aken01(id serial,name text);

CREATE TABLE

akendb=#

--DN连接，尝试drop在CN连接创建的表，提示read-only transaction，拒绝通过直连DN进行DML、DDL操作

[tbase@ ~]$ psql -h 192.168.8.2 -p 11002 -U tbase -d akendb

psql (PostgreSQL 10.0 TBase V2)

Type "help" for help.

akendb=# \dt

List of relations

Schema | Name | Type | Owner

--------+-----------------------------+-------+-------

public | aken01 | table | tbase

public | aken02 | table | tbase

public | aken03 | table | tbase

public | tab | table | tbase

public | tbase_subscription | table | tbase

public | tbase_subscription_parallel | table | tbase

(6 rows)

akendb=# drop table aken01;

ERROR: cannot execute DROP TABLE in a read-only transaction

akendb=#

akendb=# create table aken04(id serial,name text);

ERROR: cannot execute CREATE TABLE in a read-only transaction

akendb=#

使用对比总结

从上面的演示中可以看到，两种分布式存在以下几点区别：中间件分布式，由于路由信息必须由proxy等中间件上报zk调度统一管理，即DDL操作必须通过中间件路由节点访问数据库实例来操作。受集中式架构使用习惯影响，部分用户可能直接使用dn节点的ip及端口访问实例来进行DDL操作，比如建表、建索引等，甚至使用该ip及端口对数据进行增删改成，后来才发现cn节点从zk等第三方组件无法拉取元数据，直接导致分布式集群缺失元数据而异常。如果在DB访问入口方面未能做到严格的规范管理，这将是一种十分容易引起故障的隐患。

原生分布式，路由信息直接由原生组件管理，每个cn节点会保存完整的元数据，路由信息的拉取无需依赖zk等第三方组件，并拒绝从dn节点进行DDL和DML操作，杜绝了因从dn节点操作DB引发元数据信息缺失的问题，相对于中间件分布式，会显得更加安全可靠。I Love PG关于我们中国开源软件推进联盟PostgreSQL分会(简称：中国PG分会)于2017年成立，由国内多家PostgreSQL生态企业所共同发起，业务上接受工信部中国电子信息产业发展研究院指导。中国PG分会是一个非盈利行业协会组织。我们致力于在中国构建PostgreSQL产业生态，推动PostgreSQL产学研用发展。

欢迎投稿做你的舞台，show出自己的才华 。

投稿邮箱：partner@postgresqlchina.com

——愿能安放你不羁的灵魂

开源软件联盟PostgreSQL分会专辑之活动篇