KingbaseES V8R3集群运维案例之---主库系统down failover切换过程分析
案例说明：
KingbaseES V8R3集群failover时两个cluster都会触发，但只有一个cluster会调用脚本去执行真正的切换流程，另一个有对应的打印，但不会调用脚本，只是走相关的流程去修改状态。 那么你需要确认一点，到底是主库还是备库的cluster在执行脚本，关键字：failover_stream.sh ，看cluster.log中有没有这个的名称。本案例通过主库系统宕机，分析了failover 切换过程。
适用版本：
KingbaseES V8R3
集群节点状态信息：
# 集群节点状态信息
TEST=# show pool_nodes;
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_delay
---------+---------------+-------+--------+-----------+---------+------------+-------------------+-------------------
0 | 192.168.1.101 | 54321 | up | 0.500000 | primary | 1 | true | 0
1 | 192.168.1.102 | 54321 | up | 0.500000 | standby | 0 | false | 0
(2 rows)
对于KingbaseES V8R3集群failover切换的分析：
1. 可以通过主备库的cluster.log，获取整个主备切换的过程。
2. 从failover.log日志中获取执行failover过程，注意只有执行failover_stream.sh的节点才会产生failover.log。
3. recovery.log日志记录了原主库failover完成后，从主库recovery为新备库的过程。
一、Failover切换过程分析
关闭主库系统：
[root@node101 ~]# shutdown -h now
备库cluster.log日志分析：（主库系统关机，备库调用failover_stream.sh执行failover切换）
1、主备库处于正常状态时，备库收到主库的heartbeat。
2022-08-30 15:38:03: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 0 seconds ago
2022-08-30 15:38:06: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:38:06: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 0 seconds ago
2、备库kingbasecluster检测到主库集群服务和数据库服务shutdown，kingbasecluster发生主备切换，当前的kingbasecluster由standby切换为master。
2022-08-30 15:38:09: pid 17585: LOG: remote node "192.168.1.101:9999 Linux node101" is shutting down
2022-08-30 15:38:09: pid 17585: LOG: watchdog cluster has lost the coordinator node
2022-08-30 15:38:09: pid 17585: LOG: unassigning the remote node "192.168.1.101:9999 Linux node101" from watchdog cluster master
2022-08-30 15:38:09: pid 17585: LOG: We have lost the cluster master node "192.168.1.101:9999 Linux node101"
2022-08-30 15:38:09: pid 17585: LOG: watchdog node state changed from [STANDBY] to [JOINING]
2022-08-30 15:38:09: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:38:09: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 1 seconds ago
2022-08-30 15:38:10: pid 17547: ERROR: failed to authenticate
2022-08-30 15:38:10: pid 17547: DETAIL: the database system is shutting down
2022-08-30 15:38:12: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:38:12: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 4 seconds ago
3、备库kingbasecluster对主库的数据库服务根据：health_check_max_retries * health_check_retry_delay配置尝试连接。
2022-08-30 15:38:13: pid 17547: LOG: health checking retry count 1
2022-08-30 15:38:13: pid 17585: LOG: watchdog node state changed from [JOINING] to [INITIALIZING]
2022-08-30 15:38:14: pid 17585: LOG: I am the only alive node in the watchdog cluster
2022-08-30 15:38:14: pid 17585: HINT: skipping stand for coordinator state
2022-08-30 15:38:14: pid 17585: LOG: watchdog node state changed from [INITIALIZING] to [MASTER]
2022-08-30 15:38:14: pid 17585: LOG: I am announcing my self as master/coordinator watchdog node
2022-08-30 15:38:15: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:38:15: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 7 seconds ago
2022-08-30 15:38:18: pid 17585: LOG: I am the cluster leader node
2022-08-30 15:38:18: pid 17585: DETAIL: our declare coordinator message is accepted by all nodes
2022-08-30 15:38:18: pid 17585: LOG: setting the local node "192.168.1.102:9999 Linux node102" as watchdog cluster master
4、备库开启升级进程（escalation process），cluster vip漂移到新的master节点。
2022-08-30 15:38:18: pid 17585: LOG: I am the cluster leader node. Starting escalation process
2022-08-30 15:38:18: pid 17585: LOG: escalation process started with PID:22088
2022-08-30 15:38:18: pid 17547: LOG: connect_inet_domain_socket: select() interrupted by certain signal. retrying...
2022-08-30 15:38:18: pid 22088: LOG: watchdog: escalation started
2022-08-30 15:38:18: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:38:18: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 10 seconds ago
2022-08-30 15:38:21: pid 22088: LOG: successfully acquired the delegate IP:"192.168.1.201"
2022-08-30 15:38:21: pid 22088: DETAIL: 'if_up_cmd' returned with success
.......
5、 备库对原主库数据库服务的连接次数超过阈值后，将原主库的数据库服务设置为down状态。
2022-08-30 15:39:20: pid 17547: LOG: health checking retry count 10
2022-08-30 15:39:22: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:39:22: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 73 seconds ago
2022-08-30 15:39:23: pid 17547: LOG: failed to connect to kingbase server on "192.168.1.101:54321", getsockopt() detected error "
No route to host"
2022-08-30 15:39:23: pid 17547: ERROR: failed to make persistent db connection
2022-08-30 15:39:23: pid 17547: DETAIL: connection to host:"192.168.1.101:54321" failed
2022-08-30 15:39:23: pid 17547: LOG: setting backend node 0 status to NODE DOWN
6、 收到本节点kingbasecluster发出的failover request，并获取到failover lock。
2022-08-30 15:39:23: pid 17547: LOG: received degenerate backend request for node_id: 0 from pid [17547]
2022-08-30 15:39:23: pid 17585: LOG: new IPC connection received
2022-08-30 15:39:23: pid 17585: LOG: watchdog received the failover command from local kingbasecluster on IPC interface
2022-08-30 15:39:23: pid 17585: LOG: watchdog is processing the failover command [DEGENERATE_BACKEND_REQUEST] received from local
kingbasecluster on IPC interface
2022-08-30 15:39:23: pid 17585: LOG: I am the only kingbasecluster node in the watchdog cluster
2022-08-30 15:39:23: pid 17585: DETAIL: no need to propagate the failover command [DEGENERATE_BACKEND_REQUEST]
2022-08-30 15:39:23: pid 17585: LOG: new IPC connection received
2022-08-30 15:39:23: pid 17585: LOG: received the failover command lock request from local kingbasecluster on IPC interface
2022-08-30 15:39:23: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" is requesting to become a lock
holder for failover ID: 0
7、 获取到failover lock后，开始执行failover_stream.sh进行failover的切换。
2022-08-30 15:39:23: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" is the lock holder
2022-08-30 15:39:23: pid 17547: LOG: starting degeneration. shutdown host 192.168.1.101(54321)
2022-08-30 15:39:23: pid 17547: LOG: Restart all children
2022-08-30 15:39:23: pid 17547: LOG: execute command: /home/kingbase/cluster/R3HA/kingbasecluster/bin/failover_stream.sh 192.168.
1.102 0 0 192.168.1.101 192.168.1.101 1 0 /home/kingbase/cluster/R3HA/db/data
2022-08-30 15:39:25: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:39:25: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 76 seconds ago
ssh: connect to host 192.168.1.101 port 22: No route to host
2022-08-30 15:39:31: pid 17612: LOG: watchdog checking if kingbasecluster is alive using heartbeat
2022-08-30 15:39:31: pid 17612: DETAIL: the last heartbeat from "192.168.1.101:9999" received 82 seconds ago
2022-08-30 15:39:33: pid 17585: LOG: new IPC connection received
2022-08-30 15:39:33: pid 17585: LOG: received the failover command lock request from local kingbasecluster on IPC interface
2022-08-30 15:39:33: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" is requesting to release [FAIL
OVER] lock for failover ID 0
8、执行failover切换，并查找新的primary。（当前备库切换为primary）
2022-08-30 15:39:33: pid 17547: LOG: find_primary_node_repeatedly: waiting for finding a primary node
2022-08-30 15:39:33: pid 17547: LOG: find_primary_node: checking backend no 0
2022-08-30 15:39:33: pid 17547: LOG: find_primary_node: checking backend no 1
2022-08-30 15:39:33: pid 17547: LOG: find_primary_node: primary node id is 1
2022-08-30 15:39:33: pid 17585: LOG: new IPC connection received
2022-08-30 15:39:33: pid 17585: LOG: received the failover command lock request from local kingbasecluster on IPC interface
2022-08-30 15:39:33: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" is requesting to release [FOLL
OW MASTER] lock for failover ID 0
2022-08-30 15:39:33: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" has released the [FOLLOW MASTE
R] lock for failover ID 0
2022-08-30 15:39:33: pid 17547: LOG: failover: set new primary node: 1
2022-08-30 15:39:33: pid 17547: LOG: failover: set new master node: 1
2022-08-30 15:39:33: pid 21501: LOG: worker process received restart request
2022-08-30 15:39:33: pid 17585: LOG: new IPC connection received
2022-08-30 15:39:33: pid 17585: LOG: received the failover command lock request from local kingbasecluster on IPC interface
2022-08-30 15:39:33: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" is requesting to resign from a
lock holder for failover ID 0
2022-08-30 15:39:33: pid 17585: LOG: local kingbasecluster node "192.168.1.102:9999 Linux node102" has resigned from the lock hol
der
failover done. shutdown host 192.168.1.101(54321)2022-08-30 15:39:33: pid 17547: LOG: failover done. shutdown host 192.168.1.101(
54321)
备库Failover.log分析：
1、执行failover_stream.sh进行failover切换
-----------------2022-08-30 15:39:23 failover beging---------------------------------------
----failover-stats is %H = hostname of the new master node [192.168.1.102], %P = old primary node id [0], %d = node id[0], %h = host name [192.168.1.101], %O = old primary host[192.168.1.101] %m = new master node id [1], %M = old master node id [0], %D = database cluster path [/home/kingbase/cluster/R3HA/db/data].
Tips：
1）new_master : 192.168.1.102
2) new_master_id: 1
3) old_primary: 192.168.1.101
4) old_primary_id : 0
2、ping 网关测试网络连通性
----ping trust ip
ping trust ip 192.168.1.1 success
3、ssh连接远程原主库，执行关闭数据库服务和释放db vip；并将db vip加载到当前主库节点。
----determine whether the faulty db is master or standby
master down, let 192.168.1.102 become new primary.....
2022-08-30 15:39:25 del old primary VIP on 192.168.1.101
ssh connect host:192.168.1.101 failed, can not stop old primary db and del old primary db vip
2022-08-30 15:39:29 add VIP on 192.168.1.102
ADD VIP NOW AT 2022-08-30 15:39:30 ON enp0s3
execute: [/sbin/ip addr add 192.168.1.200/24 dev enp0s3 label enp0s3:2]
execute: /home/kingbase/cluster/R3HA/db/bin/arping -U 192.168.1.200 -I enp0s3 -w 1
ARPING 192.168.1.200 from 192.168.1.200 enp0s3
Sent 1 probes (1 broadcast(s))
Received 0 response(s)
2022-08-30 15:39:31 promote begin...let 192.168.1.102 become master
4、通过连接db vip执行“select 33333”测试当前数据库服务状态，如果正常，执行promote，提升为新主库，将同步模式设为async。
check db if is alive
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2022-08-30 15:39:31 kingbase is ok , to prepare execute promote
execute promote
server promoting
check db if is alive after promote
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2022-08-30 15:39:32 after execute promote , kingbase status is ok.
after execute promote, kingbase is ok.
2022-08-30 15:39:32 sync to async
ALTER SYSTEM
SYS_RELOAD_CONF
-----------------
t
(1 row)
5、连接新主库数据库服务，如果成功，在新主库上执行checkpoint，checkpoint成功，则failover切换完成。
2022-08-30 15:39:32 make checkpoint
check the db to see if it is alive
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2022-08-30 15:39:32 kingbase is ok , to prepare execute checkpoint
execute checkpoint
CHECKPOINT
check the db to see if it is alive after execute checkpoint
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
2022-08-30 15:39:33 after execute checkpoint, kingbase is ok.
after execute checkpoint, kingbase is ok.
-----------------2022-08-30 15:39:33 failover end---------------------------------------
二、原主库recovery为新备库
1、在原主库生成recovery.conf文件（系统通过crond计划任务，调用network_rewind.sh脚本自动recovery为备库）
[kingbase@node101 data]$ cp ../etc/recovery.done ./recovery.conf
2、查看recovery.log日志信息
[kingbase@node101 log]$ more recovery.log
---------------------------------------------------------------------
1）开启recovery，检测存储读写功能是否正常。
2022-08-30 16:42:01 recover beging...
my pid is 11927,officially began to perform recovery
2022-08-30 16:42:01 check read/write on mount point
2022-08-30 16:42:01 check read/write on mount point (1 / 6).
2022-08-30 16:42:01 stat the directory of the mount point "/home/kingbase/cluster/R3HA/db/data" ...
2022-08-30 16:42:01 stat the directory of the mount point "/home/kingbase/cluster/R3HA/db/data" ... OK
2022-08-30 16:42:01 create/write the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ...
2022-08-30 16:42:01 create/write the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ... OK
2022-08-30 16:42:01 stat the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ...
2022-08-30 16:42:01 stat the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ... OK
2022-08-30 16:42:01 read the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ...
2022-08-30 16:42:01 read the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ... OK
2022-08-30 16:42:01 delete the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ...
2022-08-30 16:42:01 delete the file "/home/kingbase/cluster/R3HA/db/data/rw_status_file_574940445" ... OK
2022-08-30 16:42:01 success to check read/write on mount point (1 / 6).
2022-08-30 16:42:01 check read/write on mount point ... ok
2）ping 网关检测网络的连通性
2022-08-30 16:42:01 check if the network is ok
ping trust ip 192.168.1.1 success ping times :[3], success times:[2]
3）判断当前节点role（master OR standby）,如果是standby节点，并判断是否需要recovery。（ I,m status is [1] (1 is down), I will be in recovery.）
determine if i am master or standby
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_delay
---------+---------------+-------+--------+-----------+---------+------------+-------------------+-------------------
0 | 192.168.1.101 | 54321 | down | 0.500000 | standby | 0 | false | 0
1 | 192.168.1.102 | 54321 | up | 0.500000 | primary | 0 | true | 0
(2 rows)
i am standby in cluster,determine if recovery is needed
2022-08-30 16:42:03 now will del vip [192.168.1.200/24]
but no 192.168.1.200/24 on my DEV, nothing to do with del
ksql execute success,but node:node101 does not have correct streaming(or catchup) replication ,will retry ,retry times:[1/10]
......
ksql execute success,but node:node101 does not have correct streaming(or catchup) replication ,will retry ,retry times:[10/10]
primary node/Im node status is changed, primary ip[192.168.1.102], recovery.conf NEED_CHANGE [0] (0 is need ), I,m status is [1] (1 is down), I will be in recovery.
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_delay
---------+---------------+-------+--------+-----------+---------+------------+-------------------+-------------------
0 | 192.168.1.101 | 54321 | down | 0.500000 | standby | 0 | false | 0
1 | 192.168.1.102 | 54321 | up | 0.500000 | primary | 0 | true | 0
(2 rows)
4）如果需要做recovery，执行sys_rewind。
if recover node up, let it down , for rewind
2022-08-30 16:42:34 sys_rewind...
sys_rewind --target-data=/home/kingbase/cluster/R3HA/db/data --source-server="host=192.168.1.102 port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST"
datadir_source = /home/kingbase/cluster/R3HA/db/data
rewinding from last common checkpoint at 0/66000028 on timeline 15
find last common checkpoint start time from 2022-08-30 16:42:34.727711 CST to 2022-08-30 16:42:34.839545 CST, in "0.111834" seconds.
reading source file list
reading target file list
reading WAL in target
Rewind datadir file from source
update the control file: minRecoveryPoint is '0/68024E80', minRecoveryPointTLI is '16', and database state is 'in archive recovery'
rewind start wal location 0/66000028 (file 0000000F0000000000000066), end wal location 0/68024E80 (file 000000100000000000000068). time from 2022-08-30 16:42:36.727711 CST to 2022-08-30 16:42:37.201678 CST, in "2.473967" seconds.
Done!
5）sys_rewind成功，修改集群配置文件。
sed conf change #synchronous_standby_names
2022-08-30 16:42:39 file operate
cp recovery.conf...
change recovery.conf ip -> primary.ip
2022-08-30 16:42:39 no need change recovery.conf, primary node is 192.168.1.102
6）启动新备库数据库服务，删除原复制槽并重建。备库数据库服务启动成功后，配置同步为sync。
delete pid file if exist
del the replication_slots if exis
drop the slot [slot_node101].
drop the slot [slot_node102].
2022-08-30 16:42:39 start up the kingbase...
waiting for server to start....LOG: redirecting log output to logging collector process
HINT: Future log output will appear in directory "/home/kingbase/cluster/R3HA/db/data/sys_log".
done
server started
ksql "port=54321 user=SUPERMANAGER_V8ADMIN dbname=TEST connect_timeout=10" -c "select 33333;"
SYS_CREATE_PHYSICAL_REPLICATION_SLOT
--------------------------------------
(slot_node101,)
(1 row)
2022-08-30 16:42:41 create the slot [slot_node101] success.
SYS_CREATE_PHYSICAL_REPLICATION_SLOT
--------------------------------------
(slot_node102,)
(1 row)
2022-08-30 16:42:41 create the slot [slot_node102] success.
2022-08-30 16:42:41 start up standby successful!
cluster is sync cluster.
SYNC RECOVER MODE ...
2022-08-30 16:42:41 remote primary node change sync
ALTER SYSTEM
SYS_RELOAD_CONF
-----------------
t
(1 row)
SYNC RECOVER MODE DONE
7）执行pcp_attach_node将当前节点加入到集群。
2022-08-30 16:42:44 attach pool...
IM Node is 0, will try [pcp_attach_node -U kingbase -W MTIzNDU2 -h 192.168.1.201 -n 0]
pcp_attach_node -- Command Successful
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_delay
---------+---------------+-------+--------+-----------+---------+------------+-------------------+-------------------
0 | 192.168.1.101 | 54321 | up | 0.500000 | standby | 0 | false | 0
1 | 192.168.1.102 | 54321 | up | 0.500000 | primary | 0 | true | 0
(2 rows)
2022-08-30 16:42:45 attach end..
recovery success,exit script with success
三、总结
通过对原主库执行系统重启服务，如果备库在阈值范围内尝试连接主库数据库服务失败，其failover切换过程和主库系统shutdown是一致的。
KingbaseES V8R3集群运维案例之---主库系统down failover切换过程分析的更多相关文章
- KingbaseES V8R3集群运维案例之---用户自定义表空间管理
案例说明: KingbaseES 数据库支持用户自定义表空间的创建,并建议表空间的文件存储路径配置到数据库的data目录之外.本案例复现了,当用户自定义表空间存储路径配置到data下时,出现的故障问 ...
- KingbaseES V8R3集群管理维护案例之---集群迁移单实例架构
案例说明: 在生产中,需要将KingbaseES V8R3集群转换为单实例架构,可以采用以下方式快速完成集群架构的迁移. 适用版本: KingbaseES V8R3 当前数据库版本: TEST=# s ...
- KingbaseES V8R3集群管理和维护案例之---failover切换wal日志变化分析
案例说明: 本案例通过对KingbaseES V8R3集群failover切换过程进行观察,分析了主备库切换后wal日志的变化,对应用者了解KingbaseES V8R3(R6) failover ...
- KingbaseES V8R3集群维护案例之---在线添加备库管理节点
案例说明: 在KingbaseES V8R3主备流复制的集群中 ,一般有两个节点是集群的管理节点,分为master和standby:如对于一主二备的架构,其中有两个节点是管理节点,三个数据节点:管理节 ...
- PB 级大规模 Elasticsearch 集群运维与调优实践
PB 级大规模 Elasticsearch 集群运维与调优实践 https://mp.weixin.qq.com/s/PDyHT9IuRij20JBgbPTjFA | 导语 腾讯云 Elasticse ...
- 集群运维ansible
ssh免密登录 集群运维 生成秘钥,一路enter cd ~/.ssh/ ssh-keygen -t rsa 讲id_rsa.pub文件追加到授权的key文件中 cat ~/.ssh/id_rsa.p ...
- 阿里巴巴大规模神龙裸金属 Kubernetes 集群运维实践
作者 | 姚捷(喽哥)阿里云容器平台集群管理高级技术专家 本文节选自<不一样的 双11 技术:阿里巴巴经济体云原生实践>一书,点击即可完成下载. 导读:值得阿里巴巴技术人骄傲的是 2019 ...
- kingbaseES V8R6集群备份恢复案例之---备库作为repo主机执行物理备份
案例说明: 此案例是在KingbaseES V8R6集群环境下,当主库磁盘空间不足时,执行sys_rman备份,将集群的备库节点作为repo主机,执行备份,并将备份存储在备库的磁盘空间. 集群架构 ...
- KingbaseES V8R6集群外部备份案例
案例说明: 本案例采用sys_backup.sh执行物理备份,备份使用如下逻辑架构:集群采用CentOS 7系统,repo采用kylin V10 Server. 一主一备+外部备份 此场景为主备双机常 ...
随机推荐
- JavaScript写倒计时
在网页中,特别是电商网站中,倒计时的出现频率很高,接下来给大家介绍一下怎么用JavaScript写一个倒计时.代码如下: 首先我们通过Date构造函数的方法创建一个倒计时的结束的时间.并将其转换为毫秒 ...
- 全新升级的AOP框架Dora.Interception[4]: 基于Lambda表达式的拦截器注册方式
如果拦截器应用的目标类型是由自己定义的,Dora.Interception(github地址,觉得不错不妨给一颗星)可以在其类型或成员上标注InterceptorAttribute特性来应用对应的拦截 ...
- SpringBoot 整合文件上传 elment Ui 上传组件
SpringBoot 整合文件上传 elment Ui 上传组件 本文章记录 自己学习使用 侵权必删! 前端代码 博主最近在学 elment Ui 所以 前端使用 elmentUi 的 upload ...
- flex大法：一网打尽所有常见布局
flex全称Flexible Box模型,顾名思义就是灵活的盒子,不过一般都叫弹性盒子,所有PC端及手机端现代浏览器都支持,所以不用担心它的兼容性,有了这玩意,妈妈再也不用担心我们的布局. 先简单介绍 ...
- Spring框架系列(14) - SpringMVC实现原理之DispatcherServlet处理请求的过程
前文我们有了IOC的源码基础以及SpringMVC的基础,我们便可以进一步深入理解SpringMVC主要实现原理,包含DispatcherServlet的初始化过程和DispatcherServlet ...
- EEPROM存储电路（M24C64芯片）
电可擦写可编程只读存储器(Electrically Erasable Programmable Read-only Memory, EEPROM)实现掉电情况下保存数据,设计温湿度变送器采用M24C6 ...
- CSS进阶内容—浮动和定位详解
CSS进阶内容-浮动和定位详解 我们在学习了CSS的基本知识和盒子之后,就该了解一下网页的整体构成了 当然如果没有学习之前的知识,可以到我的主页中查看之前的文章:秋落雨微凉 - 博客园 CSS的三种布 ...
- .NetCore|.Net6 gRPC服务开发及本地调试
前言 最近在项目中实装应用了gRPC技术,本着能把技术描述出来给别人能看的懂的思想及作为自己学习笔记的心态编写了此文.因为在实际项目中是webApi接口和gRPC接口使用在同一项目服务中,所以本文的例 ...
- 构建 API 的7个建议【翻译】
迄今为止,越来越多的企业依靠API来为客户提供服务,以确保竞争的优势和业务可见性.出现这个情况的原因是微服务和无服务器架构正变得越来越普遍,API作为其中的关键节点,继承和承载了更多业务. 在这个前提 ...
- jdbc 12: 悲观锁
jdbc连接mysql,简单演示行级锁 通过debug模式进行演示 在Test1程序设置断点,让程序1,查询并锁定数据,且程序不执行完(此时停在debug断点处) 这时启动Test2程序,去修改已经被 ...