mysql udf函数怎么调用

背景

在上一篇推文中，我们介绍了 MySQL Group Replication 8.0.16 支持信息碎片化功能来增强大型事务处理能力。

如果您想在组复制中使用该功能，则任何组成员的版本都不能低于 8.0.16！

简单地说就是由于低版本协议上不支持。MySQL 8.0.16 的组通讯开始支持新协议，简称“分段协议”，之前的版本中只有一种“压缩协议”。

如果多个成员想加入复制组，那么在协议匹配上遵循以下原则：

现有复制组成员和新加入成员版本相同，加入成功。

低版本成员想加入高版本的组会被驱逐，加入失败。

高版本的成员想加入低版本的组，单独加入成功，多个加入失败。

例如：

一个 MySQL Server 8.0.16 实例可以成功加入使用通信协议版本 5.7.24 的组。

一个 MySQL Server 5.7.24 实例无法成功加入使用通信协议版本 8.0.16 的组。

两个 MySQL Server 8.0.16 实例无法同时加入使用通信协议版本 5.7.24 的组。

两个 MySQL Server 8.0.16 实例可以同时加入使用通信协议版本 8.0.16 的组。

新增 UDF

为了能让高版本的复制组更便于加入低版本的成员，MySQL 8.0.16 新增两个 UDF。

您可以使用两个新的 UDF 命令去管理组通信协议：

1. group_replication_set_communication_protocol(new_protocol)

设置组复制通讯协议版本

SELECT group_replication_set_communication_protocol("8.0.15")

填入一个所有成员都支持的版本号，即：new_protocol ≤ 所有成员的 MySQL版本。

new_protocol 格式：major.minor.patch （主版本号.次版本号.发布版本号）例如：8.0.15。

2. group_replication_get_communication_protocol()

获取复制中最旧成员的 MySQL 版本号

SELECT group_replication_get_communication_protocol()   +------------------------------------------------+    | group_replication_get_communication_protocol() |    +------------------------------------------------+    | 5.7.14                                         |    +------------------------------------------------+

获取的版本号可能与设置的值不一致，但不一致的版本之间组复制协议是一样的。

返回结果格式：major.minor.patch （主版本号.次版本号.发布版本号）例如：8.0.15。

以上两个 UDF 对全部组成员有效，主机或从机上均可执行。

结论

若想使用信息碎片功能。建议将组复制成员全部升级为 8.0.16。

若组内成员版本仅有部分为 8.0.16，可以用两个新的函数来让高版本的成员保持与其它成员组协议一致。

请点击输入图片描述

复制之所以工作得益于MySQL把对数据库的变更都记录在 binlog中，然后主库把它读出来，放到从库上去应用。当然binlog 的用途不仅限于此，比如 PITR等

在5.1.4版本以前，binlog格式只能是 statement -based replication ,在以后的版本中引入了 row-based replication 以及 mixed-based replication。

下面我会简单的介绍一下SBR、RBR、MBR 这三种格式下binlog是如何组织的，更重要的是在这三种格式下，replication是如何进行工作的。当然我主要介绍 RBR模式下的复制，因为RBR模式下我们的复制是认为是最安全的方式，即使是使用MBR也会有可能踩到坑。

在MySQL中，Binlog有两类文件，一类文件用于记录数据变更，一类文件用于记录binlog list。

Binlog list文件就是 ${HOSTNAME}-bin.index ；用于记录当前有哪些binlog

binlog的数据文件名字类似于 ${HOSTNAME}-bin.00001,这类文件是我们重点关注的对象。

先来大概的看看binlog 的文件内容：

svan-mac:mydata xiean$ mysqlbinlog -vvvv mysql-bin.000010

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/

DELIMITER /*!*/

# at 4

#151218 15:19:30 server id 5331 end_log_pos 123 CRC32 0xd483743a Start: binlog v 4, server v 5.7.9-log created 151218 15:19:30

# Warning: this binlog is either in use or was not closed properly.

BINLOG '

grNzVg/TFAAAdwAAAHsAAAABAAQANS43LjktbG9nAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA

ATp0g9Q=

'/*!*/

# at 123

#151218 15:19:30 server id 5331 end_log_pos 154 CRC32 0x622c3733 Previous-GTIDs

# [empty]

SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/

DELIMITER

# End of log file

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/

抽一段binlog出来看看：

# at 141

#151218 15:19:30server id 5331 end_log_pos 245

Query thread_id=3350 exec_time=11 error_code=0

at 141

当前事件在文件中的起始位置，单位bytes

#151218 15:19:30

当前事件开始时间

Server id

当前事件在哪个Server 执行的

End_log_pos

下一个事件在文件中的开始位置，即当前事件内容为 4~end_log_pos-1范围

exec_time

执行所花费的时间(如果是Master )；

error_code

执行该事件时的结果

我们把Binlog 文件拆分成3个部份

简单描述 －－>

{

"header": "desc …",

"event": "xxxxxxx",

"footer": "log rotat"

}

第一部份： 由 4-bytes 开始，这4-bytes 表明它是一个MySQL binlog 文件（由log_event.h 这个文件常量：BINLOG_MAGIC (0xfe 0x62 0x69 0x6e = 0xfe 'b''i''n') 表示），这也就能解释我们的第一个event 为什么 起始位置是 4 了原因了。

第二部份： 一个一个的 event ，每个event 根据binlog版本不同，解释出来的含义有所不同(在MySQL 5.0＋ binlog版本都使用的是 V4版本)

第三部份：也就是文件最后event用于记录log-rotation 事件，表明了接下来的日志将写入哪个文件。

Event 是binlog 记录的最小单位，event 的上一级是event group ，复制或者恢复的时候基于 event group 来重放日志。对于一个组来说，要么都执行， 要么都不执行。而对于DML来说一个 event 包含多个event，而对于DDL 来说，一个event 就是一个 event group。对于每个Event里边有哪些东西，以及event group 是如何划分的我们将在下面讨论。

触发器，存储过程，函数在MySQL里边是如何处理的呢？

触发器，存储过程，函数 在创建的时候都会记录Binlog

触发器在执行的时候 Master、Slave 都会被调用，Master上的触发器将会在Master上被调用，Slave上的触发器将会在Slave上被调用。

存储过程在执行的时候，Master上会被转化成具体的SQL语句存储在Binlog里边，因此在binlog里边是看不到任何 call 来调用存储过程的event 。

函数在执行的时候并不会被解析成为具体的语句，相反函数执行时和触发器比较相像，在Master上和Slave都会被调用。

三种模式下Binlog 是如何记录的

基于语句的复制 ： 是MySQL 5.7.7 版本以前默认配置，它将SQL语句（而不是实际的数据变化）从主服务器复制到从服务器。

优点 ：在某些情况下，最终写入日志文件的数据更少，例如更新或者删除许多行时。对于只影响几行数据的简单语句，基于行的复制占用的空间更少。

缺点 ： 最明显的是它不支持不确定性的语句，例如当前时间函数。

基于行的复制 ： 使用单个的表行记录变化，而不是语句。主服务器将消息，也就是事件写入二进制日志，表示单个表行的变化。这与其他RDBMS中更加传统的复制方式类似。

优点：需要更少的锁定，意味着能够达到更高的并发。

缺点：它会产生更多需要记录的数据，占用的空间大。

混合模式日志 ： 可以根据要记录的事件实时改变二进制日志格式。使用混合模式复制时，默认采用基于语句的复制，但是在某些情况下自动切换到基于行的复制

1、函数必须指定返回值，且参数默认为IN类型。

2、存储过程没返回值，参数可以是 IN,OUT,IN OUT类型，有的人可能会理解成OUT 也算是返回值。

3、调用方式：函数 select my_fun() 过程 call my_pro( )

4、DEMO

---