社区投稿 | DBLE Server.xml 配置解析

戏子无情 提交于 2019-12-04 12:50:08

原创: 余朝飞


DBLE是基于开源项目MyCat发展的企业级开源分布式中间件,适用于高并发及TB级海量数据处理场景;江湖人送外号 “MyCat Plus”;其简单稳定,持续维护,良好的社区环境和广大的群众基础使DBLE得到了社区的大力支持。

DBLE项目介绍

DBLE官方网站:

https://opensource.actionsky.com

可以详细了解DBLE的背景和应用场景,本文不涉及到的细节都可在官方文档获得更多信息;对于刚了解的同学,本文可以作为快速入门的基础

DBLE 官方项目:

https://github.com/actiontech/dble

如对源码有兴趣或者需要定制的功能的可以通过源码编译安装

DBLE 下载地址:

https://github.com/actiontech/dble/releases

DBLE 官方社区交流群:669663113

 

DBLE的主要配置文件

前两篇文章"DBLE Rule.xml 配置解析"、"DBLE Schema.xml 配置解析" 分别介绍DBLE中Rule.xml和Schema.xml的配置,今天继续介绍DBLE中Server.xml文件的配置,希望通过本篇的介绍,能对Server.xml文件的整体结构和内容有较为清晰的认识,方便大家快速入门。

DBLE的配置文件都在conf目录里面,常用的几个配置文件如下:

文件 说明
server.xml DBLE server相关参数定义,包括dble性能,定时任务,端口,用户配置等
schema.xml DBLE具体分片定义,规定table和schema以及dataNode之间的关系,指定每个表格使用哪种类型的分片方法,定义每个dataNode的连接信息等
rule.xml DBLE实际用到的分片算法的配置

DBLE是一个JAVA分库分表中间件,既然是JAVA应用肯定会有JVM相关的配置,在DBLE中我们选择wrapper来作为管理DBLE进程的工具,配置文件在conf/wrapper.conf中,关于JVM的详细介绍在wrapp.conf。

wrapp.conf:

https://actiontech.github.io/dble-docs-cn/1.config_file/1.4_wrapper.conf.html

 

Server.xml配置解析

Server.xml是DBLE的重要配置文件之一, 整体配置可以分为三段,<system>段,<user>段和<firewall>段,分别定义了DBLE软件的相关配置,用户配置和针对用户的权限控制功能。

<dble:server>
  <system></system>
  <user></user>
  <firewall>
  <whitehost></whitehost>
  </firewall>
</dble:server>

关于配置文件,如果在DBLE运行途中修改了配置,要想配置动态生效,只需要使用reload @@config命令,但是需要提醒的是reload @@config对Server.mxl中的<system>段中的内容无法生效,即如果修改了server.xml的system的配置,需要重新启动DBLE使其生效 ,更多关于DBLE管理命令请参考DBLE管理端命令。

管理端命令:

https://actiontech.github.io/dble-docs-cn/2.Function/2.01_manager_cmd.html

同样以思维导图的方式归纳如下,其中个别参数配置只是粗略地将最重要的参数罗列出来,详细的参数还请参考官方文档。

 

system配置

DBLE通过Server.xml配置文件来定义相关管理行为,如监听端口,sql统计和控制连接行为等功能,DBLE除了支持分库分表功能外,还实现了类似MySQL的慢查询日志功能,并且支持使用pt-query-digest这样的工具进行慢查询SQL分析,极大地方便了DBA的SQL性能分析与问题SQL定位,以下简单列出了一些最重要的也是最基础的功能配置。

property 作用

serverPort

业务用户连接端口

managerPort

管理用户连接端口

charset

字符集

maxCon

控制最大连接数

processors

NIO前端处理器的数量,默认java虚拟机核数

enableSlowLog

是否允许慢查询,默认不开启

sqlSlowTime

慢查询阈值,类似MySQL中的long_query_time,单位是毫秒

 

用户配置

用户配置在<user>段进行配置,因为在Schema.xml中允许多个schema的存在,因此业务用户也是允许多个用户同时存在,并且还可以给这些用户进行更小粒度的权限划分。

以实际场景来举例,比如当前配置了两个逻辑库advmotor,分别是汽车和广告业务,这两个库直接没有任何的关联,因此需要分别配置两个用户来使用这两个schema,一个是adv_user,另一个是motor_user,这两个用户登录上去DBLE能看到只有自己的schema,其他schema不可见,两个用户的配置如下:

<user name="adv_user">
   <property name="password">adv_user</property>
   <property name="schemas">adv</property>
   <property name="readOnly">false</property>
</user>
 <user name="motor_user">
   <property name="password">motor_user</property>
   <property name="schemas">motor</property>
   <property name="readOnly">false</property>
</user>

但是你可能会想万一这两个库之中的表有关联查询呢?对应场景是:我们需要有个用户叫adv_motor_user,它对motoradv库都需要有权限访问,别担心,DBLE提供了对单个用户可以访问多个schema的配置方式,我们可以在schemas中指定多个schema,之间用逗号分隔,配置生效后使用这个用户就能登录看到两个schema。

<user name="adv_motor_user">
  <property name="password">adv_motor_user</property>
  <property name="schemas">motor,adv</property> <!--多个逻辑库之间使用逗号分隔,这些逻辑库必须在Schema.xml中定义-->
  <property name="readOnly">false</property>  <!--用来做只读用户-->
</user>

你可能还会想,这样的权限粒度依然不够细,我们需要更细粒度的权限控制,比如需要adv_user的权限仅限于增删改查权限,即需要将权限细分到dml语句, DBLE仍然提供这样的配置,我们可以继续增加privileges的配置,如下图示:

<user name="adv_user">
   <property name="password">adv_user</property>
   <property name="schemas">adv</property>
   <property name="readOnly">false</property>
   <privileges check="true">
   <schema name="adv" dml="1110" >  <!-- 默认库中所有逻辑表的继承权限 -->
        <table name="tb01" dml="1111"></table>  <!-- 单独指定表权限 -->
   </schema>
   </privileges>
</user>

privileges的check参数作用于是否对用户权限进行检查,默认是不检查,dml的权限是分别是INSERT UPDATE SELECT DELETE四种权限,用4个数字0或1的组合来表示是否开启, 1表示开启,0表示关闭。

在上图中, adv_user对adv库中所有表的默认权限是'1110', 即只有insert, updateselect权限, 即如果没有像tb01那样详细地列出来的情况,所有表的权限继承权限1110,上面例子中,ta01作为特殊指定的逻辑表的权限,adv_user对该表的权限是1111

我们可以看到DBLE可以将权限划分到DML,并且是可以精确到某一逻辑表级别,对于只需要DML权限的场景是足够了,但是这种权限控制还是很粗略,比如如果想让adv_user除了有dml权限之外,还需要有drop table权限,这时候在用DBLE的privileges权限控制就显得无能为力了,因此可行的建议是:

  1. 控制连接后端MySQL的用户的权限,将DBLE侧的权限完全放开, 换句话说只严格限制schema.xml的writehost中配置的连接用户的权限。

  2. 使用后面要讲的黑名单提供的权限控制。

 

黑白名单配置

针对上的权限粒度略显粗略的限制(事实上大多数场景下DML的权限也已经足够了),DBLE提供黑白名单的功能,白名单就是只允许白名单的连接,而黑名单则是详细的针对已经通过白名单的连接的权限控制,黑名单更类似于SQL审计, 黑名单配置以firewall分隔开来, 典型配置如下:

<firewall>
  <whitehost>
    <host host="127.0.0.1" user="adv_user"/>
    <host host="127.0.0.1" user="admin"/> 
  </whitehost>
  <blacklist check="true">
<property name="selelctAllow">false</property>  <!-- 允许select-->
<property name="insertAllow">false</property>  <!-- 允许insert-->
<property name="updateAllow">false</property>
......  
  </blacklist>
</firewall>

对于黑白名单,需要注意:

  1. DBLE针对来源IP和用户名进行限制,放行白名单连接,对于不在白名单列之中的连接,统统拒绝而无法登陆。 白名单中的来源ip,只能指定固定IP, 暂不支持MySQL "%''类似的ip通配符。

    想象一种场景,需要像MySQL一样指定一个ip范围能允许连接DBLE,这时只能一行一行增加允许ip了,此处略显笨拙。

  2. 如果配置了黑名单,则再根据黑名单中的权限property 来进一步限制白名单中的用户权限,例如是否允许查询,是否允许INSERT,是否允许UPDATE。可以看出DBLE中黑名单更像是对用户的权限审计,DBLE在黑名单中将上面只能粗糙地限制到DML权限的用户配置做了较多较细的扩展,这样权限粒度更小,从实际场景来说,这更符合生产需要,由此我们可以针对性地去掉一些危险的SQL。

 

总结

本文简单介绍了Server.xml中的三个重要的配置段落,分别是DBLE的系统配置,用户配置以及黑白名单功能,针对用户配置则介绍了实际应用场景下的配置以及对应的DML权限配置,并详细介绍了DBLE黑白名单配置实践。

标签
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!