MySQL中间件之ProxySQL(3)：多层配置系统

1.ProxySQL中的库

使用ProxySQL的Admin管理接口连上ProxySQL，可查看ProxySQL拥有的库。

mysql -uadmin -padmin -h127.0.0.1 -P6032 --prompt 'admin> '
admin> show databases;
+-----+---------------+-------------------------------------+
| seq | name          | file                                |
+-----+---------------+-------------------------------------+
| 0   | main          |                                     |
| 2   | disk          | /var/lib/proxysql/proxysql.db       |
| 3   | stats         |                                     |
| 4   | monitor       |                                     |
| 5   | stats_history | /var/lib/proxysql/proxysql_stats.db |
+-----+---------------+-------------------------------------+

其中：

  • main库是ProxySQL最主要的库，是需要修改配置时使用的库，它其实是一个内存数据库系统。所以，修改main库中的配置后，必须将其持久化到disk上才能永久保存。
  • disk库是磁盘数据库，该数据库结构和内存数据库完全一致。当持久化内存数据库中的配置时，其实就是写入到disk库中。磁盘数据库的默认路径为$DATADIR/proxysql.db。
  • stats库是统计信息库。这个库中的数据一般是在检索其内数据时临时填充的，它保存在内存中。因为没有相关的配置项，所以无需持久化。
  • monitor库是监控后端MySQL节点相关的库，该库中只有几个log类的表，监控模块收集到的监控信息全都存放到对应的log表中。
  • stats_history库是1.4.4版新增的库，用于存放历史统计数据。默认路径为$DATADIR/proxysql_stats.db。

ProxySQL内部使用的是SQLite3数据库，无论是内存数据库还是磁盘数据库，都是通过SQLite3引擎进行解析、操作的。它和MySQL的语法可能稍有不同，但ProxySQL会对不兼容的语法自动进行调整，最大程度上保证MySQL语句的有效率。

上面描述main库的时候，只是说了内存数据库需要持久化到disk库才能永久保存配置。但实际上，修改了main库中的配置后，并不会立即生效，它还需要load到runtime的数据结构中才生效，只有在runtime数据结构中的配置才是对ProxySQL当前有效的配置。请看下面的"多层配置系统"。

2.ProxySQL的多层配置系统

ProxySQL的配置系统非常强大，它能在线修改几乎所有配置(仅有的两个需要重启才能生效的变量为mysql-threads和mysql-stacksize)，并在线生效、持久化保存。这得益于它采用的多层配置系统。

多层配置系统结构如下：

       +-------------------------+
       |         RUNTIME         |
       +-------------------------+
              /|\          |
               |           |
           [1] |       [2] |
               |          \|/
       +-------------------------+
       |         MEMORY          |
       +-------------------------+ _
              /|\          |      |               |           |                   [3] |       [4] |         \ [5]
               |          \|/                +-------------------------+  +---------------+
       |          DISK           |  |  CONFIG FILE  |
       +-------------------------+  +---------------+

解释下这个3层的配置系统。

最底层的是disk库和config file。这里需要注意，这里的config file就是传统的配置文件，默认为/etc/proxysql.cnf，ProxySQL启动时，主要是从disk库中读取配置加载到内存并最终加载到runtime生效，只有极少的几个特定配置内容是从config file中加载的，除非是第一次初始化ProxySQL运行环境(或者disk库为空)。

中间层的是memory，表示的是内存数据库，其实就是main库。通过管理接口修改的所有配置，都保存在内存数据库(main)中。当ProxySQL重启或者崩溃时，这个内存数据库中的数据会丢失，所以需要save到disk库中。

最上层的是runtime，它是ProxySQL有关线程运行时读取的数据结构。换句话说，该数据结构中的配置都是已生效的配置。所以，修改了main库中的配置后，必须load到runtime数据结构中才能使其生效。

在上面的多层配置系统图中，标注了[1]、[2]、[3]、[4]、[5]的序号。每个序号都有两个操作方向from/to b，其实只是所站角度不同而已。以下是各序号对应的操作：

[1] ：将内存数据库中的配置加载到RUNTIME数据结构中
        LOAD XXX FROM MEMORY
        LOAD XXX TO RUNTIME

[2] ：将RUNTIME数据结构中的配置持久化到内存数据库中
        SAVE XXX FROM RUNTIME
        SAVE XXX TO MEMORY

[3] ：将磁盘数据库中的配置加载到内存数据库中
        LOAD XXX FROM DISK
        LOAD XXX TO MEMORY

[4] ：将内存数据库中的配置持久化到磁盘数据库中
        SAVE XXX FROM MEMORY
        SAVE XXX TO DISK

[5] ：从传统配置文件中读取配置加载到内存数据库中
        LOAD XXX FROM CONFIG

DISK/MEMORY/RUNTIME/CONFIG可以缩写，只要能识别即可。例如MEMORY可以缩写为MEM，runtime可以缩写为run。

另外，上面的XXX是什么？这表示要加载/保存的是哪类配置。目前的ProxySQL支持以下几种：

  • [x] mysql users
  • [x] mysql servers
  • [x] mysql variables
  • [x] mysql query rules
  • [x] admin variables
  • [x] scheduler
  • [ ] proxysql_servers：目前ProxySQL集群功能还处于实验阶段，所以该类配置不应该去使用。

这些从main库或disk库中就可以查看到。

admin> show tables from disk;
+------------------------------------+
| tables                             |
+------------------------------------+
| global_variables                   |  # (1)
| mysql_collations                   |  # (N)
| mysql_group_replication_hostgroups |  # (2)
| mysql_query_rules                  |  # (3)
| mysql_query_rules_fast_routing     |  # (4)
| mysql_replication_hostgroups       |  # (5)
| mysql_servers                      |  # (6)
| mysql_users                        |  # (7)
| proxysql_servers                   |  # (8)
| scheduler                          |  # (9)
+------------------------------------+

其中：

  • (1)中包含两类变量，以amdin-开头的表示admin variables，以mysql-开头的表示mysql variables。修改哪类变量，前文的XXX就代表哪类。
  • (2,5,6)对应的都是mysql servers。
  • (3,4)对应的是mysql query rules。
  • (7)对应的mysql users。
  • (9)对应的scheduler。
  • (N)只是一张表，保存的是ProxySQL支持的字符集和排序规则，它是不用修改的。
  • (8)是ProxySQL的集群配置表，该功能目前还处于实验阶段。如果想要配置该功能，则load/save proxysql_servers to/from ...。

以下是几个示例：注意，几乎所有配置都是在admin管理接口上修改的，这也是建议的配置方式。

(1).向ProxySQL的mysql_servers表中添加了一个后端节点。

load mysql servers to runtime;    # 加载到runtime使该节点的配置生效
save mysql servers to disk;     # 将该节点的配置持久化到磁盘数据库中

上面两句和下面两句是等价的，只是操作方向不同(还使用了缩写)：

load mysql servers from mem;
save mysql servers from mem;

(2).向ProxySQL的mysql_users表中添加了用于发送、处理SQL语句的用户。

load mysql users to runtime;
save mysql users to disk;

(3).修改了以admin-开头的变量。

load admin variables to runtime;
save admin variables to disk;

3.启动ProxySQL时如何加载配置

如果ProxySQL是刚安装的，或者磁盘数据库文件为空(甚至不存在)，或者启动ProxySQL时使用了选项--initial，这几种情况启动ProxySQL时，都会从传统配置文件config file中读取配置加载到内存数据库，并自动load到runtime数据结构、save到磁盘数据库，这是初始化ProxySQL运行环境的过程。

如果不是第一次启动ProxySQL，由于已经存在磁盘数据库文件，这时ProxySQL会从磁盘数据库中读取几乎所有的配置(即使传统配置文件中配置了某项，也不会去解析)，但有3项是必须从传统配置文件中读取的。这3项是：

  • datadir：ProxySQL启动时，必须从配置文件中确定它的数据目录，因为磁盘数据库文件、日志以及其它一些文件是存放在数据目录下的。
  • restart_on_missing_heartbeats：MySQL线程丢失多少次心跳，就会杀掉这个线程并重启它。默认值为10。
  • execute_on_exit_failure：如果设置了该变量，ProxySQL父进程将在每次ProxySQL崩溃的时候执行已经定义好的脚本。建议使用它来生成一些崩溃时的警告和日志。注意，ProxySQL的重启速度可能只有几毫秒，因此很多其它的监控工具可能无法探测到ProxySQL的一次普通故障，此时可使用该变量。

    4.关于传统配置文件

传统配置文件默认路径为/etc/proxysql.cnf，也可以在二进制程序proxysql上使用-c或--config来手动指定配置文件。

ProxySQL的传统配置文件示例如下：浏览下即可，几乎不需要手动去配置proxysql.cnf。

datadir="/var/lib/proxysql"

admin_variables=
{
        admin_credentials="admin:admin"
#       mysql_ifaces="127.0.0.1:6032;/tmp/proxysql_admin.sock"
        mysql_ifaces="0.0.0.0:6032"
#       refresh_interval=2000
#       debug=true
}

mysql_variables=
{
        threads=4
        max_connections=2048
        default_query_delay=0
        default_query_timeout=36000000
        have_compress=true
        poll_timeout=2000
#       interfaces="0.0.0.0:6033;/tmp/proxysql.sock"
        interfaces="0.0.0.0:6033"
        default_schema="information_schema"
        stacksize=1048576
        server_version="5.5.30"
        connect_timeout_server=3000
# make sure to configure monitor username and password
        monitor_username="monitor"
        monitor_password="monitor"
        monitor_history=600000
        monitor_connect_interval=60000
        monitor_ping_interval=10000
        monitor_read_only_interval=1500
        monitor_read_only_timeout=500
        ping_interval_server_msec=120000
        ping_timeout_server=500
        commands_stats=true
        sessions_sort=true
        connect_retries_on_failure=10
}

# defines all the MySQL servers
mysql_servers =
(
# {
#   address = "127.0.0.1" # no default, required . If port is 0 , address is interpred as a Unix Socket Domain
#   port = 3306           # no default, required . If port is 0 , address is interpred as a Unix Socket Domain
#   hostgroup = 0         # no default, required
#   status = "ONLINE"     # default: ONLINE
#   weight = 1            # default: 1
#   compression = 0       # default: 0
#   max_replication_lag = 10  # default 0 . If greater than 0 and replication lag passes such threshold, the server is shunned
# },
#       {
#               address = "/var/lib/mysql/mysql.sock"
#               port = 0
#               hostgroup = 0
#       },
#       {
#               address="127.0.0.1"
#               port=21891
#               hostgroup=0
#               max_connections=200
#       },
#       { address="127.0.0.2" , port=3306 , hostgroup=0, max_connections=5 },
#       { address="127.0.0.1" , port=21892 , hostgroup=1 },
#       { address="127.0.0.1" , port=21893 , hostgroup=1 }
#       { address="127.0.0.2" , port=3306 , hostgroup=1 },
#       { address="127.0.0.3" , port=3306 , hostgroup=1 },
#       { address="127.0.0.4" , port=3306 , hostgroup=1 },
#       { address="/var/lib/mysql/mysql.sock" , port=0 , hostgroup=1 }
)

# defines all the MySQL users
mysql_users:
(
#       {
#               username = "username" # no default , required
#               password = "password" # default: ''
#               default_hostgroup = 0 # default: 0
#               active = 1            # default: 1
#       },
#       {
#               username = "root"
#               password = ""
#               default_hostgroup = 0
#               max_connections=1000
#               default_schema="test"
#               active = 1
#       },
#       { username = "user1" , password = "password" , default_hostgroup = 0 , active = 0 }
)

#defines MySQL Query Rules
mysql_query_rules:
(
#       {
#               rule_id=1
#               active=1
#               match_pattern="^SELECT .* FOR UPDATE$"
#               destination_hostgroup=0
#               apply=1
#       },
#       {
#               rule_id=2
#               active=1
#               match_pattern="^SELECT"
#               destination_hostgroup=1
#               apply=1
#       }
)

scheduler=
(
#  {
#    id=1
#    active=0
#    interval_ms=10000
#    filename="/var/lib/proxysql/proxysql_galera_checker.sh"
#    arg1="0"
#    arg2="0"
#    arg3="0"
#    arg4="1"
#    arg5="/var/lib/proxysql/proxysql_galera_checker.log"
#  }
)

mysql_replication_hostgroups=
(
#        {
#                writer_hostgroup=30
#                reader_hostgroup=40
#                comment="test repl 1"
#       },
#       {
#                writer_hostgroup=50
#                reader_hostgroup=60
#                comment="test repl 2"
#        }
)

原文地址：https://www.cnblogs.com/f-ck-need-u/p/9280793.html

时间： 2024-11-05 11:01:02

MySQL中间件之ProxySQL(3)：多层配置系统的相关文章

MySQL中间件之ProxySQL(1)：简介和安装

1.ProxySQL简介 之前的文章里,介绍了一个MySQL的中间件:MySQL Router.详细内容参见:MySQL Router实现MySQL的读写分离. 这里准备用一个系列来详细介绍一个能实实在在用在生产环境的MySQL中间件:ProxySQL.它有两个版本:官方版和percona版,percona版是在官方版的基础上修改的,添加了几个比较实用的工具.在我这个系列文章中,我使用的是官方版. 官方站点:官方站点 官方github:官方github 官方手册:官方手册 percona Pro

MySQL中间件之ProxySQL(2)：初试读写分离

1.实现一个简单的读写分离 这里通过ProxySQL实现一个简单的读写分离功能示例,以便快速入门.即使是快速入门,需要配置的内容也很多,包括:后端MySQL的配置.监控配置.发送SQL语句的用户.SQL语句的路由规则.所以,想要实现一个ProxySQL+MySQL,即使只实现最基本的功能,步骤也是挺多的,不过配置的逻辑都很简单. 实验环境: 角色 主机IP server_id 数据状态 Proxysql 192.168.100.21 null 无 Master 192.168.100.22 11

MySQL中间件之ProxySQL(5)：线程、线程池、连接池

1.ProxySQL的线程 ProxySQL由多个模块组成,是一个多线程的daemon类程序.每个模块都有一个或多个线程去执行任务. 例如,以下是刚启动ProxySQL时的进程情况,一个main进程,一个主线程,21个线程. [[email protected] ~]# pstree | grep proxy |-proxysql---proxysql---21*[{proxysql}] 下面是正常运行时使用的线程列表: 1.1 Main thread 这其实是一个进程,该进程只负责引导.启动核

MySQL中间件之ProxySQL(3)：Admin管理接口

1.ProxySQL的Admin管理接口 当ProxySQL启动后,将监听两个端口: (1).admin管理接口,默认端口为6032.该端口用于查看.配置ProxySQL. (2).接收SQL语句的接口,默认端口为6033,这个接口类似于MySQL的3306端口. ProxySQL的admin管理接口是一个使用MySQL协议的接口,所以,可以直接使用mysql客户端.navicat等工具去连接这个管理接口. 例如,使用mysql客户端去连接ProxySQL的管理接口.下面使用的是管理接口的默认用

MySQL中间件之ProxySQL(15)：ProxySQL代理MySQL组复制

返回ProxySQL系列文章:http://www.cnblogs.com/f-ck-need-u/p/7586194.html 1.ProxySQL+组复制前言 在以前的ProxySQL版本中,要支持MySQL组复制(MGR,MySQL Group Replication)需要借助第三方脚本对组复制做健康检查并自动调整配置,但是从ProxySQL v1.4.0开始,已原生支持MySQL组复制的代理,在main库中也已提供mysql_group_replication_hostgroups表来控

MySQL中间件之ProxySQL(9)：ProxySQL的查询缓存功能

返回ProxySQL系列文章:http://www.cnblogs.com/f-ck-need-u/p/7586194.html ProxySQL支持查询缓存的功能,可以将后端返回的结果集缓存在自己的内存中,在某查询的缓存条目被清理(例如过期)之前,前端再发起同样的查询语句,将直接从缓存中取数据并返回给前端.如此一来,ProxySQL处理的性能会大幅提升,也会大幅减轻后端MySQL Server的压力. 1.开启query cache功能 ProxySQL的查询缓存功能由mysql_query_

MySQL中间件之ProxySQL(8):SQL语句的重写规则极速赛车ProxySQL(8):

联系方式:QQ:2747044651 网址http://zhengtuwl.com的根元素"#mvvm-app"内只有一个文本节点#text,#text的内容为{{name}}.我们就以下面这个模板详细了解一下VUE框架的大体实现流程.<div id="mvvm-app">{{name}}</div><script src="./js/observer.js"></script><script

Mysql 5.7.12解压版的安装及配置系统编码

这篇博文是由于上篇EF+MySql博文引发的,上篇博文中在Seed方法中插入中文数据到Mysql数据库中乱码,后来网上找了N种方法也没解决.重装了MySql并在安装过程中配置了系统编码,此篇记录一下. 一.下载Mysql对应版本的Zip(我这里是mysql-5.7.12-winx64.zip)文件 a.解压后把文件复制到需要放的安装目录文件下.(ps:我的路径是D:\Program Files\MySql 5.7.12\bin)  b.复制bin目录下的my-default.ini文件改名为my

Mysql中间件Proxysql实现mysql主从架构读写分离

实验主机 Master: 192.168.0.17 Slave: 192.168.0.20 Proxysql:192.168.0.30建议关闭防火墙建立Master: 192.168.0.17与Slave: 192.168.0.20的MySQL主从复制架构 Proxysql:192.168.0.30主机上基于yum安装proxysql [[email protected] ~ 20:21:05]#cat <<EOF | tee /etc/yum.repos.d/proxysql.repo &g