openGauss数据库日志管理指导-低调大师

openGauss数据库日志管理指导

2022-02-13 878

本文介绍openGauss数据库日志相关内容和管理方法，了解openGauss数据库中日志管理的内容，并对数据库进行日常管理维护、问题定位和数据库恢复的操作。

环境说明

组网说明
本实验环境为openGauss数据库管理系统，安装在华为云openEuler弹性服务器ECS上。

设备介绍
为了满足数据库原理与实践课程实验需要，建议每套实验环境软件版本采用以下配置：

设备名称	设备型号	软件版本
数据库	openGauss	openGauss 1.1.0
操作系统	openEuler	openEuler 20.3LTS

概览

1.日志管理

1.1实验介绍

1.1.1 关于本实验
在实际的数据库管理工作中，小数据量的日志可以按照实验手册，使用cat查看。但需要注意的是，生产环境的日志量可能比较多，日志文件容量经常在GB级别左右，为了提升读取日志的有效性，一般建议使用more、tail、grep等命令查看日志，所以学会这些命令的基本使用方法也是必须的。另外，在生产环境节点较多（成千上万个生产节点）、日志类型较复杂的情况下，人工已无法满足实际生产需求，针对这种情况，一般使用脚本自动化分析或使用第三方软件对日志进行实时监控、分析、告警。
本实验主要描述openGauss数据库中日志管理的内容，并对数据库进行日常管理维护、问题定位和数据库恢复的操作。

1.1.2 实验目的

掌握openGauss数据库中日志管理的内容；
掌握对数据库进行日常管理维护、问题定位。

1.1.3 系统日志
openGauss运行时数据库节点以及openGauss安装部署时产生的日志统称为系统日志。如果openGauss在运行时发生故障，可以通过这些系统日志及时定位故障发生的原因，根据日志内容制定恢复openGauss的方法。
说明：

日志路径在安装openGauss时已由XML文件中gaussdbLogPath参数指定，如果未指定该参数值，则默认路径在/var/log/gaussdb。
数据文件路径在安装openGauss时已由XML文件中dataNode参数指定，如果未指定该参数值，则默认路径在/gaussdb/data/data_dn。

1.1.3.1 运行时日志

步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 数据库节点的运行日志放在“$gaussdbLogPath/用户名/pg_log /用户名/pg_log”中，当前场景下用户名为”omm”，切换到pg_log文件夹，并显示文件夹中的内容。

cd /var/log/gaussdb/omm/pg_log  ##实际路径以$gaussdbLogPath为准
ls

文件内容显示如下:

dn_6001

数据库节点文件夹为”dn_6001”,以自己实际数据库节点名先为准。

步骤 3 切换到“pg_log”文件夹下的数据库节点文件夹中，查看日志文件。

cd dn_6001
ls

日志文件列表如下：

postgresql-2020-07-21_170715.log  postgresql-2020-07-23_145207.log
postgresql-2020-07-21_174440.log  postgresql-2020-07-23_160709.log
postgresql-2020-07-22_102526.log  postgresql-2020-07-23_162357.log
postgresql-2020-07-23_140520.log  postgresql-2020-07-24_103226.log
postgresql-2020-07-23_142946.log  postgresql-2020-07-25_000000.log

步骤 4 由于在运行过程中日志的大小可能会超过16 MB，所以在简单查询的过程中，可以先查看日志的大小（其中l是L的小写）。

ll -h

列表显示如下：

total 56M
-rw------- 1 omm dbgrp  56K Jul 21 17:38 postgresql-2020-07-21_170715.log
-rw------- 1 omm dbgrp 3.5M Jul 21 20:51 postgresql-2020-07-21_174440.log
-rw------- 1 omm dbgrp  12M Jul 22 21:10 postgresql-2020-07-22_102526.log
-rw------- 1 omm dbgrp  46K Jul 23 14:06 postgresql-2020-07-23_140520.log
-rw------- 1 omm dbgrp  83K Jul 23 14:32 postgresql-2020-07-23_142946.log
-rw------- 1 omm dbgrp 1.1M Jul 23 15:45 postgresql-2020-07-23_145207.log
-rw------- 1 omm dbgrp 373K Jul 23 16:23 postgresql-2020-07-23_160709.log
-rw------- 1 omm dbgrp 5.3M Jul 23 21:03 postgresql-2020-07-23_162357.log
-rw------- 1 omm dbgrp  15M Jul 24 23:59 postgresql-2020-07-24_103226.log
-rw------- 1 omm dbgrp  19M Jul 25 16:52 postgresql-2020-07-25_000000.log

步骤 5 可以查看内容较少的日志。

cat postgresql-2020-07-23_142946.log

日志内容为：

2020-07-23 14:29:46.457 5f192e5a.1 [unknown] 281466519832976 [unknown] 0 dn_6001 00000 0 [BACKEND] LOG:  start create thread!
2020-07-23 14:29:46.457 5f192e5a.1 [unknown] 281466519832976 [unknown] 0 dn_6001 00000 0 [BACKEND] LOG:  create thread end!
2020-07-23 14:29:46.458 5f192e5a.10000 [unknown] 281466446432848 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG:  reaper backend started.
2020-07-23 14:29:46.458 5f192e5a.10000 [unknown] 281466463275600 dn_6001 0 dn_6001 00000 0 [BACKEND] LOG:  [Alarm Module]alarm checker started.
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <JitExec>            Using native LLVM version 7.0.0
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Configuration>      Configuring total memory for relative memory values to: 2048 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <System>             Startup: Loading configuration from /gaussdb/data/db1/mot.conf
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Configuration>      Loaded max_mot_global_memory: 80% from total = 1638 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Configuration>      Loaded max_mot_local_memory: 15% from total = 307 MB
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Configuration>      Loading max_connections from envelope into MOTEngine: 5000
2020-07-23 14:29:46.459 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Configuration>      Configuring asynchronous redo-log handler due to synchronous_commit=off
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [WARNING]  <Configuration>      Adjusting MOT memory limits: global = 102 MB, local = 26 MB, session large store = 0 MB, total = 128 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Memory>             Global Memory Limit is configured to: 0 MB --> 102 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Memory>             Local Memory Limit is configured to: 0 MB --> 26 MB
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Memory>             Session Memory Limit is configured to: 0 KB --> 0 KB (maximum 5000 sessions)
2020-07-23 14:29:46.460 [MOT] <TID:21137/-----> <SID:-----/-----> [INFO]     <Memory>             Configured automatic chunk allocation policy to 'LOCAL' on single node machine

1.1.3.2 安装卸载时日志
步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 openGauss安装卸载时产生的日志放在“$gaussdbLogPath/用户名/om”目录下，当前场景下用户名为”omm”，切换到om文件夹，并显示文件夹中的内容。

cd /var/log/gaussdb/omm/om ##实际路径以$gaussdbLogPath为准
ll -h

文件夹中内容显示如下：

total 160K
-rw------- 1 omm dbgrp 9.1K Jul 21 17:07 gs_install-2020-07-21_170455.log
-rw------- 1 omm dbgrp  68K Jul 24 10:32 gs_local-2020-07-21_160847.log
-rw------- 1 omm dbgrp  35K Jul 24 10:32 gs_om-2020-07-21_174438.log
-rw------- 1 omm dbgrp  32K Jul 21 16:36 gs_preinstall-2020-07-21_160843.log

步骤 3 查看“gs_install-2020-07-21_170455.log”日志，了解openGauss安装情况。

cat gs_install-2020-07-21_170455.log

日志内容如下：

[2020-07-21 17:04:55.967536][27138][gs_install][DEBUG]:The /opt/huawei/wisequery/omm_mppdb/install_step/install_step.dat does not exits.
[2020-07-21 17:04:55.967641][27138][gs_install][DEBUG]:gs_install execution takes 7 steps in total
[2020-07-21 17:04:55.967709][27138][gs_install][LOG][Step1]:Parsing the configuration file.
[2020-07-21 17:04:55.970059][27138][gs_install][DEBUG]:Instance information of cluster:
ClusterName=dbCluster,AppPath=/opt/gaussdb/app,LogPath=/var/log/gaussdb,ClusterType=single-inst
HostName=db1,backIps=['192.168.0.58']
InstanceId=10001,MirrorId=-3,Host=db1,Port=0,DataDir=cm_agent,XlogDir=,SsdDir=,InstanceType=-1,Role=5,ListenIps=['192.168.0.58'],HaIps=[]
InstanceId=6001,MirrorId=1,Host=db1,Port=26000,DataDir=/gaussdb/data/db1,XlogDir=,SsdDir=,InstanceType=0,Role=4,ListenIps=['192.168.0.58'],HaIps=['192.168.0.58'],azName=AZ1.
[2020-07-21 17:04:56.022578][27138][gs_install][DEBUG][Step1]:Successfully parsed the configuration file.
[2020-07-21 17:04:56.067808][27138][gs_install][LOG][Step2]:Check preinstall on every node.
……
alarm=/opt/huawei/snas/bin/snas_cm_cmd  --time_out=300 
[2020-07-21 17:07:16.476528][27138][gs_install][LOG]:Successfully started cluster.
[2020-07-21 17:07:16.476605][27138][gs_install][DEBUG][Step7]:Successfully started the cluster.
[2020-07-21 17:07:16.487388][27138][gs_install][LOG]:Successfully installed application.
[2020-07-21 17:07:16.487469][27138][gs_install][LOG]:end deploy..

1.1.4 操作日志
操作日志是指数据库管理员使用工具操作数据库时以及工具被openGauss调用时产生的日志。如果openGauss发生故障，可以通过这些日志信息跟踪用户对数据库进行了哪些操作，重现故障场景。
1.1.4.1 操作步骤
步骤 1 切换到omm用户，以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 默认在“ G A U S S L O G / b i n ” 目录下，其中 GAUSSLOG/bin”目录下，其中 GAUSSLOG/bin”目录下，其中GAUSSLOG默认为“/var/log/gaussdb/用户名”，当前场景下用户名为”omm”。

cd /var/log/gaussdb/omm/bin
ls

显示如下：

gs_ctl  gs_guc  gs_initdb  gs_obs

步骤 3 以gs_guc操作为例，进入gs_guc文件夹，并查看文件的属性。

cd gs_guc
ll -h

文件列表显示如下：

total 20K
-rw------- 1 omm dbgrp 17K Jul 23 17:20 gs_guc-2020-07-21_170713-current.log

步骤 4 查看操作日志文件

cat gs_guc-2020-07-21_170713-current.log

日志显示如下：

[2020-07-21 17:07:13]
expected instance path: [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl=on: [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_cert_file='server.crt': [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_key_file='server.key': [/gaussdb/data/db1/postgresql.conf]
gs_guc set: ssl_ca_file='cacert.pem': [/gaussdb/data/db1/postgresql.conf]

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!
……
[2020-07-23 17:20:20]
Begin to perform gs_guc for all datanodes.
[2020-07-23 17:20:20]
[2020-07-23 17:20:20]
expected instance path: [/gaussdb/data/db1/pg_hba.conf]
Notice: the above configuration uses cluster internal communication, your configuration may affect the cluster internal communication.
gs_guc sethba: host all  dim 192.168.0.96/24  sha256: [/gaussdb/data/db1/pg_hba.conf]

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!


Total instances: 1. Failed instances: 0.
Success to perform gs_guc!


Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

1.1.5 审计日志
审计功能开启时会不断产生大量的审计日志，占用磁盘空间。用户可以根据磁盘空间的大小设置审计日志维护策略。
1.1.5.1 前提条件

用户必须拥有审计权限。
omm用户连接数据库。

步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 启动openGauss数据库服务

gs_om -t start

步骤 3 使用如下命令连接数据库。

gsql -d postgres -p 26000 -r

postgres为需要连接的数据库名称，26000为数据库主节点的端口号。

1.1.5.2 背景信息
与审计日志相关的配置参数及其含义请参见下表。

配置项	含义	默认值
audit_directory	审计文件的存储目录。	/var/log/gaussdb/用户名/pg_audit
audit_resource_policy	审计日志的保存策略。	on（表示使用空间配置策略）
audit_space_limit	审计文件占用的磁盘空间总量。	1 GB
audit_file_remain_time	审计日志文件的最小保存时间。	90天
audit_file_remain_threshold	审计目录下审计文件的最大数量。	1048576

说明：如果使用gs_om工具部署openGauss，则审计日志路径为 “/var/log/gaussdb/用户名/pg_audit”。

审计日志删除命令为数据库提供的sql函数pg_delete_audit，其原型为：
pg_delete_audit(timestamp startime,timestamp endtime)
其中参数startime和endtime分别表示审计记录的开始时间和结束时间。

目前常用的记录审计内容的方式有两种：记录到数据库的表中、记录到OS文件中。这两种方式的优缺点比较如下表所示。

方式	优点	缺点
记录到表中	不需要用户维护审计日志。	由于表是数据库的对象，如果一个数据库用户具有一定的权限，就能够访问到审计表。如果该用户非法操作审计表，审计记录的准确性难以得到保证。
记录到OS文件中	比较安全，即使一个帐户可以访问数据库，但不一定有访问OS这个文件的权限。	需要用户维护审计日志。

从数据库安全角度出发，openGauss采用记录到OS文件的方式来保存审计结果，保证了审计结果的可靠性。

1.1.5.3 选择日志维护方式进行维护。

1.1.5.3.1 设置自动删除审计日志
审计文件占用的磁盘空间或者审计文件的个数超过指定的最大值时，系统将删除最早的审计文件，并记录审计文件删除信息到审计日志中。
注：审计文件占用的磁盘空间大小默认值为1024MB，用户可以根据磁盘空间大小重新设置参数。

步骤 1 配置审计文件占用磁盘空间的大小（audit_space_limit），查看已配置的参数。

postgres=# SHOW audit_space_limit; 

 audit_space_limit 
------------------- 
 1GB 
(1 row)

如果显示结果不为1 GB（1024 MB），执行“\q”命令退出数据库。

postgres=# \q

步骤 2 建议执行如下命令设置成默认值1024 MB。

gs_guc reload -N all -I all -c "audit_space_limit=1024MB"

显示结果为：

"audit_space_limit=1024MB";
Begin to perform gs_guc for all datanodes.

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

步骤 3 配置审计文件个数的最大值（audit_file_remain_threshold）。连接数据库，查看已配置的参数。
连接数据库：

gsql -d postgres -p 26000 -r

查看审计文件个数的参数：

postgres=# SHOW audit_file_remain_threshold;
 audit_file_remain_threshold 
-----------------------------
 1048576
(1 row)

如果显示结果不为1048576，执行“\q”命令退出数据库。

postgres=# \q

步骤 4 建议执行如下命令设置成默认值1048576。

gs_guc reload -N all -I all -c "audit_file_remain_threshold=1048576"

显示为：

Begin to perform gs_guc for all datanodes.

Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

1.1.5.3.2 手动备份审计文件
当审计文件占用的磁盘空间或者审计文件的个数超过配置文件指定的值时，系统将会自动删除较早的审计文件，因此建议用户周期性地对比较重要的审计日志进行保存。

步骤 1 连接数据库，使用show命令获得审计文件所在目录（audit_directory）。
连接数据库：

gsql -d postgres -p 26000 -r

获得审计文件所在目录：

postgres=# SHOW audit_directory;

            audit_directory            
---------------------------------------
 /var/log/gaussdb/omm/pg_audit/dn_6001
(1 row)

退出数据库

postgres=# \q

步骤 2 将审计目录整个拷贝出来进行保存。

cp -r /var/log/gaussdb/omm/pg_audit/dn_6001 /var/log/gaussdb/omm/pg_audit/dn_6001_bak

查看备份是否成功：

cd /var/log/gaussdb/omm/pg_audit/
ll -h

total 8.0K
drwx------ 2 omm dbgrp 4.0K Sep 14 16:52 dn_6001
drwx------ 2 omm dbgrp 4.0K Sep 15 11:43 dn_6001_bak

1.1.6 WAL日志
预写式日志WAL（Write Ahead Log，也称为Xlog）是指如果要修改数据文件，必须是在这些修改操作已经记录到日志文件之后才能进行修改，即在描述这些变化的日志记录刷新到永久存储器之后。在系统崩溃时，可以使用WAL日志对openGauss进行恢复操作。
1.1.6.1 操作步骤
步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 以一个数据库节点为例，默认在“/gaussdb/data/data_dn/pg_xlog”目录下。其中“/gaussdb/data/data_dn”代表openGauss节点的数据目录，当前情况下为“/gaussdb/data/db1/”。

cd /gaussdb/data/
ls
db1

切换到db1文件夹。

cd db1
ls

文件夹中内容如下：

base                pg_ctl.lock       pg_notify     postgresql.conf
cacert.pem          pg_errorinfo      pg_replslot   postgresql.conf.bak
gaussdb.state       pg_hba.conf       pg_serial     postgresql.conf.lock
global              pg_hba.conf.bak   pg_snapshots  postmaster.opts
gswlm_userinfo.cfg  pg_hba.conf.lock  pg_stat_tmp   postmaster.pid
mot.conf            pg_ident.conf     pg_tblspc     server.crt
pg_clog             pg_llog           pg_twophase   server.key
pg_copydir          pg_location       PG_VERSION    server.key.cipher
pg_csnlog           pg_multixact      pg_xlog       server.key.rand

步骤 3 切换到pg_xlog文件夹，查看WAL日志文件。

cd pg_xlog
ls

日志文件列表如下：

00001000000010000004E  000000010000000100000066  00000001000000010000007E
00000001000000010000004F  000000010000000100000067  00000001000000010000007F
000000010000000100000050  000000010000000100000068  
……
000000010000000100000063  00000001000000010000007B  archive_status
000000010000000100000064  00000001000000010000007C
000000010000000100000065  00000001000000010000007D

1.1.7 性能日志
性能日志主要关注外部资源的访问性能问题。性能日志指的是数据库系统在运行时检测物理资源的运行状态的日志，在对外部资源进行访问时的性能检测，包括磁盘、OBS等外部资源的访问检测信息。在出现性能问题时，可以借助性能日志及时的定位问题发生的原因，能极大地提升问题解决效率。
1.1.7.1 操作步骤
步骤 1 以操作系统用户omm登录数据库主节点。

su - omm

步骤 2 数据库节点的性能日志目录在“$GAUSSLOG/gs_profile”中各自对应的目录下, 其中$GAUSSLOG默认为“/var/log/gaussdb/用户名”，当前场景下用户名为”omm”。切换到文件夹，查看文件列表的信息。

cd /var/log/gaussdb/omm/gs_profile/
ls
dn_6001

切换到dn_6001文件夹。

cd dn_6001
ls –h

性能日志内容显示如下:

total 4.0K
-rw------- 1 omm dbgrp  0 Jul 21 17:07 postgresql-2020-07-21_170715.prf
-rw------- 1 omm dbgrp  0 Jul 21 17:44 postgresql-2020-07-21_174440.prf
-rw------- 1 omm dbgrp  0 Jul 22 10:25 postgresql-2020-07-22_102526.prf
-rw------- 1 omm dbgrp  0 Jul 23 14:05 postgresql-2020-07-23_140520.prf
-rw------- 1 omm dbgrp  0 Jul 23 14:29 postgresql-2020-07-23_142946.prf
-rw------- 1 omm dbgrp  0 Jul 23 14:52 postgresql-2020-07-23_145207.prf
-rw------- 1 omm dbgrp  0 Jul 23 16:07 postgresql-2020-07-23_160709.prf
-rw------- 1 omm dbgrp  0 Jul 23 16:23 postgresql-2020-07-23_162357.prf
-rw------- 1 omm dbgrp 48 Jul 25 00:00 postgresql-2020-07-24_103226.prf
-rw------- 1 omm dbgrp  0 Jul 25 00:00 postgresql-2020-07-25_000000.prf

说明：

性能日志主要监控三种资源访问：磁盘、OBS、Hadoop。openGauss不支持OBS、Hadoop，所以只有磁盘访问的监控信息。
磁盘监控的访问信息主要在磁盘文件IO读写的时候进行统计。比如拷贝文件时的读文件IO，正常SQL执行时访问OS表文件的pread系统调用。
性能日志进行收集的配置：logging_collector 是否进行日志收集；plog_merge_age 多久进行一次性能日志汇聚，单位毫秒。logging_collector 参数为on，且plog_merge_age大于0，且是主机正常运行中，恢复过程不进行性能收集。
通过工具gs_log导出文件进行查看。

到此，openGauss数据库日志管理指导结束。

微信关注我们

原文链接：https://my.oschina.net/gaussdb/blog/5443395

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

事件驱动分布式应用 EventMesh - 1 月进展

EventMesh 事件驱动分布式应用多运行时 1.参与云原生社区在线meetup介绍推广EventMesh 2.grpc特性开发测试跟进 3.1.4.0发布准备 4.与serverless 社区workflow合作调研 learn more：Apache EventMesh

2022-02-14

523

众所周知，执行器执行之前，需要计划的支撑。计划分为逻辑计划和物理计划。他们的关系就好比是我们要出去旅游，选择什么交通工具就相当于逻辑计划，在这一步比如选择了飞机后。选择哪家航空公司就相当于物理计划。最后，当你真正动身去旅游就相当于执行。下面给出SQL语句执行的基本构架图，从中可以清楚地看到优化器和执行器在整个流程中的执行过程。优化器逻辑计划和物理计划负责生成执行计划和索引选择等功能，可以把它看做优化器。比如执行这样的语句，执行两个表的join： Select*fromt1joint2using(ID)wheret1.c=10andt2.d=20; 既可以先从t1里取出c=10记录的ID，再根据ID关联到t2,再判断t2里面d的值是否等于20，也可以先从t2里取出c=20记录的ID，再根据ID关联到t1,再判断t2里面d的值是否等于10。这两种执行方法的逻辑是一样的，但执行效率不同，优化器可以预估代价决定使用方案。在分布式数据库中，其中的物理计划还可以根据要用到的数据span所在的节点判断该算子在哪个节点上执行，从而实现分布式执行。与分布式相关的物理计划具体作用在分布式执行概述。 ...

2022-02-14

437

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。