暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

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=#

                使用对比总结

                从上面的演示中可以看到,两种分布式存在以下几点区别:

                1. 中间件分布式,由于路由信息必须由proxy等中间件上报zk调度统一管理,即DDL操作必须通过中间件路由节点访问数据库实例来操作。受集中式架构使用习惯影响,部分用户可能直接使用dn节点的ip及端口访问实例来进行DDL操作,比如建表、建索引等,甚至使用该ip及端口对数据进行增删改成,后来才发现cn节点从zk等第三方组件无法拉取元数据,直接导致分布式集群缺失元数据而异常。如果在DB访问入口方面未能做到严格的规范管理,这将是一种十分容易引起故障的隐患。
                2. 原生分布式,路由信息直接由原生组件管理,每个cn节点会保存完整的元数据,路由信息的拉取无需依赖zk等第三方组件,并拒绝从dn节点进行DDL和DML操作,杜绝了因从dn节点操作DB引发元数据信息缺失的问题,相对于中间件分布式,会显得更加安全可靠。

                I Love PG

                关于我们

                PostgreSQLPG2017PostgreSQLPG非盈利行业协会组织。我们致力于在中国PostgreSQLPostgreSQL



                欢迎投稿

                做你的舞台,show出自己的才华 。

                投稿邮箱:partner@postgresqlchina.com

                                    

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



                技术文章精彩回顾




                PostgreSQL学习的九层宝塔
                PostgreSQL职业发展与学习攻略
                2019,年度数据库舍 PostgreSQL 其谁?
                Postgres是最好的开源软件
                PostgreSQL是世界上最好的数据库
                从Oracle迁移到PostgreSQL的十大理由
                从“非主流”到“潮流”,开源早已值得拥有

                PG活动精彩回顾




                创建PG全球生态!PostgresConf.CN2019大会盛大召开
                首站起航!2019“让PG‘象’前行”上海站成功举行
                走进蓉城丨2019“让PG‘象’前行”成都站成功举行
                中国PG象牙塔计划发布,首批合作高校授牌仪式在天津举行
                群英论道聚北京,共话PostgreSQL
                相聚巴厘岛| PG Conf.Asia 2019  DAY0、DAY1简报
                相知巴厘岛| PG Conf.Asia 2019 DAY2简报
                独家|硅谷Postgres大会简报
                直播回顾 | Bruce Momjian:原生分布式将在PG 14版本发布

                PG培训认证精彩回顾




                中国首批PGCA认证考试圆满结束,203位考生成功获得认证!
                中国第二批PGCA认证考试圆满结束,115位考生喜获认证!
                重要通知:三方共建,中国PostgreSQL认证权威升级!
                近500人参与!首次PGCE中级、第三批次PGCA初级认证考试落幕!
                2020年首批 | 中国PostgreSQL初级认证考试圆满结束
                一分耕耘一分收获,第五批次PostgreSQL认证考试成绩公布

                PG专辑预览阅读




                开源软件联盟PostgreSQL分会专辑之活动篇
                文章转载自开源软件联盟PostgreSQL分会,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

                评论