hhdb数据库介绍(9-3)
计算节点运行相关
计算节点启动说明
- 启动计算节点,可以切换到/usr/local/hhdb/hhdb-server/bin目录下,再运行启动脚本,或者直接加上路径:sh /usr/local/hhdb/hhdb/bin/hotdb_server start;
- 配置库复制同步状态会影响计算节点启动,计算节点启动或者发生高可用切换Online时配置库必须保证复制追上;
- 存储节点复制同步状态会影响计算节点启动,通过在server.xml中配置参数waitSyncFinishAtStartup 的true/false属性控制计算节点启动时是否等待存储节点复制追上,默认需等待;
- 启动计算节点时,若存储节点连接状态异常,可通过修改server.xml中的配置参数masterSourceInitWaitTimeout,控制数据节点中主存储节点是否重新初始化及初始化超时时间,具体控制逻辑参考计算节点启动时对逻辑库可用的判断。
影响计算节点启动失败的原因可能是多种多样的,包括但不限于: - 软硬件环境异常:例如脚本校验无法通过,磁盘空间不足,可用内存不足,Java版本不匹配等
- 配置库异常:例如配置库无法连接,配置错误等
- 节点异常:例如数据节点无法正常连接或无法正常初始化等
- 授权异常:例如USB-Key服务异常,授权节点超出限制,授权过期等
- XA异常:例如XA RECOVER失败等
- 端口被占用:例如端口已被其他程序占用,或者启动了多个计算节点服务等
- 复制异常:例如配置了启动时等待复制追上,实际数据节点的复制一直存在延迟,无法追上等
- 集群异常:例如集群无法达成共识,启动时存在网络分区,各节点时间不同步等
计算节点启动时对逻辑库可用的判断
为保证垂直拆分场景下,出现数据节点不可用状态时,与之不相关的不同逻辑库之间的业务场景不受影响,计算节点在启动时,对所有逻辑库的可用状态做了特殊判断处理,说明如下:
-
若配置的主存储节点为可用状态,实际该存储节点无法连接,则计算节点启动时,会等待masterSourceInitWaitTimeout配置的时间(默认:300s),判断该存储节点是否真实不可连接,若在此期间,该存储节点重连无异常,则该节点初始化成功;
-
如果数据节点初始化失败且无可用逻辑库,或数据节点下无存储节点,则计算节点无法启动,日志提示:04/13 10:50:54.644 ERROR [main] (HotdbServer.java:436) -datanodes:[3] init failed. System exit.
-
只要存在某个逻辑库对应的数据节点均可用,则可以启动计算节点,对应逻辑下的表可以正常操作。如果其他逻辑库下有不可用的节点,则该逻辑库下的表不能正常读写,客户端提示:ERROR 1003 (HY000): DATABASE is unavailable when datanodes:[datanode_id] unavailable.
例如:A逻辑库包含1,2两个节点,B逻辑库包含3,4两个节点。如果1、2节点不可用,3、4节点可用,则计算节点可以启动,B逻辑库下的表可以正常操作,A逻辑库下的表无法进行读写;如果1、3节点不可用,则计算节点无法启动。
- 判断某个节点是否可用,跟存储节点在配置库的状态以及存储节点实际可用状态有关,要求配置状态与存储节点状态要一致,否则会影响计算节点的启动。计算节点启动时连接配置库配置的可用存储节点,如果均能连接,则视为可用。如果某个配置为可用的存储节点无法连接,且该数据节点下所有其他存储节点都配置为不可用或配置为可用但实则无法连接,则视为该数据节点不可用。每个节点至少应配置一个可用存储节点,否则无法启动计算节点。具体情况如下:
1.主从存储节点均配置为可用
如果主从存储节点均可以连接,则该节点可用。如果主库无法连接,从库可连接,则会发生切换,将主库置为不可用,并且使用从库。如果主库可以连接,从库无法连接,则使用主库,从库会置为不可用。如果主从数据库均无法连接,则该节点不可用。
2.主库配置不可用,从库配置可用
如果从库可以连接,则使用从库,此节点可用。如果从库无法连接,则该节点不可用
3.主库配置可用,从库配置不可用
如果主库可以连接,则使用主库,此节点可用。如果主库无法连接,则该节点不可用
存储节点服务端参数校验
为了保证数据的一致性,计算节点在启动的时候,将对存储节点实例的参数进行校验。针对不同的参数,如果参数配置不符合校验规则,计算节点将报告警告信息,或者不能启动。计算节点对存储节点实例的参数要求有两种:一种是所有的存储节点实例的参数需一致;另一种是所有的存储节点实例的参数必须为固定值。
要求设置为固定值的参数
对于下列存储节点实例的参数,计算节点要求设置为统一的固定值:
1.completion_type必须为NO_CHAN, 如果出现该参数不符合规范,则动态加载失败;
2.innodb_rollback_on_timeout需要为ON,且任何时候SHOW [GLOBAL|SESSION] VARIABLES显示出来的innodb_rollback_on_timeout参数都为on,说明如下:
-
如果innodb_rollback_on_timeout参数全为off, 则计算节点允许加载成功,但计算节点的行为将等同于innodb_rollback_on_timeout参数为on时的事务回滚方式,且配置校验时给出提示:
且动态加载时日志输出:innodb_rollback_on_timeout=off is not supported, HotDB behavior will be equivalent to innodb_rollback_on_timeout = on. -
如果innodb_rollback_on_timeout参数存储节点间不一致,动态加载失败,且动态加载时,为off的存储节点日志输出,MySQL variables ‘innodb_rollback_on_timeout’ is not consistent,the current value is OFF ,neet to bu changed to ON , 为on的存储节点日志输出MySQL variables ‘innodb_rollback_on_timeout’ is not consistent,the current value is ON
3.read_only,参数说明如下:
如果主存储节点的参数read_only=1,计算节点将拒绝启动,动态加载失败。
如果从机的参数read_only=1且配置了切换到该从机的配置规则,计算节点可以启动,RELOAD失败。
如果从机的参数read_only=1且没有配置切换到该从机的配置规则,计算节点可以启动,reload如果无其它错误则成功。
要求所有节点配置一致的参数
对于下列存储节点实例的参数,计算节点要求存储节点间的参数值设置为一致:
- autocommit
- transaction_isolation
- div_precision_increment
若以上参数在存储节点间配置不一致,计算节点将给出警告信息。对于transaction_isolation参数,计算节点以设置的最高隔离级别为准,若最高配置的值高于REPEATABLE-READ,将使用SERIALIZABLE;若最低配置的值低于REPEATABLE-READ,计算节点将使用REPEATABLE-READ模式。
要求不能超过计算节点配置的参数
考虑到客户端发送超大SQL会有威胁到计算节点的可能(目前尚未发现实际案例),计算节点可以配置MAX_ALLOWED_PACKET,控制客户端发送给计算节点的SQL最大包大小,该参数可在server.xml中通过参数名maxAllowedPacket预置,如果计算节点的maxAllowedPacket默认值大于1024M,日志会给warning提示,且管理平台配置校验会给出提示
管理端信息监控
HHDB Server为客户提供了一套功能完善、操作便捷的信息监控、统计与服务管理功能。用户可以通过MySQL Client登录计算节点的监控管理端查看详细信息,详细说明请参考计算节点管理命令文档。
管理端命令
用户可以登录管理端(默认端口:3325)使用show @@help命令查看支持的管理端命令和相应的作用。
root> mysql -uroot -proot -P3325 -h192.168.200.201
mysql: [Warning] Using a password on the command line interface can be insecure.
Welcome to the MySQL monitor. Commands end with ; or g.
Your MySQL connection id is 992081
Server version: 5.7.42 HHDB-14.0.0 HHDB Server
Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
mysql> show @@help;
+-------------------------------------------+------------------------------+
| statement | description |
+-------------------------------------------+------------------------------+
| check @@datasource_config | 检查存储节点参数配置信息 |
| check @@route [db_name.tb_name | tb_name] | 检测分片表数据路由正确性 |
| kill @@connection [connection_id] | 将某个指定的连接关闭 |
| onlineddl "[DDLSTATEMENT]" | 执行onlineddl |
| rebuild @@pool | 重建所有节点当前可用存储节点 |
| reload @@config | 重新读取配置信息 |
...省略更多内容,可自行登陆查看...
管理端操作
用户可以输入相应的命令以监控计算节点的服务情况,如显示存储节点信息:
mysql> show @@datasource;
|----+----+-----------------------+------+--------+-------------+------+--------+--------+------+------+--------------------+--------------+--------+-------------+-----------------+
| dn | ds | name | type | status | host | port | schema | active | idle | size | unavailable_reason | flow_control | idc_id | listener_id | listener_status |
| --- | --- | --------------------- | ---- | ------ | ----------- | ---- | ------ | ------ | ---- | ---- | ------------------ | ------------ | ------ | ----------- | --------------- |
| 17 | 17 | 10.10.0.140_3313_db01 | 1 | 1 | 10.10.0.140 | 3313 | db01 | 0 | 45 | 45 | NULL | 0/64 | 1 | 8 | 1 |
...省略更多内容,可自行登陆查看...
前端连接数限制
计算节点支持限制前端连接数功能,出现访问过载时可辅助限制流量。使用方法为:在server.xml中进行配置:
<property name="maxConnections">5000</property><!-- 前端最大连接数 -->
<property name="maxUserConnections">0</property><!--用户前端最大连接数, 0为不限制-->
- maxConnections为前端最大连接数,默认5000;
- maxUserConnections为前端最大用户连接数,默认0为不限制;
同时支持具有super权限的用户在服务端口set global max_connections=1; set global max_user_connections=0;进行修改。
可以用SHOW VARIABLES来查看当前的连接数限制情况。
后端连接池管理
计算节点启动及运行过程中会与存储节点之间建立连接,在添加存储节点时,可通过四个配置控制连接数:
- 最大连接数:计算节点与存储节点之间可建立的最大连接数,超过即SQL无法正常执行;
- 初始连接数:计算节点与存储节点之间建立的初始连接数;
- 最小空闲连接数:计算节点与存储节点之间建立的最小空闲连接数;
- 最大空闲连接数:计算节点与存储节点之间建立的最大空闲连接数。
当定时检测线程发现连接池里面空闲连接小于最小空闲,创建连接;大于最大空闲,关闭连接。即:最小空闲≤连接池的空闲连接个数≤最大空闲,最大、最小空闲连接数主要控制连接池内的空闲连接数在一定范围内。
例如:
以单个计算节点举例(多计算节点服务各自限制连接数,也即极端情况下,存储节点连接数可能达到N倍),存储节点配置: 最大连接数4200,初始化连接数是32, 最小空闲连接数64 ,最大空闲连接数:512
那么计算节点在启动的时候,会与每个存储节点建立32个后端连接,定时检测线程检测时发现当前连接数不够最小空闲即增加到最小空闲连接64个;
此时若有一个2048并发的场景对计算节点压测,会发现连接池可用连接数不够用,计算节点会自动增加与存储节点的连接数。
当压测结束后,这些连接不会立即销毁,会等到空闲检测周期检测:如果空闲状态(即管理端show @@backend标记为Idle状态)的连接大于512 ,则销毁多余的连接到512个;如果小于512 就保持原样。
若需要空闲连接状态回到初始化状态,可以在计算节点运行过程中,参考计算节点管理命令文档重建连接池rebuild @@pool 相关章节重建连接池,即恢复到初始连接状态。
磁盘空间使用限制
因磁盘空间不足会导致计算节点无法正常运行等诸多问题,计算节点在自动部署时会检测计算节点安装目录所在磁盘的剩余空间是否大于10G,同时,在写临时文件时也会检测磁盘的剩余空间,具体如下:
用户创建会话后执行例如复杂跨库JOIN等操作时,必要时会在计算节点安装目录下写入临时文件。写入临时文件的同时,计算节点若检测发现安装目录所在磁盘的剩余空间不足,则终止当前会话并报错与记录日志。
计算节点日志记录error级别日志如下,终止会话时提示信息与之相同:
2019-06-10 18:03:24.423 [ERROR] [DISKSPACE] [Employee-2] cn.hotpu.hotdb.mysql.nio.handler.MultiNodeHandler(88) - session[1606] was killed,due to less than 1G space left on device,and the size of temp-file is larger than the usable space.
etl用户(用于数据抽取)
配置了etl的用户较普通用户在数据抽取时可降低内存消耗,具有更高的稳定性和数据抽取效率,具体使用配置说明如下:
- 在管理平台数据库用户中添加用户
计算节点配置库添加用户为etl用户(etl_users和ETL用户列表为固定参数值,只需修改test_user@%)
insert into hotdb_config_info values('etl_users','test_user@%','ETL用户列表');
-
开启参数enableCursor,动态加载使配置生效
-
使用etl用户做数据导出(以mysqldump为例)
mysqldump -utest_user -pyy123456 -P3323 -h192.168.171.21 --set-gtid-purged=OFF --no-tablespaces --skip-triggers --single-transaction --default-character-set=utf8 --no-create-info --complete-insert --compact --skip-tz-utc hotdb customer_auto >/usr/local/etl_temp/etl_auto.sql
错误码
若要了解计算节点错误码详情,请参考计算节点错误码文档。
若要了解管理平台错误码详情,可以点击"帮助中心">>"API接口说明"页面中的【状态码】查看错误码详情。
动态加载(RELOAD)
计算节点可在不重启服务的情况下,在线加载配置信息。通过"动态加载"功能可立即生效的参数请参考计算节点参数说明。
动态加载有两种方式,一种是登录管理端(3325)执行:reload @@config命令;一种是登录管理平台,点击菜单栏右上角"动态加载"按钮,将新增配置项目动态加载到计算节点中进行使用。如下图所示:
为了保证计算节点正确加载配置信息,在执行动态加载前,可先校验配置信息。动态加载过程中,若遇到主备配置库、主备存储节点切换,提示用户并提供强制停止切换并动态加载和取消动态加载两种选择方案。
配置校验
登录管理平台,选择"配置"->配置校验进入配置校验面板,点击"开始校验"按钮,将校验关系集群数据库可视化管理平台中配置校验菜单中的配置项,若有配置项不正确,可根据错误提示,修改相应的配置:
通过计算节点管理端执行reload @@config命令动态加载时,默认也会先进行配置校验,校验通过后才允许动态加载。
死锁检测
在关系集群数据库系统中,若死锁发生在两个数据节点下的存储节点间,存储节点的死锁检测机制将无法检测到死锁。
下面表格中的操作,描述了两个数据节点产生死锁的过程。会话一与会话二分别在两个数据节点上执行DELETE操作:
会话一 | 会话二 | |
---|---|---|
会话一开启事务 | start transaction; | |
会话二开启事务 | start transaction; | |
会话一在DNID为15的数据节点上执行DELETE语句 | delete from customer where dnid=15 and id=1; | |
会话二在DNID为13的数据节点上执行DELETE 语句 | delete from customer where dnid=13 and id=4; | |
会话一在DNID为13的数据节点上执行DELETE语句;DELETE操作将被会话二阻塞 | delete from customer where dnid=13 and id=4; | |
会话二在DNID为15的数据节点上执行DELETE语句;此操作将被会话一阻塞;因会话一被会话二阻塞,会话二也被会话一阻塞,此时将产生死锁 | delete from customer where dnid=15 and id=1; |
上述情况中,会话一与会话二互相被阻塞,将产生死锁。因是在两个数据节点下的存储节点间,存储节点无法检测到死锁的存在。
在HHDB Server关系集群数据库系统中,计算节点可检测到多个数据节点下的存储节点间的死锁,并回滚开销最少的事务。
在计算节点的配置文件server.xml中,将死锁检测周期设置为大于0的值,将开启死锁的自动检测功能。默认情况下,死锁检测是开启状态,检测周期为3000ms。
<property name=" deadlockCheckPeriod ">3000</property>
当deadlockCheckPeriod值设置为0时,将不启动死锁检测功能。
在开启计算节点的死锁检测时,再次执行上述的DELETE操作:
会话一,开启事务:
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
会话二,开启事务:
mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)
会话一,在DNID为15的数据节点上执行DELETE语句:
mysql> delete from customer where dnid=15 and id=1;
Query OK, 1 row affected (0.00 sec)
会话二,在DNID为13的数据节点上执行DELETE 语句
mysql> delete from customer where dnid=13 and id=4;
Query OK, 1 row affected (0.00 sec)
会话一,在DNID为13的数据节点上执行DELETE语句;DELETE操作将被会话二阻塞:
mysql> delete from customer where dnid=13 and id=4;
会话二,在DNID为15的数据节点上执行DELETE语句;此操作将被会话一阻塞;因会话一被会话二阻塞,会话二也被会话一阻塞,此时将产生死锁。
mysql> delete from customer where dnid=15 and id=1;
Query OK, 1 row affected (1.59 sec)
计算节点检测到死锁,回滚了会话一的事务:
mysql> delete from customer where dnid=13 and id=4;
ERROR 1213 (HY000): Deadlock found when trying to get lock; try restarting transaction
注意
由于存储节点5.7及以上版本,事务中出现死锁回滚后,不会立即开启新事务。参考官方BUG链接:https://bugs.mysql.com/bug.php?id=98133。HHDB
Server针对上述BUG做了兼容处理:对锁超时、死锁检测、后端连接断开,存储节点5.7及以上版本会根据前端连接autocommit判断是否要开启新事务。
SQL报错日志记录
若执行SQL时返回以下情况的报错信息,计算节点会将其记录到计算节点日志(hotdb-unusualsql.log)中:
- 主键唯一键冲突或外键约束不满足导致的ERROR信息(即存储节点错误码1062、1216、1217、1451、1452、1557、1761、1762、3008)
- 数据溢出(即存储节点错误码1264、1690、3155、3669)和数据类型转换或隐式转换导致数据截断(即存储节点错误码1265、1292、1366)的情况
- 涉及binlog不安全语句(即存储节点错误码1418、1592、1663、1668、1669、1671、1673、1674、1675、1693、1714、1715、1716、1719、1722、1724、1727、1785、3006、3199、3570、3571、MY-010908、MY-013098)
- 对分片字段不是自增字段的分片表做INSERT操作时,由外部指定自增值的INSERT的情况
- UPDATE语句中出现MATCH和AFFECT不相符的情况
- DELETE出现删除0行的情况
- UPDATE或DELETE AFFECT超过10000行的情况
- 在HINT语句中使用了INSERT、UPDATE、DELETE和DDL语句的情况
- DDL语句执行出现报错信息的情况;除此之外,在以下两种情况下会有额外日志记录:1. CREATE TABLE或ALTER TABLE时指定的表的字符集或字段的字符集,与存储节点的字符集或连接使用的字符集不一致时;2. CREATE TABLE或ALTER TABLE分片表,主键或唯一键不包含分片字段,且没有使用全局唯一约束来保证字段唯一性时
- 发生部分提交的情况,即部分节点已经发出COMMIT后,其余节点没有发出COMMIT但连接断开的情况,或其余部分后端连接发出COMMIT后无响应且连接断开的情况,会记录整个事务到计算节点日志
- 发生语法错误的情况
- 执行因缺少路由规则无法路由的SQL的情况,例如INSERT不存在的ROUTE规则
- 执行被SQL防火墙拦截的SQL的情况
- 执行超时的SQL的情况
- 发生死锁被杀的事务的情况
- 发生因存储节点切换等原因被杀掉的事务的情况
- 执行锁超时回滚的SQL的情况
- 执行KILL命令后KILL掉的SQL的情况
- 发生被ROLLBACK的SQL的情况
- 前端连接异常断开回滚的SQL的情况
- 后端连接异常断开或其它异常导致回滚的情况
- 计算节点意外抛异常的情况
如果上述记录的SQL过长导致SQL语句被截取,还会额外记录WARNING信息
例如,执行一条出现主键冲突的SQL如下:
mysql> insert into table01 (id,title,author,submission_date) values (3,"apple", "apple pie", '2019-10-11-20-05');
ERROR 1062 (23000): Duplicate entry '3' for key 'PRIMARY'
查看计算节点日志(hotdb-unusualsql.log):
2019-10-12 15:27:45.051 [INFO] **[UNUSUALSQL]** [$NIOREACTOR-7-RW] cn.hotpu.hotdb.mysql.nio.MySQLConnection(415) - ERROR 1062:Duplicate entry '3' for key 'PRIMARY' [frontend:[thread=$NIOREACTOR-7-RW,id=453,user=root,host=192.168.210.225,port=3323,localport=65442,schema=DBY]; backend:null; frontend_sql:insert into table01 (id,title,author,submission_date) values (3,"apple", "apple pie", '2019-10-11-20-05');backend_sql:null]
又如,执行一条被SQL防火墙拦截SQL如下:
mysql> select * from test;
ERROR 1064 (HY000): Intercepted by sql firewall, because: not allowed to execute select without where expression
查看计算节点日志(hotdb-unusualsql.log):
2019-10-14 15:41:42.246 [INFO] **[UNUSUALSQL]** [$NIOExecutor-1-2] cn.hotpu.hotdb.route.RouteService(415) - ERROR 10029:not pass sql firewall [frontend:[thread=$NIOExecutor-1-2,id=1433,user=root,host=192.168.210.225,port=3323,localport=64658,schema=DBY]; backend:null; frontend_sql:null; backend_sql:null] [DBY.count]=33
注意
存储节点错误码解释可参考官方文档:https://dev.mysql.com/doc/refman/8.0/en/server-error-reference.html
该类日志信息默认保存在计算节点安装目录logs/extra/unusualsql目录下的hotdb_unusualsql.log文件中。若日志未记录至文件,可检查计算节点安装目录conf目录下的log4j2.xml下,是否存在以下配置:
<RollingFile
name="Unusualsql"
filename="${sys:HOTDB_HOME}/logs/extra/unusualsql/hotdb-unusualsql.log"
filepattern="${sys:HOTDB_HOME}/logs/extra/unusualsql/hotdb-unusualsql-%d{yyyy-MM-dd-HH-mm-ss}.log">
<PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-4p] [%marker] [%t] %c(%L) - %msg%n"/>
<Policies>
<SizeBasedTriggeringPolicy size="100 MB"/>
</Policies>
<!-- 只记录unusual sql日志 -->
<filters>
<MarkerFilter marker="UNUSUALSQL" onMatch="ACCEPT" onMismatch="DENY"></MarkerFilter>
</filters>
<DefaultRolloverStrategy max="1000"/>
</RollingFile>
</Appenders>
<Loggers>
<Root level="info">
<AppenderRef ref="Unusualsql"/>
</Root>
</Loggers>
只读计算节点实例
计算节点支持开启只读模式(instanceReadOnly)来平衡当前主计算节点的压力,或使用只读计算节点实例抽取数据做数据分析,一般适用于备计算节点或灾备模式下的灾备机房计算节点。
计算节点开启只读方式
修改server.xml中的instanceReadOnly为1开启只读计算节点,重启计算节点后生效
管理端执行online_readonly直接开启计算节点只读模式,online_readwrite可直接关闭计算节点只读模式
root@192.168.210.79:(none) 8.0.30 03:50:51> online_readonly;
Query OK, 1 row affected, 1 warning (0.03 sec)
Info (Code 10260): Online_readOnly command executed successfully and the instanceReadOnly parameter has been set to 1.
online_readwrite命令在HA模式下等同于online,在灾备模式主节点下相当于online_dr,会导致计算节点高可用切换或机房切换,业务需谨慎使用
可通过show @@server接口中的mode字段查看是否开启了只读
开启只读的计算节点服务端只可执行DQL语句、SET会话级参数、show语句等;管理端涉及写操作的命令都不能执行,如全局表一致性修复、kill @@connection、stop @@heartbeat等操作,如:
服务端操作:
root@192.168.210.79:hotdb 8.0.30 04:24:51> create database test;
ERROR 1289 (HY000): Command CREATE_DATABASE not allowed in Read-Only mode.
root@192.168.210.79:hotdb 8.0.30 04:24:56> create table test(id int);
ERROR 1289 (HY000): Command CREATE_TABLE not allowed in Read-Only mode.
root@192.168.210.79:hotdb 8.0.30 04:25:02> insert into test values(1);
ERROR 1289 (HY000): Command INSERT not allowed in Read-Only mode.
管理端操作:
root@192.168.210.79:(none) 8.0.30 04:27:24> reload @@config;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
root@192.168.210.79:(none) 8.0.30 04:27:27> stop @@heartbeat;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
root@192.168.210.79:(none) 8.0.30 04:27:40> kill @@connection 11;
ERROR 10234 (HY000): Not allowed to execute non-query command in readonly instance.
普通模式下(含灾备模式的中心机房)只读计算节点默认读优先级最高的从库,优先级最高的从库不可用或从库复制延迟大于maxLatencyForReadOnly的值时,读次优先级的从库,从库都不可用则读主库
灾备模式的灾备机房只读计算节点读灾备机房的主库,主库不可用时拒绝读取
特定场景下的只读模式释放
- HA模式下,计算节点发生高可用切换会释放备的只读属性
- 灾备模式下,发生机房切换后,灾备机房当前主会释放只读属性
事务内开启只读,未结束的事务依旧可以读写,直到事务提交/回滚/超时
多计算节点集群只读模式下,开启参数allowReadConsistentInReadOnly、enableListener和enableXA且部署了监听组件后,可保证读一致性
计算节点实例级别的只读模式读从库的优先级高于用户级别的读写分离
主备模式下备计算节点若开启只读,则每10秒去主上同步最新配置信息;也可通过配置计算节点的集群参数实时同步配置(serverId、clusterSize、clusterNetwork、clusterHost、clusterPort)
集群模式下,只读计算节点不参与选主。如:备计算节点均开启了只读,主计算节点故障后会因无法选主导致集群不可用(仅管理端口可连接)
HA模式下开启只读计算节点需要手动将keepalived脚本check_hotdb_process.sh中的online改为online_readwrite,否则高可用切换后,不会释放只读属性
主计算节点不建议设置为只读模式,reload会跳过只读计算节点实例,主计算节点开启只读可能会对业务造成影响