ProxySQL

MySQL之前有一个查询缓存Query Cache,从8.0开始，不再使用这个查询缓存，那么放弃它的原因是什么呢？ 在这一篇里将为您介绍。 MySQL查询缓存是查询结果缓存 。 它将以SEL开头的查询与哈希表进行比较，如果匹配，则返回上一次查询的结果。进行匹配时， 查询必须逐字节匹配，例如 SELECT * FROM t1; 不等于select * from t1;，此外，一些不确定的查询结果无法被缓存，任何对表的修改都会导致这些表的所有缓存无效。因此，适用于查询缓存的最理想的方案是只读，特别是需要检查数百万行后仅返回数行的复杂查询。如果你的查询符合这样一个特点，开启查询缓存会提升你的查询性能。 随着技术的进步，经过时间的考验，MySQL的工程团队发现启用缓存的好处并不多。 首先，查询缓存的效果取决于缓存的命中率，只有命中缓存的查询效果才能有改善，因此无法预测其性能。 其次， 查询缓存的另一个大问题是它受到单个互斥锁的保护。 在具有多个内核的服务器上，大量查询会导致大量的互斥锁争用。 通过基准测试发现， 大多数工作负载最好禁用查询缓存（5.6的默认设置）： query_cache_type = 0 如果你认为会从查询缓存中获得好处，请按照实际情况进行测试。 数据 写的越多，好处越少 缓冲池中容纳的数据越多，好处越少 查询越复杂，扫描范围越大，则越受益 MySQL8

　　首先我们来回顾下代理的概念，所谓代理就是指的是一端面向客户端，另外一端面向服务端，代理客户端访问服务端，我们把这种代理叫正向代理；代理服务端响应客户端我们叫做反向代理，这个我们在之前nginx系列博客中阐述过这样的概念；不管是正向代理还是反向代理他们都是代理，他们都有一个共同点就是代表一端（客户端/服务端）访问或响应另一端；简单讲代理就是即充当服务端角色又充当客户端角色；在mariadb的主从复制集群中，读的能力被扩展了，而写的能力始终没有被扩展；这样一来对于主服务器就存在单点的问题，通常除了做双主可解决主节点单点的问题，我们还可以给主节点做高可用；而对于mariadb的主从复制集群来讲，虽然读的能力提升了，但通常情况后端数据库服务器是直接面向程序，这意味着程序要知道读请求和写请求该发往不同的数据库服务器上；在用户发来读请求，这个程序它会分析用户的请求，然后把用户的请求代理到后端server上；也就是说我们需要一个程序能够解析用户的读写操作，把对应的操作代理到后端不同的节点上；这样一来用户的读操作始终均衡的被调度到从节点，写操作调度到主节点；proxysql这款软件就有我们上面说的功能，它能够将用户发来的读写操作，通过proxysql的语句路由，把对应请求分别发送到不同节点执行；如下图所示： 　　从上面的图片可以看到，proxysql就是一代理，面向程序它就是一数据库服务器

11_ProxySQL配置之SSL_configuration 备注：文章编写时间201904-201905期间，后续官方在github的更新没有被写入 ~ ~ SSL Support 一、SSl设置[SSL configuration for backends] 从版本v1.2.0e开始，ProxySQL支持对后端使用SSL连接。尝试在旧版本上配置SSL将会失败。 1、重要提示: 1）仅支持v1.x中的后端SSL。在v2.x之前的版本中，客户端是无法使用SSL连接到ProxySQL的。 2）从v1.4.5开始，由于ProxySQL使用了mariadb-connector-c-2.3.1，所以只支持SSL/TLSv1.0: https://mariadb.com/kb/en/library/mariadb-connector-c-300-release-notes/ 3）在ProxySQL v2.x中，使用了mariadb-connector-3.0.2，它支持SSL/TLSv1.0、TLSv1.1和TLSv1.2。这适用于前端和后端连接。 2、启用SSL的准备工作 若要启用SSL连接，需要做如下准备： 1）为要使用SSL的服务器更新mysql_servers.use_ssl中SSL状态值; 2）更新关联的全局变量（仅在ProxySQL v1.x版本中需要，ProxySQL v2

22_Bug反馈 备注：文章编写时间201904-201905期间，后续官方在github的更新没有被写入 ~ ~ 如何报告崩溃错误[How to report a crash bug] 如果您要报告崩溃错误，请确保包含足够的信息以用于调试目的。 1）清楚地问题描述； 2）指定正在运行的proxysql的确切版本； 3）指定用于安装proxysql的软件包； 4）附加压缩的proxysql二进制文件； 5）指定正在运行的操作系统版本； 6）附加压缩核心转储（如果您担心它可能有敏感数据，请直接与我们联系）； 7）附加压缩错误日志（不只是最后几行）； 8）尽力让每一步都重现这个问题； 如果没有足够的崩溃错误信息，是不太可能被探究的。 完毕！ 来源： oschina 链接： https://my.oschina.net/u/4390465/blog/4258169

25_Design_Goals 备注：文章编写时间201904-201905期间，后续官方在github的更新没有被写入 ~ ~ 设计目标[Design Goals] ProxySQL的构建考虑了一些关键的设计选择。 一、最大正常运行时间[Maximum uptime] 由于ProxySQL是一个代理服务器，因此预计会尽可能接近100％的正常运行时间。 1、更改配置[configuration changes] 这通常通过更改配置文件并重新启动守护程序来完成。在ProxySQL中，通过设计，用户可以通过管理界面修改大多数配置变量，而无需重新启动服务器。 可以在运行时修改的配置示例： 1）ProxySQL正在侦听的接口； 2）ProxySQL连接的后端服务器； 3）ProxySQL执行的不同操作的超时时间； 2、崩溃[crashes] ProxySQL有一套广泛的集成测试，使用Docker运行，以确保它不会崩溃。此外，每个主要版本都使用sysbench进行性能测试，并使用valgrind进行内存泄漏测试。 除此之外，还实现了一个 angel 进程，可在需要时监视并重新启动ProxySQL，以便在停机时将停机时间降至最低。 二、最大的可扩展性[Maximum scalability] 在与ProxySQL交互时，我们希望尽快运行几个关键任务： 1、尽快完成一个新的MySQL连接了：

23_Error_codes 备注：文章编写时间201904-201905期间，后续官方在github的更新没有被写入 ~ ~ 错误代码[Error codes] 这是ProxySQL报告的自定义错误代码的临时列表 1）Error: 9001 Message: Max connect timeout reached while reaching hostgroup %d after %llums 消息：在％llums之后到达hostgroup％d的最大连接超时时间。 2）Error: 9002 Message: Max connect failure while reaching hostgroup %d 消息：到达hostgroup％d的最大连接失败次数； 3）Error: 9003 Message: Command not supported 消息：命令不受支持 完毕！ 来源： oschina 链接： https://my.oschina.net/u/4312062/blog/4258174

最近发现在我们的测试环境django事务失效了--！ 大概类似于下面这样 from app1.models import Region from django.db import transaction r,_=Region.objects.get_or_create(id=111,name='111') with transaction.atomic(): r.name='33' r.save() raise Exception('11') 执行完到库里查看时，发现库里的name字段已经修改 WTF, django的bug，这代码只能这么简单了。。。 于是重试了django的各个版本，发现django1.11版本之前的没问题，之后的就失效，接着去翻了下django的issue，发现并没有类似的bug，不可能啊，django的2.0版本在两年前就出了，事务不生效算是严重bug呢，怎么可能没人发现。 于是又怀疑测试环境数据库的问题，本地新装了mysql进行测试，这时同样的代码，发现事务又生效了，WTF,WTF......... 怎么回事啊？ 接着找到DBA，发现测试环境mysql外新加了层proxysql，那可能是这个的问题哦，于是又一通查，发现proxysql会接收set autocommit=0的命令，但不会送到后端的mysql，就在穷途末路时，去看了下版本的changelog

背景： 随着数据量的上升，OLAP一直是被讨论的话题，虽然druid，kylin能够解决OLAP问题，但是druid，kylin也是需要和hadoop全家桶一起用的，异常的笨重，再说我也搞不定，那只能找我能搞定的技术。故引进clickhoue，关于clickhoue在17年本人就开始关注，并且写了一些入门的介绍，直到19年clickhoue功能慢慢的丰富才又慢慢的关注，并且编写了同步程序，把mysql数据实时同步到clickhoue，并且最终在线上使用起来。 关于clickhouse是什么请自行查阅官网： https://clickhouse.yandex/ clickhouse官方性能测试： https://clickhouse.yandex/benchmark.html clickhouse面对海量数据，比如单表过百亿可以使用集群（复制+分片），如果数据量比较小，比如单表10-20亿使用单机就足以满足查询需求。如果使用复制需要使用zk，更多集群的请自行查阅官方资料。 单机部署（以前的文章也有写过单机部署） ： 在2016年clickhouse刚开始开源的时候对Ubuntu支持非常友好，一个apt命令就可以安装了。对于centos等系统 支持就比较差，需要自己编译，而且不一定能够成功。随着使用人群的扩大，目前对于centos支持也是非常的友好 了，有rpm包可以直接安装