这里就得提到PROXYSQL BINLOG Reader, 一个轻量级的进程运行在MYSQL 的SERVER上,主库提供GTID的
information ,并且将这些信息同步到所有的PROXYSQL 的集群中(不知道集群的,请看上一期)。
并且他考虑了相关CPU 和 NETWORK 的性能问题。当然proxysql_mysqlbinlog.
当然值得一说的还有对GALERA replication 的支持,这里可能部分人不知什么是GALERA REPLICATION ,换
个名词 PXC ,估计大部分人就知道了,其中对PXC 的支持也是有的 添加了部分参数,更符合PXC本身的原理,
例如 MAX_ TRANSACTIONS_BEHIND ,Writer_is_also_reader 等等。但鉴于使用PXC的公司和个人越来越少,
这里就 飞过。
值得我们注意的是从PROXYSQL 2.05 后开始的Audit log 的问题, 使用任何最近被问到MYSQL的AUDIT 的问
题,之前MYSQL 5.X是加载了AUDIT的插件,但目前上了MYSQL8 后,这方面就暂时短缺,而PROXYSQL 本身
的提供了AUDIT LOG 并且格式是JSON 的,这就让后期的MYSQL的AUDIT问题在PROXYSQL上被解决掉。这
里PROXYSQL 根据MYSQL本身的特点, 支持了SUCCESSFUL FAILED ,DISCONNECT ,CONNECTION
CHANGE schema(COM_INT_DB)。
PROXYSQL 提供了白名单的功能,在之前如果设置了QUERY RULE 上有一些设置某些语句不能被使用或者进行
语句转换,那对管理员来说可能就比较麻烦,例如我们设置了 SELECT count(*)的方式不能被接受,则所有的人
都不能使用select count(*), 但对于特殊的人员这一定是不行的,所以我们就需要
mysql_firewall_whitelist_users 来将这些特殊的人,放到可以“肆意妄为的”自留地。
评论