一、准备环境
+ +1. 源库创建（Oracle）
+-
+
- 创建Oracle 11.2.0.4 +
MTK程序迁移Oracle需要安装Oracle客户端
+-
+
- 安装Oracle客户端 +
2. 目标库创建（MogDB）
+ +二、迁移
+1. 上传程序，编写配置文件
+迁移为Oracle下的scott用户
+-
+
- 编写配置文件 +
2 迁移
+-
+
- 执行迁移命令 +
-
+
-
+
主界面
+
+
+ -
+
对象
+
+
+ -
+
表数据
+
+
+
| + | ++ | +
|---|---|
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
|---|---|
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | ++ | ++ | +
|---|---|---|---|
| + | ++ | ++ | ++ |
| + | ++ + | ++ | ++ | +
| + | ++ + | ++ | ++ |
| + | ++ | ++ | ++ | ++ + | ++ | +
|---|---|---|---|---|---|
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | ++ |
| + | ++ | ++ | ++ | ++ | ++ |
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ + | ++ | +
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | +
|---|---|
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | ++ | ++ | ++ | +
|---|---|---|---|---|
| + | ++ | ++ | ++ | ++ | +
**序号**
| SYSTAB_01 |
+| ---------------------------------------- | ------------------------------------------------------------ |
+| **系统表** | pg_class |
+| **差异** | openGauss新增字段：reltoastidxid, reldeltarelid, reldeltaidx, relcudescrelid, relcudescidx, relhasoids, relhaspkey, relcmprs, relhasclusterkey, relrowmovement, parttype, relfrozenxid64, relbucket, relbucketkey PostgreSQL 新增字段：relrowsecurity, relforcerowsecurity, relispopulated, relispartition, relrewrite , relminmxid , relpartbound relkind
字段可选值差异：PostgreSQL中用p和I表示分区表和分区索引，openGauss用字段parttype表示。 | +| **备注** | 具体描述可见《开发者指南》-系统表和系统视图-系统表-PG_CLASS | + +### 9.3 系统视图 + +| **序号** | SYSVIEW_01 | +| ---------- | ------------------------------------------------------------ | +| **系统表** | pg_tables | +| **差异** | openGauss新增字段：tablecreator, created, last_ddl_time PostgreSQL 新增字段：rowsecurity | +| **备注** | 具体描述可见《开发者指南》-系统表和系统视图-系统视图-PG_TABLES | + +### 9.4 系统函数 + +### 9.5 LOCK + +### 9.6 Memory Context + +### 9.7 全局变量 + +| **PostgreSQL** | **openGauss** | **作用域** | +| ------------------- | ------------------------------------ | -------------- | +| error_context_stack | t_thrd.log_cxt.error_context_stack | Thread | +| WalSndCaughtUp | t_thrd.walsender_cxt.walSndCaughtUp | Thread | +| disable_cost | g_instance.cost_cxt.disable_cost | Instance | +| cpu_tuple_cost | u_sess->attr.attr_sql.cpu_tuple_cost | cpu_tuple_cost | + +## 10 常见错误信息 + +1) 编译安装时报错：dangerous relocation: unsupported relocation + +解决方法：参考4.2，在Makefile中添加下面一句。 + + override CPPFLAGS :=$(filter-out -fPIE, $(CPPFLAGS)) -fPIC + +2) 编译安装时报错：error: invalid conversion from ‘void’ to ‘char’ [-fpermissive] + +解决方法：参考5类型转换 + +3) create extension时报错：could not find function "xxx" in file "xxx.so" + +解决方法：参考6函数声明。 \ No newline at end of file diff --git a/content/zh/post/cym/.DS_Store b/content/zh/post/cym/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..9b88a574476e8fbfaf07e75d4759acf5cd3f1038 Binary files /dev/null and b/content/zh/post/cym/.DS_Store differ diff --git "a/content/zh/post/cym/OpenGauss\344\270\255\347\232\204AI\346\212\200\346\234\257\342\200\224\342\200\224\346\205\242SQL\347\232\204\346\243\200\346\265\213.md" "b/content/zh/post/cym/OpenGauss\344\270\255\347\232\204AI\346\212\200\346\234\257\342\200\224\342\200\224\346\205\242SQL\347\232\204\346\243\200\346\265\213.md" new file mode 100644 index 0000000000000000000000000000000000000000..d4def94eb82cfdf2e6073438833c52489039fb30 --- /dev/null +++ "b/content/zh/post/cym/OpenGauss\344\270\255\347\232\204AI\346\212\200\346\234\257\342\200\224\342\200\224\346\205\242SQL\347\232\204\346\243\200\346\265\213.md" @@ -0,0 +1,384 @@ +``` +title = "openGauss中的AI技术————慢SQL的检测" +date = "2021-11-30" +tags = ["openGauss社区开发入门"] +archives = "2021-11" +author = "chen-yiming-cs" +summary = "openGauss社区开发入门" +``` + +# 一、概念部分 + + 本文主要是介绍OpenGauss中AI技术——慢SQL发现技术的分析。 +## （1）慢SQL相关概念 + 慢SQL：效率慢的SQL语句 + 慢SQL发现：基于历史SQL语句信息进行模型训练，并用训练好的模型进行SQL语句的预测，利用预测结果判断该SQL语句是否是潜在的慢SQL。当发现潜在的慢SQL后，开发者便可以进行针对性优化或者风险评估，以防业务上线后发生问题。 + 慢SQL的产生原因：SQL编写问题、锁、业务实例相互干绕对 IO/CPU 资源争用、服务器硬件、MYSQL BUG，其中编写问题可以说是占了主要，所以发现慢SQL并提示用户更改或者程序自动优化是有很必要的。 + +## （2）慢SQL的三个阶段 + +- 阶段1（发现问题）： + 对用户输入的一批业务SQL语句进行分析，推断SQL语句执行时间的快慢，进而可以将评估为慢SQL的语句识别出来。(目前OpenGauss已经具备这方面的能力，比如本次报告介绍的慢SQL发现技术) + +- 阶段2（找到原因）： + 对识别出的潜在慢SQL进行根因诊断，判断这些SQL语句是因为什么慢，例如比较常见的原因可能是数据量过大、SQL语句自身过于复杂、容易产生并发的锁冲突、没有创建索引导致全表扫描等等。 + +- 阶段3（给出处理建议）： + 对于已经识别出来的慢SQL语句的可能问题源，给出针对性的解决方案，譬如可以提示用户进行SQL语句的改写、创建索引等。(OpenGauss有部分相关的功能，如索引推荐等) + + + +## （3）慢SQL发现的AI技术 + +**①基于执行的在线SVM模型** + + + + + 第一种技术是利用了SVM模型来预测是否为慢SQL。 + 这里主要是有两个环节，分别是训练阶段和测试阶段。 + **训练阶段**： + Data Collection模块执行作为训练集的语句，Data Extraction模块收集执行的语句特征及执行时间，包括执行计划及算子级别的信息。Model Building模块基于计划级别特征与算子级别信息分别训练SVM模型，再将两模型通过误差分布结合，生成最终的预测模型。 + + **测试阶段：** + Query Planning模块生成待预测语句的执行计划，Feature Extraction抽取这些计划中的特征，整合后投入训练阶段生成的模型中产生预测结果。 + +整体的算法流程图如下： + + + + + +**②基于执行计划的DNN模型** + + + + 此算法与第一种相似，区别就是其中的Model Building模块中选择的算法不同。如上图所示，是此技术的算法架构图，算法的概述如下。 + 该算法依然是将执行计划中的算子信息输入到深度学习网络中，从而对执行时间进行预测的。对于每个算子，收集左右子树的向量化特征、优化器代价及执行时间，输入与之对应的模型中，预测该算子的向量化特征及执行时间等。上图中显示了一个join操作的预测流程，其左右子树均为Scan算子，将两个Scan算子通过对应的模型预测出的向量化特征、执行时间，以及该join算子的优化器评估代价作为入参，输出join算子模型得到该操作的向量化特征及预测出的执行时间。上述过程是个自底向上的过程。 +此技术流程图如下： + + + +当然，此技术也有很多缺点： + 需要通过已预测算子不断修正模型，预测过程会较慢。 + 对环境变化感知差，如数据库参数变化会使得原模型几乎完全失效。 + 预测过程依赖待测语句的执行计划，加重了数据库的负荷，对于OLTP场景格外不适用。 + + +## （4）总体流程 + + 程序开始后，会先去获取SQL流水，然后根据我们设置的初始化参数来确定是使用模板法还是深度学习方法，如果是模板化方法，具体流程如下： +1°检测本地是否存在对应实例的历史模板信息，如果存在，则加载该模板信息，如果不存在，则对该模板进行初始化。 +2°基于SQL数据，提取SQL的粗粒度模板信息。粗粒度模板表示将SQL中表名、列名和其他敏感信息去除之后的SQL语句模板，该模板只保留最基本的SQL语句骨架。 +3° 基于SQL数据，提取SQL细粒度的模板信息。细粒度模板表示在粗粒度模板信息的基础上保留表名、列名等关键信息的SQL语句模板。细粒度模板相对粗粒度模板保留了更多SQL语句的信息。 +4°执行训练过程时，首先构造SQL语句的基于粗粒度模板和细粒度模板信息，例如粗粒度模板ID、执行平均时间、细模板执行时间序列、执行平均时间和基于滑动窗口计算出的平均执行时间等。最后将上述模板信息进行储存。 +5°执行预测过程时，首先导入对应实例的模板信息，如果不存在该模板信息，则直接报错退出；否则继续检测是否存在该SQL语句的粗粒度模板信息，如果不存在，则基于模板相似度计算方法在所有粗粒度模板里面寻找最相似的N条模板，之后基于KNN（k nearest neighbor，K近邻）算法预测出执行时间；如果存在粗粒度模板，则接着检测是否存在近似的细粒度模板，如果不存在，则基于模板相似度计算方法在所有细粒度模板里面寻找最相似的N条模板，之后基于KNN预测出执行时间；如果存在匹配的细粒度模板，则基于当前模板数据，直接返回对应的执行时间。 + +如果是选择了深度学习，具体流程如下所示： +1°在训练过程中，首先判断是否存在历史模型，如果存在，则导入模型进行增量训练；如果不存在历史模型，则首先利用word2vector算法对SQL语句进行向量化，即图8-11中的SQL embeding过程。而后创建深度学习模型，将该SQL语句向量化的结果作为输入特征。基于训练数据进行训练，并将模型保存到本地。值得一提的是，该深度学习模型的最后一个全连接层网络的输出结果作为该SQL语句的特征向量。 +2°在预测过程中，首先判断是否存在模型，如果模型不存在，则直接报错退出；如果存在模型，则导入模型，并利用word2vector算法将待预测的SQL语句进行向量化，并将该向量输入到深度学习网络中，获取该神经网络的最后一个全连接层的输出结果，即为该SQL语句的特征向量。最后，利用余弦相似度在样本数据集中进行寻找，找到相似度最高的SQL语句，将该结果返回即为该待预测SQL语句的预估执行时间。当然，如果是基于最新SQL语句执行时间数据集训练出的深度学习模型，则模型的回归预测结果也可以作为预估执行时间。 + + +# 二、具体项目代码分析 + + +## 1、整体项目结构 + +项目路径：openGauss-server/src/gausskernel/dbmind/tools/sqldiag +首先是，本项目的整体架构如下所示： + + + +其中，重要的文件/文件夹主要有： + preprocessing.py SQL预处理方法 + requirements.txt 依赖第三方库列表等 + main.p 入口文件 + algorithm 项目核心代码 + algorithm/sql_similarity 相似度计算方法 + + +## 2、核心代码分析 + + +### (1)首先是main函数 + + +```python +def main(args): + logging.basicConfig(level=logging.WARNING)//初始化参数 + if not is_valid_conf(args.config_file): + logging.fatal('The [--config-file] parameter is incorrect') + sys.exit(1) + // 下面就是根据我们初始化的参数来生成对应模型 + model = SQLDiag(args.model, get_config(args.config_file)) + if args.mode in ('train', 'finetune')://如果检测到是要训练/微调，就执行这个分支，主要是读取训练数据，然后做训练，再保存模型 + if not args.csv_file: + logging.fatal('The [--csv-file] parameter is required for train mode') + sys.exit(1) + train_data = LoadData(args.csv_file).train_data + if args.mode == 'train': + model.fit(train_data) + else: + model.fine_tune(args.model_path, train_data) + model.save(args.model_path) + else: //不然的话就是执行测试分支，这里就不用读取训练数据，而是直接读取模型，然后用这个模型来预测结果 + model.load(args.model_path) + if args.csv_file and not args.query: + predict_data = LoadData(args.csv_file).predict_data + elif args.query and not args.csv_file: + predict_data = split_sql(args.query) + else: + logging.error('The predict model only supports [--csv-file] or [--query] at the same time.') + sys.exit(1) + args.threshold = -100 if not args.threshold else float(args.threshold)//这里是要设置一个阈值来划分 + pred_result = model.transform(predict_data) + if args.predicted_file: + if args.model == 'template': + info_sum = [] + if _info: + _info = list(filter(lambda item: item[1]>=args.threshold, _info)) + for item in _info: + item.insert(1, stats) + info_sum.extend(_info) + ResultSaver().save(info_sum, args.predicted_file) + else: + pred_result = list(filter(lambda item: float(item[1])>=args.threshold, pred_result)) + ResultSaver().save(pred_result, args.predicted_file) + else: + from prettytable import PrettyTable + + display_table = PrettyTable() + if args.model == 'template': + display_table.field_names = ['sql', 'status', 'predicted time', 'most similar template'] + display_table.align = 'l' + status = ('Suspect illegal SQL', 'No SQL information', 'No SQL template found', 'Fine match') + for stats in status: + if pred_result[stats]: + for sql, predicted_time, similariest_sql in pred_result[stats]: + if predicted_time >= args.threshold or stats == 'Suspect illegal sql': + display_table.add_row([sql, stats, predicted_time, similariest_sql]) + else: + display_table.field_names = ['sql', 'predicted time'] + display_table.align = 'l' + for sql, predicted_time in pred_result: + if float(predicted_time) >= args.threshold: + display_table.add_row([sql, predicted_time]) + print(display_table.get_string()) + + +``` + +### (2)然后来分析下模板化算法的框架 + + + + 模板化方法类的结构就如上所示，其中fit方法就是训练的，transform方法是预测的，load是加载模型，save是储存模型，predict_duration_time是计算执行时间，在transform中会被调用。 + +```python +# fit方法： +def fit(self, data): + # 对每条sql语句按照粗、细粒度进行标准化，生成模板 + for sql, duration_time in data: + if check_illegal_sql(sql): + continue + sql_template = templatize_sql(sql) + sql_prefix = sql_template.split()[0] + if sql_prefix not in self.__hash_table: + sql_prefix = 'OTHER'#如果不存在，说明没有此模板，就标记下来，后续插入 + + if sql_template not in self.__hash_table[sql_prefix]: + self.__hash_table[sql_prefix][sql_template] = dict(time_list=[], count=0, mean_time=0.0, iter_time=0.0) + self.__hash_table[sql_prefix][sql_template]['count'] += 1 + self.__hash_table[sql_prefix][sql_template]['time_list'].append(duration_time) + # 更新模板信息，也就相当于是训练的过程了 + for sql_prefix, sql_prefix_info in self.__hash_table.items(): + for sql_template, sql_template_info in sql_prefix_info.items(): + del sql_template_info['time_list'][:-self.time_list_size] + sql_template_info['mean_time'] = sum(sql_template_info['time_list']) / len(sql_template_info['time_list']) + sql_template_info['iter_time'] = reduce(lambda x, y: (x+y)/2, sql_template_info['time_list']) + +# Predict_duration_time方法，就是去从一堆模板中找到最相似的k个，然后算均值（KNN方法）。 +def predict_duration_time(self, sql): + top_similarity_sql = None + if check_illegal_sql(sql): + predict_time = -1 + status = 'Suspect illegal sql' + return sql, status, predict_time, top_similarity_sql + + sql_template = templatize_sql(sql) + # get 'sql_template' of SQL + sql_prefix = sql_template.strip().split()[0] + if sql_prefix not in self.__hash_table: + sql_prefix = 'OTHER' + if not self.__hash_table[sql_prefix]: + status = 'No SQL information' + predict_time = -1 + elif sql_template not in self.__hash_table[sql_prefix]: + similarity_info = [] + """ + if the template does not exist in the hash table, + then calculate the possible execution time based on template + similarity and KNN algorithm in all other templates + """ + status = 'No SQL template found' + for local_sql_template, local_sql_template_info in self.__hash_table[sql_prefix].items(): + similarity_info.append( + (self.similarity_algorithm(sql_template, local_sql_template), + local_sql_template_info['mean_time'], local_sql_template)) + topn_similarity_info = heapq.nlargest(self.knn_number, similarity_info) #找相似度最高的模板的信息 + sum_similarity_scores = sum(item[0] for item in topn_similarity_info) + if not sum_similarity_scores: + sum_similarity_scores = self.bias + top_similarity_sql = '\n'.join([item[2] for item in topn_similarity_info]) + similarity_proportions = [item[0] / sum_similarity_scores for item in + topn_similarity_info] + topn_duration_time = [item[1] for item in topn_similarity_info] + predict_time = reduce(lambda x, y: x + y, + map(lambda x, y: x * y, similarity_proportions, + topn_duration_time)) + + else: + status = 'Fine match' + predict_time = self.__hash_table[sql_prefix][sql_template]['iter_time'] + top_similarity_sql = sql_template + + return sql, status, predict_time, top_similarity_sql + + + +``` + + +### (3)模板化算法-相似度计算算法 + +主要有四个算法： + +```python +# 1°余弦距离 + + + + +def distance(str1, str2): + c_1 = Counter(str1) + c_2 = Counter(str2) + c_union = set(c_1).union(c_2) + dot_product = sum(c_1.get(item, 0) * c_2.get(item, 0) for item in c_union) + mag_c1 = math.sqrt(sum(c_1.get(item, 0)**2 for item in c_union)) + mag_c2 = math.sqrt(sum(c_2.get(item, 0)**2 for item in c_union)) + return dot_product / (mag_c1 * mag_c2) + +# 2°编辑距离 + + + + +def distance(str1, str2): + """ + func: calculate levenshtein distance between two strings. + :param str1: string1 + :param str2: string2 + :return: distance + """ + len_str1 = len(str1) + 1 + len_str2 = len(str2) + 1 + + mat = [[0]*len_str2 for i in range(len_str1)] + mat[0][0] = 0 + for i in range(1,len_str1): + mat[i][0] = mat[i-1][0] + 1 + for j in range(1,len_str2): + mat[0][j] = mat[0][j-1]+1 + for i in range(1,len_str1): + for j in range(1,len_str2): + if str1[i-1] == str2[j-1]: + mat[i][j] = mat[i-1][j-1] + else: + mat[i][j] = min(mat[i-1][j-1],mat[i-1][j],mat[i][j-1])+1 + + return 1 / mat[len_str1-1][j-1] + + +# 3°列表距离 + +大致就是两个部分：长度相似度+内容相似度 +def distance(str1, str2): + sql_distance = 0.0 + list1 = str1.split() + list2 = str2.split() + sorted_list1 = sorted(list1) + sorted_list2 = sorted(list2) + max_len = max(len(sorted_list1), len(sorted_list2)) + min_len = min(len(sorted_list1), len(sorted_list2)) + short_list = sorted_list1 if len(sorted_list1) < len(sorted_list2) else sorted_list2 + long_list = sorted_list1 if len(sorted_list1) > len(sorted_list2) else sorted_list2 + for item in short_list: + if item in long_list: + sql_distance += 1.0 + length_similarity = float(min_len / max_len) + return sql_distance + length_similarity +# 4°解析树距离（这里没看懂，就不叙述了） + + +``` + + + +## 3、DNN算法 + + + + + + +DNN模型主要有一个word2vec模块，然后是接上一个KerasRegression，KerasRegression结构如下： + +```python +from tensorflow.keras import Input, Model + from tensorflow.keras.layers import Dense + inputs = Input(shape=(shape,)) + layer_dense1 = Dense(128, activation='relu', + kernel_initializer='he_normal')(inputs) + layer_dense2 = Dense(256, activation='relu', + kernel_initializer='he_normal')(layer_dense1) + layer_dense3 = Dense(256, activation='relu', + kernel_initializer='he_normal')(layer_dense2) + layer_dense4 = Dense(256, activation='relu', + kernel_initializer='he_normal', name='vectors')(layer_dense3) + y_pred = Dense(encoding_dim)(layer_dense4) + model = Model(inputs=inputs, outputs=y_pred) + model.compile(optimizer='adam', loss='mse', metrics=['mae']) + return model + + +``` +就是一个简单的5层全连接网络。 + +预测过程： + +```python +feature_list = [] + data_backup = list(data) + error_list = [] + for idx_error, sql in enumerate(data_backup): + if check_illegal_sql(sql): + error_list.append(idx_error) + continue + filter_template = templatize_sql(sql) + vector = self.w2v.str2vec(filter_template) + feature_list.append(vector) + + features = np.array(feature_list) + predictions = self.regression.predict(features) + predictions = np.abs(predictions) + score = self.scaler.inverse_transform(predictions) + if error_list: + for item in error_list: + score = np.insert(score, item, -1) + score = np.hstack((np.array(data_backup).reshape(-1, 1), score.reshape(-1, 1))).tolist() + return score + + +``` + +训练过程就相当于预测过程多一个反向传播。 diff --git "a/content/zh/post/cym/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md" "b/content/zh/post/cym/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md" new file mode 100644 index 0000000000000000000000000000000000000000..0e99b9680abfb91e1259687d42164da47651997a --- /dev/null +++ "b/content/zh/post/cym/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md" @@ -0,0 +1,382 @@ +``` +title = "openGauss数据库安装与使用" +date = "2021-11-30" +tags = ["openGauss社区开发入门"] +archives = "2021-11" +author = "chen-yiming-cs" +summary = "openGauss社区开发入门" +times = "17:30" +``` +# 一、相关说明 + 使用VMware虚拟机，安装CentOS7.9 64位系统（因为找不到7.6的安装包了），设置此系统的基础参数如下（这里内存需要设置大一点，不然可能会无法运行OpenGauss）： + + + + 此外，还需要修改/etc/redhat-release文件中系统的版本为：CentOS Linux release 7.6(Core)，这是因为不安装7.6，可能出现gauss与os不匹配的问题，但是目前已经没有7.6的包了。所以选择了7.9，然后吧版本号改掉。 + + + +# 二、具体安装步骤 + + +## 1．准备操作 +（1）配置yum源 + 删除自带的yum源 + +```bash +rm -rf /etc/yum.repos.d/* +``` + + 下载阿里云的yum源 + +```bash +wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo +``` + + 然后更新缓存 +```bash +yum makecache +``` +（2）安装一些依赖项 + +``` +yum clean all +yum install -y lksctp* +yum install -y java-1.8.0-openjdk* psmisc bzip2 python3 python3-devel +yum install -y libaio-devel flex bison ncurses-devel glibc-devel patch redhat-lsb-core +``` + + + +（3）配置ip和hostname + +``` +hostname && ifconfig |grep broadcast|awk '{print $2}' +sed -i '/MasterG/d' /etc/hosts +echo "192.168.2.131 MasterG ##Gauss OM IP Hosts Mapping" >> /etc/hosts +cat /etc/hosts|grep Gauss + + + +``` +（4）关闭防火墙然后重启 + +``` +systemctl status firewalld +systemctl disable firewalld.service +systemctl stop firewalld.service +sed -i '/SELINUX=/d' /etc/selinux/config +echo "SELINUX=disabled" >> /etc/selinux/config +cat /etc/selinux/config|grep -v ^#|grep -v '^$' +reboot + + +``` + +（5）配置时区 + +``` +echo "export LANG=en_US.UTF-8" >> ~/.bash_profile +source ~/.bash_profile +env|grep LANG +rm -fr /etc/localtime +ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime +ll /etc/localtime + + +``` + +（6）关闭SWAP + +``` +swapoff -a + + +``` + +（7）关闭透明页并重启 + +``` +echo never > /sys/kernel/mm/transparent_hugepage/enabled +echo never > /sys/kernel/mm/transparent_hugepage/defrag +sed -i '/^GRUB_CMDLINE_LINUX/d' /etc/default/grub +echo "GRUB_CMDLINE_LINUX=\"rhgb quiet transparent_hugepage=never\"" >> /etc/default/grub +grub2-mkconfig -o /boot/grub2/grub.cfg + +reboot + + +``` + +（8）修改系统资源限制 + +``` +echo "* soft stack 3072" >> /etc/security/limits.conf +echo "* hard stack 3072" >> /etc/security/limits.conf +echo "* soft nofile 1000000" >> /etc/security/limits.conf +echo "* hard nofile 1000000" >> /etc/security/limits.conf +echo "* soft nproc unlimited" >> /etc/security/limits.d/90-nproc.conf +tail -n 4 /etc/security/limits.conf +tail -n 1 /etc/security/limits.d/90-nproc.conf + + +``` + +## 2．详细安装 + +（1）下载安装包、创建用户组和目录 + +``` +groupadd dbgrp +useradd -g dbgrp -d /home/omm -m -s /bin/bash omm + echo "omm" | passwd -‐stdin omm +mkdir -p /opt/software/openGauss +chmod 755 -R /opt/software +chown -R omm:dbgrp /opt/software/openGauss +cd /opt/software/openGauss/ +wgethhttps://opengauss.obs.cn-south-1.myhuaweicloud.com/2.0.0/x86/openGauss-2.0.0-CentOS-64bit-all.tar.gz +tar -zxvf openGauss-2.0.0-CentOS-64bit-all.tar.gz +tar -zxvf openGauss-2.0.0-CentOS-64bit-om.tar.gz + + +``` +（2）配置XML文件 + +``` +cp script/gspylib/etc/conf/cluster_config_template.xml . +具体配置文件为（标红的地方要设置成自己的）： + +
+ +## 干货内容如下： +### 1. 启用WDR报告的snapshot收集 +```sql +$ gs_guc reload -N all -I all -c "enable_wdr_snapshot=on" +postgres=# select name,setting from pg_settings where name like '%wdr%'; + name | setting +-----------------------------+--------- + enable_wdr_snapshot | on -- 开启数据库监控快照功能 + wdr_snapshot_interval | 60 -- 后台Snapshot线程执行监控快照的时间间隔 + wdr_snapshot_query_timeout | 100 -- 快照操作相关的sql语句的执行超时时间 + wdr_snapshot_retention_days | 8 -- 系统中数据库监控快照数据的保留天数 +``` +
+ +### 2. WDR信息表 +**1> snapshot.snapshot** 【记录当前系统中存储的WDR快照信息】 +```sql +postgres=# \d snapshot.snapshot + Table "snapshot.snapshot" + Column | Type | Modifiers +-------------+--------------------------+----------- + snapshot_id | bigint | not null -- WDR快照序列号 + start_ts | timestamp with time zone | -- WDR快照的开始时间 + end_ts | timestamp with time zone | -- WDR快照的结束时间 +``` +**2> snapshot.tables_snap_timestamp**【记录所有表的WDR快照信息】 +```sql +postgres=# \d snapshot.tables_snap_timestamp + Table "snapshot.tables_snap_timestamp" + Column | Type | Modifiers +-------------+--------------------------+----------- + snapshot_id | bigint | not null -- WDR快照序列号 + db_name | text | -- WDR snapshot对应的database + tablename | text | -- WDR snasphot对应的table + start_ts | timestamp with time zone | -- WDR快照的开始时间 + end_ts | timestamp with time zone | -- WDR快照的结束时间 +``` +
+ +### 3. WDR数据表 +说明：WDR的数据表保存在snapshot这个schema下以snap_开头的表，其数据来源于dbe_perf这个schema内的视图 +```sql +postgres=# select relname from pg_class where relname like '%snap_%'; +---------------------------------------------------------------------------------------------------------------- +snapshot.tables_snap_timestamp -- 记录所有存储的WDR快照中数据库、表对象、数据采集的开始、结束时间 +snapshot.snapshot -- 记录当前系统中存储的WDR快照数据的索引信息、开始、结束时间 +snapshot.snapshot_pkey -- snapshot.snapshot表的primary key +snapshot.snap_seq -- 序列 +snapshot.snap_global_os_runtime -- 操作系统运行状态信息 +snapshot.snap_global_os_threads -- 线程状态信息 +snapshot.snap_global_instance_time -- 各种时间消耗信息(时间类型见instance_time视图) +snapshot.snap_summary_workload_sql_count -- 各数据库主节点的workload上的SQL数量分布 +snapshot.snap_summary_workload_sql_elapse_time -- 数据库主节点上workload（业务）负载的SQL耗时信息 +snapshot.snap_global_workload_transaction -- 各节点上的workload的负载信息 +snapshot.snap_summary_workload_transaction -- 汇总的负载事务信息 +snapshot.snap_global_thread_wait_status -- 工作线程以及辅助线程的阻塞等待情况 +snapshot.snap_global_memory_node_detail -- 节点的内存使用情况 +snapshot.snap_global_shared_memory_detail -- 共享内存上下文的使用情况 +snapshot.snap_global_stat_db_cu -- 数据库的CU命中情况，可以通过gs_stat_reset()进行清零 +snapshot.snap_global_stat_database -- 数据库的统计信息 +snapshot.snap_summary_stat_database -- 汇总的数据库统计信息 +snapshot.snap_global_stat_database_conflicts -- 数据库冲突状态的统计信息 +snapshot.snap_summary_stat_database_conflicts -- 汇总的数据库冲突状态的统计信息 +snapshot.snap_global_stat_bad_block -- 表、索引等文件的读取失败信息 +snapshot.snap_summary_stat_bad_block -- 汇总的表、索引等文件的读取失败信息 +snapshot.snap_global_file_redo_iostat -- Redo(WAL)相关统计信息 +snapshot.snap_summary_file_redo_iostat -- 汇总的Redo(WAL)相关统计信息 +snapshot.snap_global_rel_iostat -- 数据对象IO统计信息 +snapshot.snap_summary_rel_iostat -- 汇总的数据对象IO统计信息 +snapshot.snap_global_file_iostat -- 数据文件IO统计信息 +snapshot.snap_summary_file_iostat -- 汇总的数据文件IO统计信息 +snapshot.snap_global_replication_slots -- 复制节点的信息 +snapshot.snap_global_bgwriter_stat -- 后端写进程活动的统计信息 +snapshot.snap_global_replication_stat -- 日志同步状态信息 +snapshot.snap_global_transactions_running_xacts -- 各节点运行事务的信息 +snapshot.snap_summary_transactions_running_xacts -- 汇总各节点运行事务的信息 +snapshot.snap_global_transactions_prepared_xacts -- 当前准备好进行两阶段提交的事务的信息 +snapshot.snap_summary_transactions_prepared_xacts -- 汇总的当前准备好进行两阶段提交的事务的信息 +snapshot.snap_summary_statement -- SQL语句的全量信息 +snapshot.snap_global_statement_count -- 当前时刻执行的DML/DDL/DQL/DCL语句统计信息 +snapshot.snap_summary_statement_count -- 汇总的当前时刻执行的DML/DDL/DQL/DCL语句统计信息 +snapshot.snap_global_config_settings -- 数据库运行时参数信息 +snapshot.snap_global_wait_events -- event等待相关统计信息 +snapshot.snap_summary_user_login -- 用户登录和退出次数的相关信息 +snapshot.snap_global_ckpt_status -- 实例的检查点信息和各类日志刷页情况 +snapshot.snap_global_double_write_status -- 实例的双写文件的情况 +snapshot.snap_global_pagewriter_status -- 实例的刷页信息和检查点信息 +snapshot.snap_global_redo_status -- 实例的日志回放情况 +snapshot.snap_global_rto_status -- 极致RTO状态信息 +snapshot.snap_global_recovery_status -- 主机和备机的日志流控信息 +snapshot.snap_global_threadpool_status -- 节点上的线程池中工作线程及会话的状态信息 +snapshot.snap_statement_responsetime_percentile -- SQL响应时间P80、P95分布信息 +snapshot.snap_global_statio_all_indexes -- 数据库中的每个索引行、显示特定索引的I/O的统计 +snapshot.snap_summary_statio_all_indexes -- 汇总的数据库中的每个索引行、显示特定索引的I/O的统计 +snapshot.snap_global_statio_all_sequences -- 数据库中每个序列的每一行、显示特定序列关于I/O的统计 +snapshot.snap_summary_statio_all_sequences -- 汇总的数据库中每个序列的每一行、显示特定序列关于I/O的统计 +snapshot.snap_global_statio_all_tables -- 数据库中每个表（包括TOAST表）的I/O的统计 +snapshot.snap_summary_statio_all_tables -- 汇总的数据库中每个表（包括TOAST表）的I/O的统计 +snapshot.snap_global_stat_all_indexes -- 数据库中的每个索引行，显示访问特定索引的统计 +snapshot.snap_summary_stat_all_indexes -- 汇总的数据库中的每个索引行，显示访问特定索引的统计 +snapshot.snap_summary_stat_user_functions -- 汇总的数据库节点用户自定义函数的相关统计信息 +snapshot.snap_global_stat_user_functions -- 用户所创建的函数的状态的统计信息 +snapshot.snap_global_stat_all_tables -- 每个表的一行（包括TOAST表）的统计信息 +snapshot.snap_summary_stat_all_tables -- 汇总的每个表的一行（包括TOAST表）的统计信息 +snapshot.snap_class_vital_info -- 校验相同的表或者索引的Oid是否一致 +snapshot.snap_global_record_reset_time -- 重置（重启，主备倒换，数据库删除）openGauss统计信息时间 +snapshot.snap_summary_statio_indexes_name -- 表snap_summary_statio_all_indexes的索引 +snapshot.snap_summary_statio_tables_name -- 表snap_summary_statio_all_tables的索引 +snapshot.snap_summary_stat_indexes_name -- 表snap_summary_stat_all_indexes的索引 +snapshot.snap_class_info_name -- 表snap_class_vital_info的索引 +(66 rows) +---------------------------------------------------------------------------------------------------------------- +``` +
+ +### 4. WDR报告创建 +#### 4.1 创建snapshot +```sql +-- 当开启enable_wdr_snapshot参数时，数据库默认每小时自动执行一次snapshot操作。 +-- 当然特定情况下，也可以手动使用函数创建snapshot，如：select create_wdr_snapshot(); +postgres=# select * from snapshot.snapshot offset 20; + snapshot_id | start_ts | end_ts +-------------+-------------------------------+------------------------------- + 21 | 2021-04-21 05:59:09.337877+08 | 2021-04-21 05:59:10.249162+08 + 22 | 2021-04-21 06:59:10.3209+08 | 2021-04-21 06:59:11.229808+08 + 23 | 2021-04-21 07:59:10.426882+08 | 2021-04-21 07:59:11.340277+08 + 24 | 2021-04-21 08:59:10.534251+08 | 2021-04-21 08:59:11.447762+08 + 25 | 2021-04-21 09:59:11.448225+08 | 2021-04-21 09:59:26.121124+08 +``` +#### 4.2 查询数据库节点信息 +```sql +postgres=# select * from pg_node_env; + node_name | host | process | port | installpath | datapath | log_directory +-----------+--------------+---------+-------+--------------+-------------------+--------------------------------- + dn_6001 | 192.168.0.99 | 9442 | 26000 | /gaussdb/app | /gaussdb/data/db1 | /gaussdb/log/omm/pg_log/dn_6001 +``` +#### 4.3 创建WDR Report[使用gsql客户端生成] +```sql +postgres=# \a \t \o WDR_20210421.html -- 打开格式化输出，输出WDR报告：WDR_20210421.html +postgres=# select generate_wdr_report(24,25,'all','node','dn_6001'); -- 生成WDR报告 +postgres=# \o \a \t -- 关闭格式化输出 +``` +**函数说明：generate_wdr_report()** +```sql +-- 语法 +select generate_wdr_report(begin_snap_id bigint, end_snap_id bigint, report_type cstring, report_scope cstring, node_name cstring); +-- 选项： +begin_snap_id：查询时间段开始的snapshot的id（表snapshot.snaoshot中的snapshot_id） +end_snap_id： 查询时间段结束snapshot的id。默认end_snap_id大于begin_snap_id（表snapshot.snaoshot中的snapshot_id） +report_type： 指定生成report的类型。例如，summary/detail/all，其中：summary[汇总数据]/detail[明细数据]/all[包含summary和detail] +report_scope： 指定生成report的范围，可以为cluster或者node，其中：cluster是数据库级别的信息，node是节点级别的信息。 +node_name： 当report_scope指定为node时，需要把该参数指定为对应节点的名称。当report_scope为cluster时，该值可以省略或者指定为空或NULL。node[节点名称]、cluster[省略/空/NULL] +``` +
+ +### 5. WDR报告解读 +说明：为了使得WDR报告内容不空洞，本次在测试环境使用BenchmarkSQL对openGauss数据库进行压力测试。 本次解读的WDR报告样例来自于此时采集的snapshot数据。 + +**解读：** +这一部分是WDR报告的概况信息，从这一部分我们能得到如下信息： + +
| 信息分类 | 信息描述 |
| 报告采集类型 | Summary + Detail，即汇总数据+明细数据 |
| Snapshot信息 | 使用snapshot_id为24和25的快照采集2021-04-21(08:59 ~ 09:59)的运行信息 |
| 硬件配置 | 1*1c/4g |
| 节点名 | dn_6001 |
| openGauss版本 | openGauss 2.0.0 |
wait_event类型 | |
|---|---|
+
+- 事务锁等待事件列表
+当wait_status值为acquire lock（事务锁）时对应的wait_event等待事件类型为事务锁等待事件。
+
+|wait_event类型 |类型描述|
+|-|-|
+|relation|对表加锁|
+|extend|对表扩展空间时加锁|
+|partition|对分区表加锁|
+|partition_seq|对分区表的分区加锁|
+|page|对表页面加锁|
+|tuple|对页面上的tuple加锁|
+|transactionid|对事务ID加锁|
+|virtualxid|对虚拟事务ID加锁|
+|object|加对象锁|
+|cstore_freespace|对列存空闲空间加锁|
+|userlock|加用户锁|
+|advisory|加advisory锁|
+
+**相关代码：**
+```sql
+-- 说明：变量ld-->snapshot_id, 变量s-->node_name
+select snap_event as "Event",
+ snap_wait as "Waits",
+ snap_total_wait_time as "Total Wait Times(us)",
+ round(snap_total_wait_time/snap_wait) as "Wait Avg(us)",
+ snap_type as "Wait Class"
+from (
+ select snap_2.snap_event as snap_event,
+ snap_2.snap_type as snap_type,
+ snap_2.snap_wait - snap_1.snap_wait as snap_wait,
+ snap_2.total_time - snap_1.total_time as snap_total_wait_time
+ from
+ (select snap_event,
+ snap_wait,
+ snap_total_wait_time as total_time,
+ snap_type
+ from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_event != 'none'
+ and snap_event != 'wait cmd'
+ and snap_event != 'unknown_lwlock_event'
+ and snap_nodename = '%s') snap_1,
+ (select snap_event,
+ snap_wait,
+ snap_total_wait_time as total_time,
+ snap_type
+ from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_event != 'none'
+ and snap_event != 'wait cmd'
+ and snap_event != 'unknown_lwlock_event'
+ and snap_nodename = '%s') snap_2
+ where snap_2.snap_event = snap_1.snap_event
+ order by snap_total_wait_time desc limit 10)
+where snap_wait != 0;
+```
+
+**解读：**
+这一部分按照等待类型（STATUS、IO_EVENT、LWLOCK_EVENT、LOCK_EVENT），分类统计等待次数、总等待时间、平均等待时间。
+**相关代码：**
+
+```sql
+-- 说明： 变量ld-->snapshot_id, 变量s-->node_name
+select
+ snap_2.type as "Wait Class",
+ (snap_2.wait - snap_1.wait) as "Waits",
+ (snap_2.total_wait_time - snap_1.total_wait_time) as "Total Wait Time(us)",
+ round((snap_2.total_wait_time - snap_1.total_wait_time) / greatest((snap_2.wait - snap_1.wait), 1)) as "Wait Avg(us)"
+from
+ (select
+ snap_type as type,
+ sum(snap_total_wait_time) as total_wait_time,
+ sum(snap_wait) as wait from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_nodename = '%s'
+ and snap_event != 'unknown_lwlock_event'
+ and snap_event != 'none'
+ group by snap_type) snap_2
+ left join
+ (select
+ snap_type as type,
+ sum(snap_total_wait_time) as total_wait_time,
+ sum(snap_wait) as wait
+ from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_nodename = '%s'
+ and snap_event != 'unknown_lwlock_event' and snap_event != 'none'
+ group by snap_type) snap_1
+ on snap_2.type = snap_1.type
+ order by "Total Wait Time(us)" desc;
+```
+
+**解读：**
+这一部分主机CPU的负载情况：CPU的平均负载、用户使用占比、系统使用占比、IO等待占比、空闲占比。
+**相关SQL：**
+
+```sql
+select
+ snap_2.cpus as "Cpus",
+ snap_2.cores as "Cores",
+ snap_2.sockets as "Sockets",
+ snap_1.load as "Load Average Begin",
+ snap_2.load as "Load Average End",
+ round(coalesce((snap_2.user_time - snap_1.user_time), 0) / greatest(coalesce((snap_2.total_time - snap_1.total_time), 0), 1) * 100, 2) as "%User",
+ round(coalesce((snap_2.sys_time - snap_1.sys_time), 0) / greatest(coalesce((snap_2.total_time - snap_1.total_time), 0), 1) * 100, 2) as "%System",
+ round(coalesce((snap_2.iowait_time - snap_1.iowait_time), 0) / greatest(coalesce((snap_2.total_time - snap_1.total_time), 0), 1) * 100, 2) as "%WIO",
+ round(coalesce((snap_2.idle_time - snap_1.idle_time), 0) / greatest(coalesce((snap_2.total_time - snap_1.total_time), 0), 1) * 100, 2) as "%Idle"
+from
+ (select H.cpus, H.cores, H.sockets, H.idle_time, H.user_time, H.sys_time, H.iowait_time,
+ (H.idle_time + H.user_time + H.sys_time + H.iowait_time) AS total_time, H.load from
+ (select C.cpus, E.cores, T.sockets, I.idle_time, U.user_time, S.sys_time, W.iowait_time, L.load from
+ (select snap_value as cpus from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPUS')) AS C,
+ (select snap_value as cores from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPU_CORES')) AS E,
+ (select snap_value as sockets from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPU_SOCKETS')) AS T,
+ (select snap_value as idle_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'IDLE_TIME')) AS I,
+ (select snap_value as user_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'USER_TIME')) AS U,
+ (select snap_value as sys_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'SYS_TIME')) AS S,
+ (select snap_value as iowait_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'IOWAIT_TIME')) AS W,
+ (select snap_value as load from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'LOAD')) AS L ) as H ) as snap_2,
+
+ (select H.cpus, H.cores, H.sockets, H.idle_time, H.user_time, H.sys_time, H.iowait_time,
+ (H.idle_time + H.user_time + H.sys_time + H.iowait_time) AS total_time, H.load from
+ (select C.cpus, E.cores, T.sockets, I.idle_time, U.user_time, S.sys_time, W.iowait_time, L.load from
+ (select snap_value as cpus from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPUS')) AS C,
+ (select snap_value as cores from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPU_CORES')) AS E,
+ (select snap_value as sockets from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'NUM_CPU_SOCKETS')) AS T,
+ (select snap_value as idle_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'IDLE_TIME')) AS I,
+ (select snap_value as user_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'USER_TIME')) AS U,
+ (select snap_value as sys_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'SYS_TIME')) AS S,
+ (select snap_value as iowait_time from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'IOWAIT_TIME')) AS W,
+ (select snap_value as load from snapshot.snap_global_os_runtime
+ where (snapshot_id = %ld and snap_node_name = '%s' and snap_name = 'LOAD')) AS L ) as H ) as snap_1 ;
+```
+
+**解读：**
+这一部分描述了openGauss在快照期间的IO负载情况。
+**Database requests：** 即每秒IO请求次数，包括请求次数总和、读请求次数、写请求次数.
+**Database(blocks)：** 即每秒block请求数量，包含请求的block总和数量、读block的数量和写block的数量.
+**Database(MB):** 即将block换算成容量(MB)[如：blocks * 8/1024]，增加数据的可读性。
+**Redo requests和Redo(MB)** 分别表示每秒redo的写请求次数和redo写的数据量。
+相关代码：
+
+```sql
+-- 由于源码中相关SQL融合了C++程序语法，像我这种不做开发的DBA读起来有些难以理解【如：(phyblkwrt * %d) >> 20 这个段没有很好理解】。
+-- 但是依旧不影响我们对这些数据采集方法的理解，相关SQL如下：
+-- 两个snapshot_id(24和25)期间，数据块的IO统计信息(数值除以3600即换算成以秒为单位的WDR数据)
+postgres=# select
+ (snap_2.phytotal - snap_1.phytotal) as phytotal,
+ (snap_2.phyblktotal - snap_1.phyblktotal) as phyblktotal,
+ (snap_2.phyrds - snap_1.phyrds) as phyrds,
+ (snap_2.phyblkrd - snap_1.phyblkrd) as phyblkrd,
+ (snap_2.phywrts - snap_1.phywrts) as phywrts,
+ (snap_2.phyblkwrt - snap_1.phyblkwrt) as phyblkwrt
+ from
+ (select (snap_phyrds + snap_phywrts) as phytotal,
+ (snap_phyblkwrt + snap_phyblkrd) as phyblktotal,
+ snap_phyrds as phyrds, snap_phyblkrd as phyblkrd,
+ snap_phywrts as phywrts, snap_phyblkwrt as phyblkwrt
+ from snapshot.snap_global_rel_iostat
+ where snapshot_id = 24 and snap_node_name = 'dn_6001') snap_1,
+ (select (snap_phyrds + snap_phywrts) as phytotal,
+ (snap_phyblkwrt + snap_phyblkrd) as phyblktotal,
+ snap_phyrds as phyrds, snap_phyblkrd as phyblkrd,
+ snap_phywrts as phywrts, snap_phyblkwrt as phyblkwrt
+ from snapshot.snap_global_rel_iostat
+ where snapshot_id = 25 and snap_node_name = 'dn_6001') snap_2;
+ phytotal | phyblktotal | phyrds | phyblkrd | phywrts | phyblkwrt
+----------+-------------+---------+----------+---------+-----------
+ 4626892 | 4626892 | 2955639 | 2955639 | 1671253 | 1671253
+
+-- 两个snapshot_id(24和25)期间，redo的统计信息(数值除以3600即换算成以秒为单位的WDR数据)
+postgres=# select
+ (snap_2.phywrts - snap_1.phywrts) as phywrts,
+ (snap_2.phyblkwrt - snap_1.phyblkwrt) as phyblkwrt
+ from
+ (select sum(snap_phywrts) as phywrts, sum(snap_phyblkwrt) as phyblkwrt
+ from snapshot.snap_global_file_redo_iostat
+ where snapshot_id = 24 and snap_node_name = 'dn_6001') snap_1,
+ (select sum(snap_phywrts) as phywrts, sum(snap_phyblkwrt) as phyblkwrt
+ from snapshot.snap_global_file_redo_iostat
+ where snapshot_id = 25 and snap_node_name = 'dn_6001') snap_2;
+ phywrts | phyblkwrt
+---------+-----------
+ 132721 | 509414
+```
+
+**解读：**
+ 这一部分描述了节点内存的变化信息,通过这些变化信息，我们可以了解到在两次快照期间，数据库的内存变化情况，作为数据库性能分析或异常分析的参考。数据来源于snapshot.snap_global_memory_node_detail。
+**这部分分别描述了：** 内存的类型 以及 对应的起始大小和终止大小。
+**这里没有采集到数据的原因：** 测试环境内存太小，导致启动时将memory protect关闭了，从而导致无法查询dbe_perf.global_memory_node_detail视图。 而WDR的内存统计数据(snapshot.snap_global_memory_node_detail)则来源于该视图。
+另外，请确保disable_memory_protect=off。
+关于这部分Memory Type常见类型如下：
+
+|Memory 类型|说明|
+|-|-|
+|max_process_memory |openGauss实例所占用的内存大小|
+|process_used_memory|进程所使用的内存大小|
+|max_dynamic_memory |最大动态内存|
+|dynamic_used_memory|已使用的动态内存|
+|dynamic_peak_memory|内存的动态峰值|
+|dynamic_used_shrctx|最大动态共享内存上下文|
+|dynamic_peak_shrctx|共享内存上下文的动态峰值|
+|max_shared_memory |最大共享内存|
+|shared_used_memory |已使用的共享内存|
+|max_cstore_memory |列存所允许使用的最大内存|
+|cstore_used_memory |列存已使用的内存大小|
+|max_sctpcomm_memory|sctp通信所允许使用的最大内存|
+|sctpcomm_used_memory|sctp通信已使用的内存大小|
+|sctpcomm_peak_memory|sctp通信的内存峰值|
+|other_used_memory |其他已使用的内存大小|
+|gpu_max_dynamic_memory |GPU最大动态内存|
+|gpu_dynamic_used_memory|GPU已使用的动态内存|
+|gpu_dynamic_peak_memory|GPU内存的动态峰值|
+|pooler_conn_memory |链接池申请内存计数|
+|pooler_freeconn_memory |链接池空闲连接的内存计数|
+|storage_compress_memory|存储模块压缩使用的内存大小|
+|udf_reserved_memory |UDF预留的内存大小|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select
+ snap_2.snap_memorytype as "Memory Type",
+ snap_1.snap_memorymbytes as "Begin(MB)",
+ snap_2.snap_memorymbytes as "End(MB)"
+from
+ (select snap_memorytype, snap_memorymbytes
+ from
+ snapshot.snap_global_memory_node_detail
+ where (snapshot_id = %ld and snap_nodename = '%s')
+ and
+ (snap_memorytype = 'max_process_memory'
+ or snap_memorytype = 'process_used_memory'
+ or snap_memorytype = 'max_shared_memory'
+ or snap_memorytype = 'shared_used_memory'))
+ as snap_2
+left join
+ (select snap_memorytype, snap_memorymbytes
+ from
+ snapshot.snap_global_memory_node_detail
+ where (snapshot_id = %ld and snap_nodename = '%s')
+ and (snap_memorytype = 'max_process_memory'
+ or snap_memorytype = 'process_used_memory'
+ or snap_memorytype = 'max_shared_memory'
+ or snap_memorytype = 'shared_used_memory'))
+ as snap_1
+on snap_2.snap_memorytype = snap_1.snap_memorytype;
+```
+
+**解读：**
+这一部分描述了数据库各种状态所消耗的时间，关于Stat Name的解释如下：
+
+|Stat Name|说明|
+|-|-|
+|DB_TIME| 作业在多核下的有效时间花销|
+|CPU_TIME|CPU的时间花销|
+|EXECUTION_TIME|执行器内的时间花销|
+|PARSE_TIME| SQL解析的时间花销|
+|PLAN_TIME| 生成Plan的时间花销|
+|REWRITE_TIME| SQL重写的时间花销|
+|PL_EXECUTION_TIME | plpgsql（存储过程）执行的时间花销|
+|PL_COMPILATION_TIME|plpgsql（存储过程）编译的时间花销|
+|NET_SEND_TIME|网络上的时间花销|
+|DATA_IO_TIME| IO上的时间花销|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select t2.snap_node_name as "Node Name",
+ t2.snap_stat_name as "Stat Name",
+ (t2.snap_value - coalesce(t1.snap_value, 0)) as "Value(us)"
+from
+ (select * from snapshot.snap_global_instance_time
+ where snapshot_id = %ld
+ and snap_node_name = '%s') t1
+right join
+ (select * from snapshot.snap_global_instance_time
+ where snapshot_id = %ld
+ and snap_node_name = '%s') t2
+on t1.snap_stat_name = t2.snap_stat_name
+order by "Value(us)"
+desc limit 200;
+```
+
+
+
+**解读：**
+这一部分分别从SQL执行时间、SQL消耗CPU的时间、SQL返回的行数、SQL扫描的行数、SQL执行的次数、SQL物理读的次数、SQL逻辑读的次数等多维度对两次快照期间的SQL执行情况进行统计。
+关于表中列的含义，如下所示：
+
+|列名称| 备注|
+|-|-|
+|Unique SQL Id| 归一化的SQL ID, 即SQL唯一标识|
+|User Name| 执行SQL的用户|
+|Logical Read| 逻辑读，即Buffer的块访问次数|
+|Calls| SQL的调用次数|
+|Min Elapse Time(us)| SQL在内核中的最小运行时间（单位：微秒）|
+|Max Elapse Time(us)| SQL在内核中的最大运行时间（单位：微秒）|
+|Total Elapse Time(us)| SQL在内核中的总运行时间 （单位：微秒）|
+|Avg Elapse Time(us)| SQL在内核中的平均运行时间（单位：微秒）|
+|Returned Rows| SELECT返回的结果集行数|
+|Tuples Read| SQL扫描的总行数(包括顺序扫描和随机扫描)|
+|Tuples Affected| SQL删除的行数|
+|Physical Read| 物理读，即下盘读取block进入buffer的次数|
+|CPU Time(us)| SQL消耗的CPU时间（单位：微秒）|
+|Data IO Time(us)| IO上的时间花费（单位：微秒）|
+|Sort Count| SQL排序执行的次数|
+|Sort Time(us)| SQL排序执行的时间（单位：微秒）|
+|Sort Mem Used(KB)| 排序过程中使用的work memory大小（单位：KB）|
+|Sort Spill Count| 排序过程中发生落盘写文件的次数|
+|Sort Spill Size(KB)| 排序过程中发生落盘写文件的大小（单位：KB）|
+|Hash Count| hash执行的次数|
+|Hash Time(us)| hash执行的时间（单位：微秒）|
+|Hash Mem Used(KB)| hash过程中使用的work memory大小（单位：KB）|
+|Hash Spill Count| hash过程中发生落盘写文件的次数|
+|Hash Spill Size(KB)| hash过程中发生落盘写文件的大小（单位：KB）|
+|SQL Text| SQL语句内容|
+Tips：Top200显得有些冗余，多余的SQL信息并没有太大用处，反而降低了可读性，希望将来能优化到Top20,。
+**相关代码：**
+```sql
+-- 由于多个SQL统计信息的SQL语句类似，这里仅列举SQL执行时间的统计SQL，其他的类似。
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select t2.snap_unique_sql_id as "Unique SQL Id",
+ t2.snap_user_name as "User Name",
+ (t2.snap_total_elapse_time - coalesce(t1.snap_total_elapse_time, 0)) as "Total Elapse Time(us)",
+ (t2.snap_n_calls - coalesce(t1.snap_n_calls, 0)) as "Calls",
+ round("Total Elapse Time(us)"/greatest("Calls", 1), 0) as "Avg Elapse Time(us)",
+ t2.snap_min_elapse_time as "Min Elapse Time(us)",
+ t2.snap_max_elapse_time as "Max Elapse Time(us)",
+ (t2.snap_n_returned_rows - coalesce(t1.snap_n_returned_rows, 0)) as "Returned Rows",
+ ((t2.snap_n_tuples_fetched - coalesce(t1.snap_n_tuples_fetched, 0)) +
+ (t2.snap_n_tuples_returned - coalesce(t1.snap_n_tuples_returned, 0))) as "Tuples Read",
+ ((t2.snap_n_tuples_inserted - coalesce(t1.snap_n_tuples_inserted, 0)) +
+ (t2.snap_n_tuples_updated - coalesce(t1.snap_n_tuples_updated, 0)) +
+ (t2.snap_n_tuples_deleted - coalesce(t1.snap_n_tuples_deleted, 0))) as "Tuples Affected",
+ (t2.snap_n_blocks_fetched - coalesce(t1.snap_n_blocks_fetched, 0)) as "Logical Read",
+ ((t2.snap_n_blocks_fetched - coalesce(t1.snap_n_blocks_fetched, 0)) -
+ (t2.snap_n_blocks_hit - coalesce(t1.snap_n_blocks_hit, 0))) as "Physical Read",
+ (t2.snap_cpu_time - coalesce(t1.snap_cpu_time, 0)) as "CPU Time(us)",
+ (t2.snap_data_io_time - coalesce(t1.snap_data_io_time, 0)) as "Data IO Time(us)",
+ (t2.snap_sort_count - coalesce(t1.snap_sort_count, 0)) as "Sort Count",
+ (t2.snap_sort_time - coalesce(t1.snap_sort_time, 0)) as "Sort Time(us)",
+ (t2.snap_sort_mem_used - coalesce(t1.snap_sort_mem_used, 0)) as "Sort Mem Used(KB)",
+ (t2.snap_sort_spill_count - coalesce(t1.snap_sort_spill_count, 0)) as "Sort Spill Count",
+ (t2.snap_sort_spill_size - coalesce(t1.snap_sort_spill_size, 0)) as "Sort Spill Size(KB)",
+ (t2.snap_hash_count - coalesce(t1.snap_hash_count, 0)) as "Hash Count",
+ (t2.snap_hash_time - coalesce(t1.snap_hash_time, 0)) as "Hash Time(us)",
+ (t2.snap_hash_mem_used - coalesce(t1.snap_hash_mem_used, 0)) as "Hash Mem Used(KB)",
+ (t2.snap_hash_spill_count - coalesce(t1.snap_hash_spill_count, 0)) as "Hash Spill Count",
+ (t2.snap_hash_spill_size - coalesce(t1.snap_hash_spill_size, 0)) as "Hash Spill Size(KB)",
+ LEFT(t2.snap_query, 25) as "SQL Text"
+from
+ (select * from snapshot.snap_summary_statement where snapshot_id = %ld and snap_node_name = '%s') t1
+ right join
+ (select * from snapshot.snap_summary_statement where snapshot_id = %ld and snap_node_name = '%s') t2
+ on t1.snap_unique_sql_id = t2.snap_unique_sql_id
+ and t1.snap_user_id = t2.snap_user_id
+ order by "Total Elapse Time(us)"
+ desc limit 200;
+```
+
+**解读：**
+这一部分分别从等待时长、等待次数这两个维度对等待事件进行统计。
+表格中列的含义即就是列的英文翻译，这里就不再复述了。
+具体的等待事件的介绍详见前文：“Top 10 Events by Total Wait Time”部分的内容，这里也不再复述。
+**相关代码：**
+
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id，无论从哪个维度统计，基本的SQL语句差异不大，这里仅列举"by wait time"的SQL示例
+select t2.snap_type as "Type",
+ t2.snap_event as "Event",
+ (t2.snap_total_wait_time - coalesce(t1.snap_total_wait_time, 0)) as "Total Wait Time (us)",
+ (t2.snap_wait - coalesce(t1.snap_wait, 0)) as "Waits",
+ (t2.snap_failed_wait - coalesce(t1.snap_failed_wait, 0)) as "Failed Waits",
+ (case "Waits"
+ when 0 then 0
+ else round("Total Wait Time (us)" / "Waits", 2)
+ end) as "Avg Wait Time (us)",
+ t2.snap_max_wait_time as "Max Wait Time (us)"
+from
+ (select * from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_nodename = '%s'
+ and snap_event != 'unknown_lwlock_event'
+ and snap_event != 'none') t1
+right join
+ (select * from snapshot.snap_global_wait_events
+ where snapshot_id = %ld
+ and snap_nodename = '%s'
+ and snap_event != 'unknown_lwlock_event'
+ and snap_event != 'none') t2
+on t1.snap_event = t2.snap_event
+order by "Total Wait Time (us)"
+desc limit 200;
+```
+
+**解读：**
+这一部分根据Heap block的命中率排序统计用户表的IO活动状态。
+数据来源于snapshot.snap_global_statio_all_indexes表和snapshot.snap_global_statio_all_tables表。
+该表相关列的介绍如下：
+
+|列名|描述|
+|-|-|
+|DB Name| 数据库名|
+|Schema Name| 模式名|
+|Table Name| 表名|
+|%Heap Blks Hit Ratio| 数据块读取缓存命中率=heap_blks_hit/(heap_blks_read+heap_blks_hit)*100|
+|Heap Blks Read| 从该表中读取的磁盘块数|
+|Heap Blks Hit| 此表缓存命中数|
+|Idx Blks Read| 从表中所有索引读取的磁盘块数|
+|Idx Blks Hit| 表中所有索引命中缓存数|
+|Toast Blks Read| 此表的TOAST表读取的磁盘块数（如果存在）|
+|Toast Blks Hit| 此表的TOAST表命中缓冲区数（如果存在）|
+|Tidx Blks Read| 此表的TOAST表索引读取的磁盘块数（如果存在）|
+|Tidx Blks Hit| 此表的TOAST表索引命中缓冲区数（如果存在）|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+SELECT table_io.db_name as "DB Name",
+ table_io.snap_schemaname as "Schema Name",
+ table_io.snap_relname as "Table Name",
+ table_io.heap_blks_hit_ratio as "%Heap Blks Hit Ratio",
+ table_io.heap_blks_read as "Heap Blks Read",
+ table_io.heap_blks_hit as "Heap Blks Hit",
+ idx_io.idx_blks_read as "Idx Blks Read",
+ idx_io.idx_blks_hit as "Idx Blks Hit",
+ table_io.toast_blks_read as "Toast Blks Read",
+ table_io.toast_blks_hit as "Toast Blks Hit",
+ table_io.tidx_blks_read as "Tidx Blks Read",
+ table_io.tidx_blks_hit as "Tidx Blks Hit"
+FROM
+ (select t2.db_name, t2.snap_schemaname , t2.snap_relname ,
+ (case
+ when ((t2.snap_heap_blks_read - coalesce(t1.snap_heap_blks_read, 0)) + (t2.snap_heap_blks_hit - coalesce(t1.snap_heap_blks_hit, 0))) = 0
+ then 0
+ else round((t2.snap_heap_blks_hit - coalesce(t1.snap_heap_blks_hit, 0))/
+ ((t2.snap_heap_blks_read - coalesce(t1.snap_heap_blks_read, 0)) + (t2.snap_heap_blks_hit - coalesce(t1.snap_heap_blks_hit, 0))) * 100, 2)
+ end ) as heap_blks_hit_ratio,
+ (t2.snap_heap_blks_read - coalesce(t1.snap_heap_blks_read, 0)) as heap_blks_read,
+ (t2.snap_heap_blks_hit - coalesce(t1.snap_heap_blks_hit, 0)) as heap_blks_hit,
+ (t2.snap_idx_blks_read - coalesce(t1.snap_idx_blks_read, 0)) as idx_blks_read,
+ (t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0)) as idx_blks_hit,
+ (t2.snap_toast_blks_read - coalesce(t1.snap_toast_blks_read, 0)) as toast_blks_read,
+ (t2.snap_toast_blks_hit - coalesce(t1.snap_toast_blks_hit, 0)) as toast_blks_hit,
+ (t2.snap_tidx_blks_read - coalesce(t1.snap_tidx_blks_read, 0)) as tidx_blks_read,
+ (t2.snap_tidx_blks_hit - coalesce(t1.snap_tidx_blks_hit, 0)) as tidx_blks_hit from
+ (select * from snapshot.snap_global_statio_all_tables
+ where snapshot_id = %ld and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') t1
+ right join
+ (select * from snapshot.snap_global_statio_all_tables
+ where snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') t2
+ on t1.snap_relid = t2.snap_relid
+ and t2.db_name = t1.db_name
+ and t2.snap_schemaname = t1.snap_schemaname ) as table_io
+LEFT JOIN
+ (select t2.db_name , t2.snap_schemaname , t2.snap_relname,
+ (t2.snap_idx_blks_read - coalesce(t1.snap_idx_blks_read, 0)) as idx_blks_read,
+ (t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0)) as idx_blks_hit
+ from
+ (select * from snapshot.snap_global_statio_all_indexes
+ where snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') t1
+ right join
+ (select * from snapshot.snap_global_statio_all_indexes
+ where snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ AND snap_schemaname !~ '^pg_toast') t2
+ on t1.snap_relid = t2.snap_relid
+ and t2.snap_indexrelid = t1.snap_indexrelid
+ and t2.db_name = t1.db_name and t2.snap_schemaname = t1.snap_schemaname) as idx_io
+on table_io.db_name = idx_io.db_name
+and table_io.snap_schemaname = idx_io.snap_schemaname
+and table_io.snap_relname = idx_io.snap_relname
+order by "%%Heap Blks Hit Ratio"
+asc limit 200;
+```
+
+**解读：**
+这一部分根据索引缓存命中率，统计用户索引IO活动信息。
+数据来源于snapshot.snap_global_statio_all_indexes表。
+相关列信息如下：
+
+|列名| 介绍|
+|-|-|
+|DB Name| 数据库名|
+|Schema Name| 模式名|
+|Table Name| 表名|
+|Index Name| 索引名|
+|%Idx Blks Hit Ratio| 索引缓冲命中率="Idx Blks Hit"/("Idx Blks Hit"+"Idx Blks Read")*100|
+|Idx Blks Read| 从索引中读取的磁盘块数|
+|Idx Blks Hit| 索引命中缓存数|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select t2.db_name as "DB Name",
+ t2.snap_schemaname as "Schema Name",
+ t2.snap_relname as "Table Name",
+ t2.snap_indexrelname as "Index Name",
+ (case
+ when ((t2.snap_idx_blks_read - coalesce(t1.snap_idx_blks_read, 0)) + (t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0))) = 0 then 0
+ else
+ round((t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0))/((t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0)) +
+ (t2.snap_idx_blks_read - coalesce(t1.snap_idx_blks_read, 0))) * 100, 2)
+ end) as "%Idx Blks Hit Ratio",
+ (t2.snap_idx_blks_read - coalesce(t1.snap_idx_blks_read, 0)) as "Idx Blks Read",
+ (t2.snap_idx_blks_hit - coalesce(t1.snap_idx_blks_hit, 0)) as "Idx Blks Hit"
+from
+ (select * from snapshot.snap_global_statio_all_indexes
+ where snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') t1
+right join
+ (select * from snapshot.snap_global_statio_all_indexes
+ where snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') t2
+on t1.snap_relid = t2.snap_relid
+and t2.snap_indexrelid = t1.snap_indexrelid
+and t2.db_name = t1.db_name
+and t2.snap_schemaname = t1.snap_schemaname
+order by "%Idx Blks Hit Ratio"
+asc limit 200;
+```
+
+**解读：**
+**此处存在缺陷，统计的数据有问题，个人认为SQL语句需要修改，详见“相关代码”。**
+这一部分描述的是后台写操作的统计信息，数据来源于snapshot.snap_global_bgwriter_stat表。
+具体内容如下：
+
+|列名| 数据获取相关函数| 说明|
+|-|-|-|
+|Checkpoints Timed| pg_stat_get_bgwriter_timed_checkpoints()| 执行的定期检查点数|
+|Checkpoints Require| pg_stat_get_bgwriter_requested_checkpoints()| 执行的需求检查点数|
+|Checkpoint Write Time(ms)| pg_stat_get_checkpoint_write_time()| 检查点操作中，文件写入到磁盘消耗的时间（单位：毫秒）|
+|Checkpoint Sync Time(ms)| pg_stat_get_checkpoint_sync_time()| 检查点操作中，文件同步到磁盘消耗的时间（单位：毫秒）|
+|Buffers Checkpoint| pg_stat_get_bgwriter_buf_written_checkpoints()| 检查点写缓冲区数量|
+|Buffers Clean| pg_stat_get_bgwriter_buf_written_clean()| 后端写线程写缓冲区数量|
+|Maxwritten Clean| pg_stat_get_bgwriter_maxwritten_clean()| 后端写线程停止清理Buffer的次数|
+|Buffers Backend| pg_stat_get_buf_written_backend()| 通过后端直接写缓冲区数|
+|Buffers Backend| Fsync pg_stat_get_buf_fsync_backend()| 后端不得不执行自己的fsync调用的时间数（通常后端写进程处理这些即使后端确实自己写）|
+|Buffers Alloc| pg_stat_get_buf_alloc() 分配的缓冲区数量|
+|Stats Reset| pg_stat_get_bgwriter_stat_reset_time()| 这些统计被重置的时间|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select (snap_2.snap_checkpoints_timed - coalesce(snap_1.snap_checkpoints_timed, 0)) AS "Checkpoints Timed",
+ (snap_2.snap_checkpoints_req - coalesce(snap_1.snap_checkpoints_req, 0)) AS "Checkpoints Require",
+ (snap_2.snap_checkpoint_write_time - coalesce(snap_1.snap_checkpoint_write_time, 0)) AS "Checkpoint Write Time(ms)",
+ (snap_2.snap_checkpoint_sync_time - coalesce(snap_1.snap_checkpoint_sync_time, 0)) AS "Checkpoint Sync Time(ms)",
+ (snap_2.snap_buffers_checkpoint - coalesce(snap_1.snap_buffers_checkpoint, 0)) AS "Buffers Checkpoint",
+ (snap_2.snap_buffers_clean - coalesce(snap_1.snap_buffers_clean, 0)) AS "Buffers Clean",
+ (snap_2.snap_maxwritten_clean - coalesce(snap_1.snap_maxwritten_clean, 0)) AS "Maxwritten Clean",
+ (snap_2.snap_buffers_backend - coalesce(snap_1.snap_buffers_backend, 0)) AS "Buffers Backend",
+ (snap_2.snap_buffers_backend_fsync - coalesce(snap_1.snap_buffers_backend_fsync, 0)) AS "Buffers Backend Fsync",
+ (snap_2.snap_buffers_alloc - coalesce(snap_1.snap_buffers_alloc, 0)) AS "Buffers Alloc",
+ to_char(snap_2.snap_stats_reset, 'YYYY-MM-DD HH24:MI:SS') AS "Stats Reset"
+from
+ (select * from snapshot.snap_global_bgwriter_stat
+ where snapshot_id = %ld
+ and snap_node_name = '%s') snap_2
+LEFT JOIN
+ (select * from snapshot.snap_global_bgwriter_stat
+ where snapshot_id = %ld
+ and snap_node_name = '%s') snap_1
+on snap_2.snapshot_id = snap_1.snapshot_id --错误点：snap_2.snapshot_id = snap_1.snapshot_id ？ 这其实还是同一个snapshot
+and snap_2.snap_node_name = snap_1.snap_node_name
+and snap_2.snap_stats_reset = snap_1.snap_stats_reset
+limit 200;
+
+-- 统计信息应该是2次snapshot之间的数据，而以上SQL并不能正确输出相关数据。个人觉得可以删除LEFT JOIN连接。
+-- 建议修改如下：
+select (snap_2.snap_checkpoints_timed - coalesce(snap_1.snap_checkpoints_timed, 0)) AS "Checkpoints Timed",
+ (snap_2.snap_checkpoints_req - coalesce(snap_1.snap_checkpoints_req, 0)) AS "Checkpoints Require",
+ (snap_2.snap_checkpoint_write_time - coalesce(snap_1.snap_checkpoint_write_time, 0)) AS "Checkpoint Write Time(ms)",
+ (snap_2.snap_checkpoint_sync_time - coalesce(snap_1.snap_checkpoint_sync_time, 0)) AS "Checkpoint Sync Time(ms)",
+ (snap_2.snap_buffers_checkpoint - coalesce(snap_1.snap_buffers_checkpoint, 0)) AS "Buffers Checkpoint",
+ (snap_2.snap_buffers_clean - coalesce(snap_1.snap_buffers_clean, 0)) AS "Buffers Clean",
+ (snap_2.snap_maxwritten_clean - coalesce(snap_1.snap_maxwritten_clean, 0)) AS "Maxwritten Clean",
+ (snap_2.snap_buffers_backend - coalesce(snap_1.snap_buffers_backend, 0)) AS "Buffers Backend",
+ (snap_2.snap_buffers_backend_fsync - coalesce(snap_1.snap_buffers_backend_fsync, 0)) AS "Buffers Backend Fsync",
+ (snap_2.snap_buffers_alloc - coalesce(snap_1.snap_buffers_alloc, 0)) AS "Buffers Alloc",
+ to_char(snap_2.snap_stats_reset, 'YYYY-MM-DD HH24:MI:SS') AS "Stats Reset"
+from
+ (select * from snapshot.snap_global_bgwriter_stat
+ where snapshot_id = %ld
+ and snap_node_name = '%s') snap_2,
+ (select * from snapshot.snap_global_bgwriter_stat
+ where snapshot_id = %ld
+ and snap_node_name = '%s') snap_1
+limit 200;
+```
+
+**解读：**[本次实验环境是单机，没有复制槽数据]
+这一部分描述的是复制槽的相关信息。数据来源于：snapshot.snap_global_replication_slots表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|Slot Name| 复制槽名称|
+|Slot Type| 复制槽类型|
+|DB Name| 数据库名称|
+|Active| 是否为激活状态|
+|Xmin| 事务标识，最早的事务ID(txid)|
+|Restart Lsn| 事务槽开始复制时的LSN信息，用来判断哪些事务需要被复制|
+|Dummy Standby| 是否为假备|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+SELECT snap_slot_name as "Slot Name",
+ snap_slot_type as "Slot Type",
+ snap_database as "DB Name",
+ snap_active as "Active",
+ snap_x_min as "Xmin",
+ snap_restart_lsn as "Restart Lsn",
+ snap_dummy_standby as "Dummy Standby"
+FROM snapshot.snap_global_replication_slots
+WHERE snapshot_id = %ld
+and snap_node_name = '%s'
+limit 200;
+```
+
+**解读：**[本次实验环境是单机，没有复制槽数据]
+这一部分描述事务槽详细的状态信息，数据源于snapshot.snap_global_replication_stat表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|Thread Id| 线程ID|
+|Usesys Id| 用户OID|
+|Usename| 用户名|
+|Application Name| 应用程序名称|
+|Client Addr| 客户端地址|
+|Client Hostname| 客户端主机名|
+|Client Port| 客户端端口|
+|Backend Start| 程序启动时间|
+|State| 日志复制状态【追赶状态/一直的流状态】|
+|Sender Sent Location| 日志发送的位置|
+|Receiver Write Location| 日志接收端write的位置|
+|Receiver Flush Location| 日志接收端flush的位置|
+|Receiver Replay Location| 日志接收端replay的位置|
+|Sync Priority| 同步复制的优先级(0表示异步复制)|
+|Sync State| 同步状态【异步复制/同步复制/潜在同步复制】|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+SELECT snap_pid as "Thread Id",
+ snap_usesysid as "Usesys Id",
+ snap_usename as "Usename",
+ snap_application_name as "Application Name",
+ snap_client_addr as "Client Addr",
+ snap_client_hostname as "Client Hostname",
+ snap_client_port as "Client Port",
+ snap_backend_start as "Backend Start",
+ snap_state as "State",
+ snap_sender_sent_location as "Sender Sent Location",
+ snap_receiver_write_location as "Receiver Write Location",
+ snap_receiver_flush_location as "Receiver Flush Location",
+ snap_receiver_replay_location as "Receiver Replay Location",
+ snap_sync_priority as "Sync Priority",
+ snap_sync_state as "Sync State"
+FROM snapshot.snap_global_replication_stat
+WHERE snapshot_id = %ld
+and snap_node_name = '%s' limit 200;
+```
+
+**解读：**
+这一部分描述用户表状态的统计信息，数据源于snapshot.snap_global_stat_all_tables表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|DB Name| 数据库名称|
+|Schema| 模式名称|
+|Relname| 表名称|
+|Seq Scan| 顺序扫描的次数|
+|Seq Tup Read| 顺序扫描获取的活跃行数|
+|Index Scan| 索引扫描次数|
+|Index Tup Fetch| 索引扫描获取的活跃行数|
+|Tuple Insert| 插入的行数|
+|Tuple Update| 更新的行数|
+|Tuple Delete| 删除的行数|
+|Tuple Hot Update| HOT(Heap Only Tuple)更新行数备注：HOT更新指，如果更新后的新行和旧行位于同一个数据块内，则旧行会有一个指针指向新行，这样就不用更新索引了，通过索引访问到旧行数据，进而访问到新行数据。|
+|Live Tuple| 活跃行数(估值)|
+|Dead Tuple|死行数(估值)|
+|Last Vacuum| 最后一次手动Vacuum的时间(不包含VACUUM FULL)|
+|Last Autovacuum| 最后一次autovacuum的时间|
+|Last Analyze| 最后一次手动Analyze表的时间|
+|Last Autoanalyze| 最后一次autovacuum线程Analyze表的时间|
+|Vacuum Count| 手动vacuum的次数(不包含VACUUM FULL)|
+|Autovacuum Count| autovacuum的次数|
+|Analyze Count| 手动Analyze的次数|
+|Autoanalyze Count| autovacuum线程Analyze表的次数|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+SELECT snap_2.db_name as "DB Name",
+ snap_2.snap_schemaname as "Schema",
+ snap_2.snap_relname as "Relname",
+ (snap_2.snap_seq_scan - coalesce(snap_1.snap_seq_scan, 0)) as "Seq Scan",
+ (snap_2.snap_seq_tup_read - coalesce(snap_1.snap_seq_tup_read, 0)) as "Seq Tup Read",
+ (snap_2.snap_idx_scan - coalesce(snap_1.snap_idx_scan, 0)) as "Index Scan",
+ (snap_2.snap_idx_tup_fetch - coalesce(snap_1.snap_idx_tup_fetch, 0)) as "Index Tup Fetch",
+ (snap_2.snap_n_tup_ins - coalesce(snap_1.snap_n_tup_ins, 0)) as "Tuple Insert",
+ (snap_2.snap_n_tup_upd - coalesce(snap_1.snap_n_tup_upd, 0)) as "Tuple Update",
+ (snap_2.snap_n_tup_del - coalesce(snap_1.snap_n_tup_del, 0)) as "Tuple Delete",
+ (snap_2.snap_n_tup_hot_upd - coalesce(snap_1.snap_n_tup_hot_upd, 0)) as "Tuple Hot Update",
+ snap_2.snap_n_live_tup as "Live Tuple",
+ snap_2.snap_n_dead_tup as "Dead Tuple",
+ to_char(snap_2.snap_last_vacuum, 'YYYY-MM-DD HH24:MI:SS') as "Last Vacuum",
+ to_char(snap_2.snap_last_autovacuum, 'YYYY-MM-DD HH24:MI:SS') as "Last Autovacuum",
+ to_char(snap_2.snap_last_analyze, 'YYYY-MM-DD HH24:MI:SS') as "Last Analyze",
+ to_char(snap_2.snap_last_autoanalyze, 'YYYY-MM-DD HH24:MI:SS') as "Last Autoanalyze",
+ (snap_2.snap_vacuum_count - coalesce(snap_1.snap_vacuum_count, 0)) as "Vacuum Count",
+ (snap_2.snap_autovacuum_count - coalesce(snap_1.snap_autovacuum_count, 0)) as "Autovacuum Count",
+ (snap_2.snap_analyze_count - coalesce(snap_1.snap_analyze_count, 0)) as "Analyze Count",
+ (snap_2.snap_autoanalyze_count - coalesce(snap_1.snap_autoanalyze_count, 0)) as "Autoanalyze Count"
+FROM
+ (SELECT * FROM snapshot.snap_global_stat_all_tables
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ AND snap_schemaname !~ '^pg_toast') snap_2
+LEFT JOIN
+ (SELECT * FROM snapshot.snap_global_stat_all_tables
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ AND snap_schemaname !~ '^pg_toast') snap_1
+ON snap_2.snap_relid = snap_1.snap_relid
+AND snap_2.snap_schemaname = snap_1.snap_schemaname
+AND snap_2.snap_relname = snap_1.snap_relname
+AND snap_2.db_name = snap_1.db_name
+order by snap_2.db_name, snap_2.snap_schemaname
+limit 200;
+```
+
+**解读：**
+这一部分描述用户索引状态的统计信息，数据源于snapshot.snap_global_stat_all_indexes表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|DB Name| 数据库名称|
+|Schema| 模式名称|
+|Relname| 表名称|
+|Index Relname| 索引名称|
+|Index Scan| 索引扫描次数|
+|Index Tuple Read| 索引扫描返回的索引条目数|
+|Index Tuple Fetch| 索引扫描获取的活跃行数|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+SELECT snap_2.db_name as "DB Name",
+ snap_2.snap_schemaname as "Schema",
+ snap_2.snap_relname as "Relname",
+ snap_2.snap_indexrelname as "Index Relname",
+ (snap_2.snap_idx_scan - coalesce(snap_1.snap_idx_scan, 0)) as "Index Scan",
+ (snap_2.snap_idx_tup_read - coalesce(snap_1.snap_idx_tup_read, 0)) as "Index Tuple Read",
+ (snap_2.snap_idx_tup_fetch - coalesce(snap_1.snap_idx_tup_fetch, 0)) as "Index Tuple Fetch"
+FROM
+ (SELECT * FROM snapshot.snap_global_stat_all_indexes
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') snap_2
+LEFT JOIN
+ (SELECT * FROM snapshot.snap_global_stat_all_indexes
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s'
+ and snap_schemaname NOT IN ('pg_catalog', 'information_schema', 'snapshot')
+ and snap_schemaname !~ '^pg_toast') snap_1
+ON snap_2.snap_relid = snap_1.snap_relid
+and snap_2.snap_indexrelid = snap_1.snap_indexrelid
+and snap_2.snap_schemaname = snap_1.snap_schemaname
+and snap_2.snap_relname = snap_1.snap_relname
+and snap_2.snap_indexrelname = snap_1.snap_indexrelname
+and snap_2.db_name = snap_1.db_name
+order by snap_2.db_name, snap_2.snap_schemaname
+limit 200;
+```
+
+**解读：**
+这一部分描述坏块的统计信息，数据源于snapshot.snap_global_stat_bad_block表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|DB Id| 数据库OID|
+|Tablespace Id| 表空间OID|
+|Relfilenode| relation的filenode号|
+|Fork Number| fork编号|
+|Error Count| error数量|
+|First Time| 坏块第一次出现的时间|
+|Last Time| 坏块最近一次出现的时间|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+ SELECT snap_2.snap_databaseid AS "DB Id",
+ snap_2.snap_tablespaceid AS "Tablespace Id",
+ snap_2.snap_relfilenode AS "Relfilenode",
+ snap_2.snap_forknum AS "Fork Number",
+ (snap_2.snap_error_count - coalesce(snap_1.snap_error_count, 0)) AS "Error Count",
+ snap_2.snap_first_time AS "First Time",
+ snap_2.snap_last_time AS "Last Time"
+FROM
+ (SELECT * FROM snapshot.snap_global_stat_bad_block
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s') snap_2
+LEFT JOIN
+ (SELECT * FROM snapshot.snap_global_stat_bad_block
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s') snap_1
+ON snap_2.snap_databaseid = snap_1.snap_databaseid
+and snap_2.snap_tablespaceid = snap_1.snap_tablespaceid
+and snap_2.snap_relfilenode = snap_1.snap_relfilenode
+limit 200;
+```
+
+**解读：**
+这一部分描述的是数据库参数配置信息，数据源于snapshot.snap_global_config_settings表。
+信息内容如下所示：
+
+|列名| 描述|
+|-|-|
+|Name| 参数名称|
+|Abstract| 参数的简单描述|
+|Type| 参数类型(bool/enum/integer/real/string)|
+|Curent Value| 参数当前值|
+|Min Value| 最小参数值|
+|Max Value| 最大参数值|
+|Category| 参数逻辑组|
+|Enum Values| 参数枚举值|
+|Default Value| 启动时的默认参数值|
+|Reset Value| 重置时的默认参数值|
+**相关代码：**
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select snap_name as "Name",
+ snap_short_desc as "Abstract",
+ snap_vartype as "Type",
+ snap_setting as "Curent Value",
+ snap_min_val as "Min Value",
+ snap_max_val as "Max Value",
+ snap_category as "Category",
+ snap_enumvals as "Enum Values",
+ snap_boot_val as "Default Value",
+ snap_reset_val as "Reset Value"
+FROM
+ snapshot.snap_global_config_settings
+ WHERE snapshot_id = %ld
+ and snap_node_name = '%s';
+```
+
+**解读：**
+这一部分描述的是SQL语句的详细信息，数据来源于snapshot.snap_summary_statement表。
+**Unique SQL Id：** 即SQL的唯一识别ID
+**SQL Text：** 即SQL的具体内容。
+**相关代码：**
+
+```sql
+-- 说明：%s代表node_name，%ld代表snapshot_id
+select (t2.snap_unique_sql_id) as "Unique SQL Id",
+ (t2.snap_query) as "SQL Text"
+from
+ snapshot.snap_summary_statement t2
+ where snapshot_id = %ld
+ and snap_node_name = '%s';
+```
+### 小结：
+ 关于openGauss WDR报告的梳理和解读就到这里，这些内容对于刚刚接触openGauss的老DBA已经足够了，只要读懂WDR报告的数据计算方法和含义即意味着看懂了这份WDR报告内容，剩下的数据库优化工作完全可以参照已有的数据库优化经验操作。当然了，“小白”DBA也完全可以参照网络上大佬们分享的数据库优化案例以及类似Oracle等主流数据库的AWR报告解读，学习openGauss的WDR报告，从而执行openGauss数据库相关的优化工作。
+ **以上所有观点仅代表个人，如有不正确之处欢迎大佬们指正。**
+
+
diff --git "a/content/zh/post/jiajunfeng/openGauss\351\200\273\350\276\221\350\247\243\347\240\201.md" "b/content/zh/post/jiajunfeng/openGauss\351\200\273\350\276\221\350\247\243\347\240\201.md"
new file mode 100644
index 0000000000000000000000000000000000000000..52b0c8aaad7f896dac7a064b73b8892c427aaf53
--- /dev/null
+++ "b/content/zh/post/jiajunfeng/openGauss\351\200\273\350\276\221\350\247\243\347\240\201.md"
@@ -0,0 +1,116 @@
++++
+
+title = "openGauss逻辑解码"
+
+date = "2021-06-01"
+
+tags = ["openGauss核心技术"]
+
+archives = "2021-06"
+
+author = "贾军锋"
+
+summary = "openGauss逻辑解码"
+
+img = "/zh/post/jiajunfeng/title/img4.png"
+
+times = "12:30"
+
++++
+
+# openGauss逻辑解码
+
+逻辑复制由两部分组成：逻辑解码和数据复制。逻辑解码会输出以事务为单位组织的逻辑日志。业务或数据库中间件将会对逻辑日志进行解析并最终实现数据复制。
+
+openGauss当前只提供逻辑解码功能，因此文只对逻辑解码进行简单说明和测试。
+
+逻辑解码为逻辑复制提供事务解码的基础能力，openGauss使用SQL函数接口进行逻辑解码。此方法调用方便，不需使用工具，对接外部工具接口也比较清晰，不需要额外适配。
+
+由于逻辑日志是以事务为单位的，在事务提交后才能输出，且逻辑解码是由用户驱动的；因此为了防止事务开始时的xlog被系统回收，或所需的事务信息被VACUUM回收，openGauss新增了逻辑复制槽，用于阻塞xlog的回收。
+
+## 注意事项
+
+- 不支持DDL语句解码。
+- 不支持列存、数据页复制的解码。
+- 不支持备机与级联备机进行逻辑解码。
+- 当执行DDL语句（如alter table）后，该DDL语句前尚未解码的物理日志可能会丢失。
+- 使用逻辑解码功能时，禁止进行数据库在线扩容。
+- 使用逻辑解码功能时，禁止执行VACUUM FULL。
+- 单条元组大小不超过1GB，考虑解码结果可能大于插入数据，因此建议单条元组大小不超过500MB。
+- openGauss支持解码的数据类型为：INTEGER、BIGINT、SMALLINT、TINYINT、SERIAL、SMALLSERIAL、BIGSERIAL、FLOAT、DOUBLE PRECISION、DATE、TIME\[WITHOUT TIME ZONE\]、TIMESTAMP\[WITHOUT TIME ZONE\]、CHAR\(n\)、VARCHAR\(n\)、TEXT。
+- 目前默认不支持ssl连接，如果需要ssl连接需要设置guc参数ssl=on。
+- 如果使用JDBC创建逻辑复制槽，则逻辑复制槽名称必须小于64个字符，且只包含字母、数字或者下划线中的一种或几种。
+- 当前逻辑复制不支持MOT特性。
+- 当逻辑复制槽所在数据库被删除后，这些复制槽变为不可用状态，需要用户手动删除。
+- 仅支持utf-8字符集。
+- 对多库的解码需要分别在库内创建流复制槽并开始解码，每个库的解码都需要单独扫一遍日志。
+- 不支持强起，强起后需要重新全量导出数据。
+
+## 准备工作
+
+```
+$ gs_guc reload -N all -I all -c "ssl=on"
+$ gs_guc reload -N all -I all -c "wal_level=logical"
+$ gs_guc reload -N all -I all -c "max_replication_slots=10" ## max_replication_slots>每个节点所需的(物理流复制槽数+逻辑复制槽数)
+$ gs_om -t stop && gs_om -t start
+```
+
+Tips:
+
+- 物理流复制槽用于支撑主备HA。数据库所需要的物理流复制槽数为：备节点\(包括从备\)与主节点之间的比例\(假设数据库的高可用方案为1主3备，则所需物理流复制槽数为3\)。
+- 一个逻辑复制槽只能解码一个Database的修改，如果需要解码多个Database，则需要创建多个逻辑复制槽。
+- 如果需要多路逻辑复制同步给多个目标数据库，在源端数据库需要创建多个逻辑复制槽，每个逻辑复制槽对应一条逻辑复制链路。
+- 仅限数据库管理员和拥有REPLICATION权限的用户进行操作。
+
+## 创建逻辑复制槽
+
+```
+$ gsql -d postgres -p 26000 -r -q
+-- 创建一个名为slot1的逻辑复制槽，plugin_name当前仅支持mppdb_decoding
+postgres=# SELECT * FROM pg_create_logical_replication_slot('slot1', 'mppdb_decoding');
+ slotname | xlog_position
+----------+---------------
+ slot1 | 0/8948D100 -- 逻辑复制槽解码的起始LSN位置
+```
+
+## 创建测试数据
+
+```
+postgres=# create table logic_test(id int,date1 date);
+postgres=# insert into logic_test values(1,now());
+postgres=# select * from logic_test ;
+ id | date1
+----+---------------------
+ 1 | 2021-05-31 10:02:59
+```
+
+## 读取复制槽逻辑解码结果
+
+```
+postgres=# select * from pg_replication_slots;
+ slot_name | plugin | slot_type | datoid | database | active | xmin | catalog_xmin | restart_lsn | dummy_standby
+-----------+----------------+-----------+--------+----------+--------+------+--------------+-------------+---------------
+ slot1 | mppdb_decoding | logical | 15103 | postgres | f | | 13620 | 0/8948D080 | f
+postgres=# select * from pg_logical_slot_peek_changes('slot1',null,4096); -- (slot_name,LSN,upto_nchanges)
+ location | xid | data
+------------+-------+------------------------------------------------------------------------------------------------------------------
+ 0/8948D278 | 13620 | BEGIN 13620
+ 0/8948F088 | 13620 | COMMIT 13620 CSN 2277
+ 0/8948F1F8 | 13621 | BEGIN 13621
+ 0/8948F1F8 | 13621 | {"table_name":"public.logic_test","op_type":"INSERT","columns_name":["id","date1"],"columns_type":["integer","tim
+estamp without time zone"],"columns_val":["1","'2021-05-31 10:02:59'"],"old_keys_name":[],"old_keys_type":[],"old_keys_val":[]}
+ 0/8948F300 | 13621 | COMMIT 13621 CSN 2278
+```
+
+Tips:
+
+- slot\_name: 流复制槽名称
+- LSN: 日志的LSN，表示只解码小于等于此LSN的日志, NULL表示不对解码截止的日志位置做限制
+- upto\_nchanges: 解码条数。假设一共有3条事务，分别包含3、5、7条记录，如果upto\_nchanges为4，那么会解码出前两个事务共8条记录。
+
+## 删除逻辑复制槽slot1
+
+```
+postgres=# select * from pg_drop_replication_slot('slot1');
+```
+
diff --git "a/content/zh/post/jiajunfeng/\344\270\200\351\224\256\351\203\250\347\275\262openGauss2-0-0.md" "b/content/zh/post/jiajunfeng/\344\270\200\351\224\256\351\203\250\347\275\262openGauss2-0-0.md"
new file mode 100644
index 0000000000000000000000000000000000000000..cd0393a6ff7bf6b9bfccf744d6dfb059a96a9da9
--- /dev/null
+++ "b/content/zh/post/jiajunfeng/\344\270\200\351\224\256\351\203\250\347\275\262openGauss2-0-0.md"
@@ -0,0 +1,264 @@
++++
+
+title = "一键部署openGauss2.0.0"
+
+date = "2021-04-19"
+
+tags = ["openGauss安装部署"]
+
+archives = "2021-04"
+
+author = "贾军锋"
+
+summary = "一键部署openGauss2.0.0"
+
+img = "/zh/post/jiajunfeng/title/img33.png"
+
+times = "15:30"
+
++++
+
+# 一键部署openGauss2.0.0
+
+openGauss 从发布至今，安装部署碰到的问题比较多，也是大家学习openGauss数据库的第一道坎。
+
+为了提高大家部署openGauss数据库的效率，个人将安装步骤写入shell脚本，在openEuler操作系统可以连接外网的情况下，实现一键式配置、下载、安装，希望对大家有所帮助。
+
+```
+vi /root/auto_install.sh
+-----------------------------------------------------------------------------------------------------
+#!/bin/bash
+
+## Author： 贾军锋
+## Date： 2021-04-15
+## OS: openEuler20.03LTS [最小硬件配置：2c/4G]
+## Database：openGauss 2.0.0
+## Description：一键式实现操作系统环境配置、openGauss软件下载、openGauss软件安装等步骤，帮助大家提升安装openGauss数据库效率
+## Tips: 请确保操作系统可以连接外网
+
+## 0.关闭virbr0网卡 [本地虚拟机标准化安装openEuler系统会默认存在virbr0网卡，删除该网卡以避免干扰数据库的安装]
+## virsh net-destroy default
+## virsh net-list
+## echo "Net device virbr0 is disabled."
+
+
+## 1.定义主机信息[请根据实际情况修改]
+export MY_HOSTNAME=node1 ## 主机名
+export MY_HOSTIP=192.168.8.133 ## IP地址
+export MY_SOFTWARE_DIRECTORY=/soft/openGauss ## 软件包所在目录
+export MY_XML=/soft/openGauss/clusterconfig.xml ## 集群配置文件XML
+export openGauss_Download_url=https://opengauss.obs.cn-south-1.myhuaweicloud.com/2.0.0/x86_openEuler/openGauss-2.0.0-openEuler-64bit-all.tar.gz ## openGauss软件包下载地址
+
+## 1. 设置主机名并配置hosts文件
+hostnamectl set-hostname $MY_HOSTNAME
+sed -i '/$MY_HOSTIP/d' /etc/hosts
+echo "$MY_HOSTIP $MY_HOSTNAME #Gauss OM IP Hosts Mapping" >> /etc/hosts
+cat /etc/hosts
+echo "1.Configure /etc/hosts completed."
+echo -e "\n"
+
+## 2. 关闭防火墙
+systemctl disable firewalld.service
+systemctl stop firewalld.service
+echo "Firewalld " `systemctl status firewalld|grep Active`
+echo "2.Disable firewalld service completed."
+echo -e "\n"
+
+## 3. 关闭SELinux
+sed -i '/^SELINUX=/d' /etc/selinux/config
+echo "SELINUX=disabled" >> /etc/selinux/config
+cat /etc/selinux/config|grep "SELINUX=disabled"
+echo "3.Disable SELINUX completed."
+echo -e "\n"
+
+
+## 4. 设置操作系统字符集编码
+echo "LANG=en_US.UTF-8" >> /etc/profile
+source /etc/profile
+echo $LANG
+echo "4.Configure encoding completed."
+echo -e "\n"
+
+## 5. 设置操作系统时区
+rm -fr /etc/localtime
+ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
+date -R
+hwclock
+echo "5.Configure Timezone completed."
+echo -e "\n"
+
+## 6. 关闭SWAP分区 [对于2G内存的设备，建议待安装完毕后再打开SWAP以间接 “扩容内存容量”]
+sed -i '/swap/s/^/#/' /etc/fstab
+swapoff -a
+free -m
+echo "6.Close swap partition completed."
+echo -e "\n"
+
+
+## 7. 配置SSH服务，关闭Banner，允许root远程登录
+sed -i '/Banner/s/^/#/' /etc/ssh/sshd_config
+sed -i '/PermitRootLogin/s/^/#/' /etc/ssh/sshd_config
+echo -e "\n" >> /etc/ssh/sshd_config
+echo "Banner none " >> /etc/ssh/sshd_config
+echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
+cat /etc/ssh/sshd_config |grep -v ^#|grep -E 'PermitRoot|Banner'
+echo "7.Configure SSH Service completed."
+echo -e "\n"
+
+## 8. 配置YUM源、安装依赖包、修改默认Python3版本
+mkdir /etc/yum.repos.d/bak
+mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/
+wget -O /etc/yum.repos.d/openEulerOS.repo https://repo.huaweicloud.com/repository/conf/openeuler_x86_64.repo
+yum clean all
+yum install -y bzip2 python3
+yum install -y libaio-devel libnsl flex bison ncurses-devel glibc-devel patch readline-devel net-tools tar
+mv /usr/bin/python /usr/bin/python2_bak
+ln -s /usr/bin/python3 /usr/bin/python
+python -V
+echo "8.Configure Install Packages and change default Python version completed."
+echo -e "\n"
+
+
+## 9. 配置 sysctl.conf 和 performance.sh
+cat >> /etc/sysctl.conf << EOF
+net.ipv4.tcp_retries1 = 5
+net.ipv4.tcp_syn_retries = 5
+net.sctp.path_max_retrans = 10
+net.sctp.max_init_retransmits = 10
+EOF
+sysctl -p
+
+sed -i '/vm.min_free_kbytes/s/^/#/' /etc/profile.d/performance.sh ## Only for openEuler
+cat /etc/profile.d/performance.sh|grep vm.min_free_kbytes
+
+echo "9.Configure sysctl.conf and performance.sh completed."
+echo -e "\n"
+
+
+## 10. 配置资源限制
+echo "* soft stack 3072" >> /etc/security/limits.conf
+echo "* hard stack 3072" >> /etc/security/limits.conf
+echo "* soft nofile 1000000" >> /etc/security/limits.conf
+echo "* hard nofile 1000000" >> /etc/security/limits.conf
+echo "* soft nproc unlimited" >> /etc/security/limits.d/90-nproc.conf
+tail -n 4 /etc/security/limits.conf
+tail -n 1 /etc/security/limits.d/90-nproc.conf
+echo "10.Configure resource limits completed."
+echo -e "\n"
+
+## 11. 关闭透明大页[Only for CentOS]
+cat >>/etc/rc.d/rc.local<
| + | ++ | +
|---|---|
| + | +openGauss的配置文件，在gaussmaster线程启动时会读取该文件，获取监听地址、服务端口、内存分配、功能设置等配置信息，并且根据该文件，在openGauss启动时创建共享内存和信号量池等 + |
+
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
|---|---|
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
+
+- 打开网络
+
+ 
+
+- 设置时区
+
+ 
+
+- 安装位置和分区
+
+ 
+
+- 软件选择最小安装（也可以选带GUI安装）
+
+ 
+
+- 开始安装
+
+- 设置ROOT密码和新建用户
+
+- 安装完成后重启
+
+
+
+### 配置CentOS7.6
+
+- 简单配置
+
+ 设置字体 `setfont lat4-19`
+
+ [重新安装VMware Tools(Optional)](https://segmentfault.com/a/1190000038633985)（对于无GUI的应该没啥用，可以在本地ssh到vmware中就可以复制粘贴了）
+
+ 
+
+ 
+
+- 使用MobaXterm SSH连接
+
+- yum源更新 `yum update`
+
+- 安装Python3.6 `yum install -y python36`
+
+- 安装其他依赖`yum install -y bzip2 libaio-devel flex bison ncurses-devel glibc-devel patch`
+
+- 关闭防火墙和SeLinux，然后重启，重连ssh
+
+ 
+
+- 设置字符集参数：在/etc/profile文件中添加”export LANG=XXX”（XXX为Unicode编码）
+
+ 
+
+- 检查设置时区
+
+ 
+
+- 关闭swap交换内存（Optional） `swapoff -a`
+
+- 关闭RemovelPC，CentOS操作系统默认为关闭
+
+
+
+
+## 开始安装
+
+- 创建用户组dbgrp、用户omm，将该用户添加至root组,并修改用户omm的密码
+
+ 
+
+- 配置共享文件夹，把openGauss的安装包（2.0.1 极简版）放进去
+
+- 以root用户创建软件目录，以omm用户登录解压
+
+ 
+
+- 进入simpleInstall目录，执行安装脚本 `sh install.sh -w xxxx`
+
+ 出现如下错误：
+
+ 
+
+ 解决办法：
+
+ 在/etc/sysctl.conf中加入语句`kernel.sem = 250 32000 100 999`，然后执行`sysctl -p`
+
+ 
+
+ 
+
+- 执行完安装脚本之后：
+
+ openGauss端口号默认为5432
+
+ 默认生成名称为postgres的数据库
+
+ 数据库目录安装路径/opt/software/openGauss/data/single_node,其中/opt/software/openGauss为解压包路径，data/single_node为新创建的数据库节点目录。
+
+- 使用ps和gs_ctl查看进程是否正常（如果没有找到gs_ctl，配置环境变量即可 `export PATH=/opt/software/openGauss/bin:$PATH`，如果缺失lib则配置`LD_LIBRARY_PATH`）
+
+ 
+
+ 如果ps里没有的话可以先重启一下：
+
+ `gs_ctl restart -D /opt/software/openGauss/data/single_node -Z single_node`
+
+
+
+## 连接与使用
+
+### Gsql方式
+
+数据库安装完成后，默认生成名称为postgres的数据库，默认端口是5432。
+
+因为omm用户是管理员用户，因此系统显示“DBNAME=#”。若使用普通用户身份登录和连接数据库，系统显示“DBNAME=>”。
+
+“Non-SSL connection”表示未使用SSL方式连接数据库。如果需要高安全性时，请使用SSL连接。
+
+
+
+查看对象操作：
+
+- 查看帮助信息：\\?
+- 列举数据库：\\l
+- 列举表：\\dt
+- 查看表结构：\\d tablename
+- 切换数据库：\\c dbname
+- 列举schema：\\dn
+- 查看索引：\\di
+
+
+
+
+
+### 远程连接前的准备
+
+- 配置数据库用户和权限（omm不能用于远程连接）：
+
+ 
+
+- 修改数据库的pg_hba.conf文件，**给要远程连接的主机/用户放行**（这里好像不能用gs_auc命令完成，直接编辑文件即可）：
+
+ 
+
+- 使用gs_ctl将策略生效：`gs_ctl reload -D ./data/single_node`
+
+- **修改postgresql.conf中的监听地址**：`listen_addresses = '*'`，默认只监听local，改后包括了要进行远程连接的ip地址就行
+
+- 重启数据库生效：`gs_ctl restart -D ./data/single_node`
+
+如果之后进行JDBC连接的时候出现如下图中的目标地址拒绝连接的异常，可能就是这一步出问题了
+
+
+
+
+
+### ODBC/JDBC
+
+根据文档JDBC应该是都支持，ODBC支持受限
+
+
+
+因为是在CentOS 7.6上装的openGauss，所以选择JDBC。
+
+JDBC Connectors可以不用从源码构建，直接从官网下载页下载即可。
+
+在Win上VSCode中配置好JAVA环境，需要Java11和Java8，配置该项目的JDK Runtime和Referenced Libraries（把下载解压得到的postgresql.jar加进去）
+
+代码：
+
+```java
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+import java.sql.Statement;
+import java.sql.Timestamp;
+import java.util.Properties;
+
+class openGaussTest {
+ public static void main(String[] args) {
+ System.out.println("=====START TEST=====");
+
+ Connection conn = getConnect("luooofan", "Luooofan1");
+
+ Statement stmt = null;
+ try {
+ stmt = conn.createStatement();
+ ResultSet rs = null;
+ try {
+ rs = stmt.executeQuery(
+ "select pro_c_id, pro_id, pro_status, pro_quantity, pro_income, pro_purchase_time from property;");
+ while (rs.next()) {
+ int pro_c_id = rs.getInt(1);
+ int pro_id = rs.getInt(2);
+ String pro_status = rs.getString(3);
+ int pro_quantity = rs.getInt(4);
+ int pro_income = rs.getInt(5);
+ Timestamp pro_pruchase_time = rs.getTimestamp("pro_purchase_time");
+ System.out.printf("%4d %4d %4s %4d %4d ", pro_c_id, pro_id, pro_status, pro_quantity, pro_income);
+ System.out.println(pro_pruchase_time);
+ }
+ } catch (SQLException e) {
+ if (rs != null) {
+ try {
+ rs.close();
+ } catch (SQLException e1) {
+ e1.printStackTrace();
+ }
+ }
+ e.printStackTrace();
+ }
+
+ stmt.close();
+ } catch (SQLException e) {
+ if (stmt != null) {
+ try {
+ stmt.close();
+ } catch (SQLException e1) {
+ e1.printStackTrace();
+ }
+ }
+ e.printStackTrace();
+ }
+
+ try {
+ conn.close();
+ } catch (SQLException e) {
+ e.printStackTrace();
+ }
+ }
+
+ public static Connection getConnect(String username, String passwd) {
+ // 驱动类
+ String driver = "org.postgresql.Driver";
+ // 数据库连接描述符
+ String sourceURL = "jdbc:postgresql://192.168.193.129:5432/finance";
+ Connection conn = null;
+
+ try {
+ // 加载驱动
+ Class.forName(driver);
+ } catch (Exception e) {
+ e.printStackTrace();
+ return null;
+ }
+
+ try {
+ // 创建连接
+ conn = DriverManager.getConnection(sourceURL, username, passwd);
+ System.out.println("Connection succeed!");
+ } catch (Exception e) {
+ e.printStackTrace();
+ return null;
+ }
+
+ return conn;
+ }
+}
+```
+
+NOTE：
+
+- 要执行什么操作就要赋予用户什么权限，代码中要对property表查询，故：`grant select on table property to luooofan;`
+
+- 因为CentOS没配置中文编码，所以直接在CentOS上查找的话应该无法显示中文，不过这并不影响在win 上远程连接然后查询并显示
+
+ 
+
+
+
+
+
+## References
+
+[openGauss Server&Connectors Official Download](https://opengauss.org/zh/download.html)
+
+[官方文档-快速入门](https://opengauss.org/zh/docs/2.0.1/docs/Quickstart/Quickstart.html)
+
+[官方文档-开发者指南](https://opengauss.org/zh/docs/2.0.1/docs/Developerguide/Developerguide.html)
+
+[openGauss数据库部署Linux遇到的问题](https://blog.csdn.net/RANGO_CSDN/article/details/118761322)
+
+[【数据库原理实验(openGauss)】 使用JDBC连接数据库](https://blog.csdn.net/BlacKingZ/article/details/117915010)
+
diff --git "a/content/zh/post/luooofan/openGauss\344\272\213\345\212\241\346\234\272\345\210\266-MVCC\346\212\200\346\234\257\347\232\204\345\256\236\347\216\260.md" "b/content/zh/post/luooofan/openGauss\344\272\213\345\212\241\346\234\272\345\210\266-MVCC\346\212\200\346\234\257\347\232\204\345\256\236\347\216\260.md"
new file mode 100644
index 0000000000000000000000000000000000000000..4ae8ddce50b0761fa50943aa845ea4e7329e7fcc
--- /dev/null
+++ "b/content/zh/post/luooofan/openGauss\344\272\213\345\212\241\346\234\272\345\210\266-MVCC\346\212\200\346\234\257\347\232\204\345\256\236\347\216\260.md"
@@ -0,0 +1,519 @@
++++
+title = "openGauss事务机制中MVCC技术的实现分析"
+date = "2021-11-27"
+tags = ["openGauss事务机制", "openGaussMVCC技术", "openGauss源码解析"]
+archives = "2021-11"
+author = "luooofan"
+summary = "分析openGauss2.0.1中MVCC技术的实现部分"
+img = "/zh/post/luooofan/title/openGauss.png"
++++
+
+# openGauss事务机制中MVCC技术的实现分析
+
+## 概述
+
+### 事务
+
+**事务**是为用户提供的最核心、最具吸引力的数据库功能之一。简单地说,事务是用户定义的一系列**数据库操作**(如查询、插入、修改或删除等)的**集合**，从数据库内部保证了该操作集合作为一个整体的原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)，这些特性统称事务的**ACID特性**。
+
+
+
+### DBMS中的并发控制
+
+并发控制旨在针对数据库中对**事务并行**的场景，保证 ACID 中的**一致性**（Consistency）与**隔离性**（Isolation）。数据库技术中主流的三种并发控制技术分别是： Multi-version Concurrency Control (MVCC), Strict Two-Phase Locking (S2PL), 以及 Optimistic Concurrency Control (OCC)，每种技术也都有很多的变种。
+
+
+
+### MVCC
+
+MVCC的基本机制是：写事务不会原地修改元组内容，每次写操作都会在旧的版本之上创建新的版本，并且会保留旧的版本。当某个事务需要读取数据时，数据库系统会从所有的版本中选取出符合该事务隔离级别要求的版本。
+
+MVCC 的主要优点是读数据的锁请求与写数据的锁请求不冲突，以此来实现**读不阻塞写，写也不阻塞读**。
+
+
+
+### openGauss事务整体架构
+
+
+
+
+
+在openGauss中，事务的实现与存储引擎的实现有很强关联，代码主要集中在src/gausskernel/storage/access/transam及src/gausskernel/storage/lmgr下，关键文件如图所示。
+
+（1） 事务管理器：事务系统的中枢，它的实现是一个有限循环状态机，通过接受外部系统的命令并根据当前事务所处的状态决定事务的下一步执行过程。
+
+（2） 日志管理器：用来记录事务执行的状态以及数据变化的过程，包括事务提交日志(CLOG)、事务提交序列日志（CSNLOG）以及事务日志（XLOG）。其中CLOG日志只用来记录事务执行的结果状态，CSNLOG记录日志提交的顺序，用于可见性判断；XLOG是数据的redo日志，用于恢复及持久化。
+
+（3） 线程管理机制：通过一片内存区域记录所有线程的事务信息，任何一个线程可以通过访问该区域获取其他事务的状态信息。
+
+（4） MVCC机制：openGauss系统中，事务执行读流程结合各事务提交的CSN序列号，采用了多版本并发控制机制，实现了元组的读和写互不阻塞。
+
+（5） 锁管理器：实现系统的写并发控制，通过锁机制来保证事务写流程的隔离性。
+
+
+
+
+
+## MVCC的实现
+
+我们需要关注：
+
+- 元组版本号的实现
+- 快照的实现
+- 判断数据有效性、可见性、可更新性的算法的实现
+- 不同的隔离级别的实现
+
+### 多版本元组存储结构
+
+*src/include/access/htup.h*
+
+为了定义MVCC 中不同版本的数据，Opengauss在每个元组的头部信息HeapTupleHeaderData中引入了一些字段如下：
+
+```c++
+typedef struct HeapTupleHeaderData {
+ union {
+ HeapTupleFields t_heap; /* 存储该元组的一些描述信息 */
+ DatumTupleFields t_datum;
+ } t_choice;
+
+ ItemPointerData t_ctid; /* (块号，块内偏移) 存储用来记录当前元组或新元组的物理位置 */
+
+ /* Fields below here must match MinimalTupleData! */
+
+ uint16 t_infomask2;
+
+ uint16 t_infomask; /* various flag bits, see below */
+
+ uint8 t_hoff;
+
+ /* ^ - 23 bytes - ^ */
+
+ bits8 t_bits[FLEXIBLE_ARRAY_MEMBER];
+
+ /* MORE DATA FOLLOWS AT END OF STRUCT */
+} HeapTupleHeaderData;
+typedef HeapTupleHeaderData* HeapTupleHeader
+```
+
+HeapTupleFields
+
+```c++
+typedef struct HeapTupleFields {
+ ShortTransactionId t_xmin; /* 存放插入该 Tuple 时的 txid */
+ ShortTransactionId t_xmax; /* 存放删除或者更新该 Tuple 时的 txid，如果还没更新或者删除，那么置 0，表示无效 */
+
+ union {
+ CommandId t_cid; /* 创建或更新/删除该 Tuple 的命令在该事务内执行的所有 SQL 命令中的编号 */
+ ShortTransactionId t_xvac; /* old-style VACUUM FULL xact ID */
+ } t_field3;
+} HeapTupleFields;
+```
+
+t_infomask
+
+```c++
+#define HEAP_HASNULL 0x0001 /* has null attribute(s) */
+#define HEAP_HASVARWIDTH 0x0002 /* has variable-width attribute(s) */
+#define HEAP_HASEXTERNAL 0x0004 /* has external stored attribute(s) */
+#define HEAP_HASOID 0x0008 /* has an object-id field */
+#define HEAP_COMPRESSED 0x0010 /* has compressed data */
+#define HEAP_COMBOCID 0x0020 /* t_cid is a combo cid */
+#define HEAP_XMAX_EXCL_LOCK 0x0040 /* xmax is exclusive locker */
+#define HEAP_XMAX_SHARED_LOCK 0x0080 /* xmax is shared locker */
+/* if either LOCK bit is set, xmax hasn't deleted the tuple, only locked it */
+#define HEAP_IS_LOCKED (HEAP_XMAX_EXCL_LOCK | HEAP_XMAX_SHARED_LOCK)
+#define HEAP_XMIN_COMMITTED 0x0100 /* t_xmin committed */
+#define HEAP_XMIN_INVALID 0x0200 /* t_xmin invalid/aborted */
+#define HEAP_XMIN_FROZEN (HEAP_XMIN_INVALID | HEAP_XMIN_COMMITTED)
+#define HEAP_XMAX_COMMITTED 0x0400 /* t_xmax committed */
+#define HEAP_XMAX_INVALID 0x0800 /* t_xmax invalid/aborted */
+...
+```
+
+
+
+### 插入、删除、更新元组
+
+#### 元组在页中是如何存放的
+
+
+
+
+
+#### 插入
+
+假设一个txid为99的事务插入一个元组
+
+
+
+#### 删除
+
+假设一个txid为111的事务删除一个元组
+
+
+
+#### 更新
+
+假设99号事务插入的元组被100号事务更新了两次
+
+
+
+openGauss通过HeapTupleHeaderData 的几个特殊的字段，给元组设置了不同的版本号，元组的每次更新操作都会产生一条新版本的元组，版本之间从旧到新形成了一条版本链（旧的ctid指向新的元组）。
+
+
+
+### 事务快照的实现
+
+为了实现元组对事务的可见性判断，openGauss引入了事务快照SnapshotData
+
+在openGauss中，有两种方式来实现快照。
+
+#### （1）活跃事务数组方法
+
+在数据库进程中，维护一个**全局的数组**，其中的成员为**正在执行的事务信息**，包括事务的事务号，该数组即活跃事务数组。
+
+在每个事务开始的时候，复制一份该数组内容。
+
+当事务执行过程中扫描到某个元组时，需要通过判断元组xmin和xmax这两个事务对于查询事务的可见性，来决定该元组是否对查询事务可见。
+
+
+
+
+
+
+
+#### （2）时间戳方法
+
+
+
+在openGauss内部，使用一个全局自增的长整数作为逻辑的时间戳，模拟数据库内部的时序，该逻辑时间戳被称为提交顺序号（Commit Sequence Number，简称CSN）。
+
+每当一个事务提交的时候，在CSN日志中会记录该事务号 XID对应的逻辑时间戳 CSN 值。
+
+
+
+```c++
+#define COMMITSEQNO_INPROGRESS UINT64CONST(0x0) // 表示该事务还未提交或回滚
+#define COMMITSEQNO_ABORTED UINT64CONST(0x1) // 表示该事务已经回滚
+#define COMMITSEQNO_FROZEN UINT64CONST(0x2) // 表示该事务已提交，且对任何快照可见
+#define COMMITSEQNO_FIRST_NORMAL UINT64CONST(0x3) // 事务正常的CSN号起始值
+#define COMMITSEQNO_COMMIT_INPROGRESS (UINT64CONST(1) << 62) // 事务正在提交中
+```
+
+
+
+#### 事务快照数据结构SnapshotData
+
+*src/include/utils/snapshot.h*
+
+获取快照时会记录当前活跃的最小的xid，记为snapshot.xmin。当前最新提交的“事务id(latestCompleteXid) + 1”，记为snapshot.xmax。当前最新提交的“CSN号 + 1”(NextCommitSeqNo)，记为snapshot.csn。
+
+```c++
+typedef struct SnapshotData {
+ SnapshotSatisfiesFunc satisfies; /* 判断可见性的函数；通常使用MVCC，即HeapTupleSatisfiesMVCC */
+ TransactionId xmin; /*当前活跃事务最小值，小于该值的事务说明已结束 */
+ TransactionId xmax; /*最新提交事务id（latestCompeleteXid）+1，大于等于改值说明事务还未开始，该事务id不可见 */
+ TransactionId* xip; /*记录当前活跃事务链表，在CSN版本中该值无用 */
+ TransactionId* subxip; /* 记录缓存子事务活跃链表，在CSN版本中该值无用 */
+ uint32 xcnt; /* 记录活跃事务的个数（xip中元组数）在CSN版本中该值无用 */
+ ...
+
+ CommitSeqNo snapshotcsn; /* 快照的CSN号，一般为最新提交事务的CSN号+1(NextCommitSeqNo)，CSN号严格小于该值的事务可见。 */
+ ...
+
+ CommandId curcid; /*事务块中的命令序列号，即同一事务中，前面插入的数据，后面可见。 */
+ uint32 active_count; /* ActiveSnapshot stack的refcount */
+ uint32 regd_count; /* RegisteredSnapshotList 的refcount*/
+ void* user_data; /* 本地多版本快照使用，标记该快照还有线程使用，不能直接释放 */
+ SnapshotType snapshot_type; /* openGauss单机无用 */
+} SnapshotData;
+```
+
+satisfies是openGauss提供的对于事务可见性判断的统一操作接口。
+
+*src/gausskernel/storage/access/heap/heapam_visibility.c*
+
+- HeapTupleSatisfiesMVCC：判断元组对某一快照版本是否有效
+- HeapTupleSatisfiesUpdate：判断元组是否可更新
+- HeapTupleSatisfiesDirty：判断当前元组是否已脏
+- HeapTupleSatisfiesSelf：判断tuple对自身信息是否有效
+- HeapTupleSatisfiesToast：用于TOAST表（参考[文档](httpss://www.postgresql.org/docs/10/static/storage-toast.html)）的判断
+- HeapTupleSatisfiesVacuum：用在VACUUM，判断某个元组是否对任何正在运行的事务可见，如果是，则该元组不能被VACUUM删除
+- HeapTupleSatisfiesAny：所有元组都可见
+- HeapTupleSatisfiesHistoricMVCC：用于CATALOG 表
+- ……
+
+
+
+#### MVCC可见性判断机制
+
+| 状态 | xmax对于查询可见 | xmax对于查询不可见 |
+| :----------------: | :--------------------------: | :--------------------------: |
+| xmin对于查询可见 | 记录不可见（先插入，后删除） | 记录可见（先插入，未删除） |
+| xmin对于查询不可见 | 不可能发生 | 记录不可见（未插入，未删除） |
+
+##### XidVisibleInSnapshot
+
+*src/gausskernel/storage/access/heap/heapam_visibility.c*
+
+```c++
+bool XidVisibleInSnapshot(TransactionId xid, Snapshot snapshot, TransactionIdStatus* hintstatus, Buffer buffer, bool* sync)
+{
+ bool looped = false;
+ *hintstatus = XID_INPROGRESS;
+ if (GTM_MODE && TransactionIdFollowsOrEquals(xid, snapshot->xmax)) {
+ return false;
+ }
+loop:
+ csn = TransactionIdGetCommitSeqNo(xid, false, true, false);
+ if (COMMITSEQNO_IS_COMMITTED(csn)) {
+ *hintstatus = XID_COMMITTED;
+ if (csn < snapshot->snapshotcsn)
+ return true;
+ else
+ return false;
+ } else if (COMMITSEQNO_IS_COMMITTING(csn)) {
+ ...
+ } else {
+ if (csn == COMMITSEQNO_ABORTED)
+ *hintstatus = XID_ABORTED;
+ return false;
+ }
+}
+```
+
+如果xid事务正在执行：
+
+```c++
+if (looped) {
+ ereport(DEBUG1, (errmsg("transaction id %lu's csn %ld is changed to ABORT after lockwait.", xid, csn)));
+ RecheckXidFinish(xid, csn);
+ CSNLogSetCommitSeqNo(xid, 0, NULL, COMMITSEQNO_ABORTED);
+ SetLatestFetchState(xid, COMMITSEQNO_ABORTED);
+ *hintstatus = XID_ABORTED;
+ return false;
+} else {
+ if (!COMMITSEQNO_IS_SUBTRANS(csn)) {
+ ...
+ CommitSeqNo latestCSN = GET_COMMITSEQNO(csn);
+ if (latestCSN >= snapshot->snapshotcsn) {
+ ...
+ return false;
+ }
+ } else {
+ parentXid = (TransactionId)GET_PARENTXID(csn);
+ }
+ ...
+ if (TransactionIdIsValid(parentXid))
+ SyncWaitXidEnd(parentXid, buffer);
+ else
+ SyncWaitXidEnd(xid, buffer);
+ looped = true;
+ parentXid = InvalidTransactionId;
+ goto loop;
+}
+```
+
+##### HeapTupleSatisfiesMVCC
+
+
+```c++
+static bool HeapTupleSatisfiesMVCC(HeapTuple htup, Snapshot snapshot, Buffer buffer)
+{
+ // 取元组头
+ HeapTupleHeader tuple = htup->t_data;
+ ...
+ // 根据hint bit，若xmin没有被标记为已提交：可能被标记为回滚，或者还未标记
+ if (!HeapTupleHeaderXminCommitted(tuple)) {
+ // 如果xmin已经被标记为invalid，说明插入该元组的事务已经回滚，直接返回不可见
+ if (HeapTupleHeaderXminInvalid(tuple))
+ return false;
+ // xmin还未标记，并且xmin为当前事务，说明是在同一个事务内的插入命令和扫描命令，则需要去判断CID
+ // 同一个事务内，后面的查询可以查到当前事务之前命令插入的并且未删除的结果
+ if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmin(page, tuple))) {
+ if ((tuple->t_infomask & HEAP_COMBOCID) && CheckStreamCombocid(tuple, snapshot->curcid, page))
+ return true; /* delete after stream producer thread scan started */
+
+ // 当前扫描命令之后的某条命令才插入
+ if (HeapTupleHeaderGetCmin(tuple, page) >= snapshot->curcid)
+ return false; /* inserted after scan started */
+ // 到这里说明当前扫描命令之前已经插入
+ // 根据hint bit，xmax被标记为invalid
+ if (tuple->t_infomask & HEAP_XMAX_INVALID)
+ return true;
+
+ ...
+
+ // 当前扫描命令之后的某条命令删除了该元组
+ if (HeapTupleHeaderGetCmax(tuple, page) >= snapshot->curcid)
+ return true; /* deleted after scan started */
+ else
+ return false; /* deleted before scan started */
+ }
+ // xmin还没打标记，并且不是当前事务
+ else {
+ // 通过csnlog判断事务是否可见，并且返回该事务的最终提交状态
+ visible = XidVisibleInSnapshot(HeapTupleHeaderGetXmin(page, tuple), snapshot, &hintstatus, buffer, NULL);
+ // 如果该事务提交，则打上提交的hint bit用于加速判断
+ if (hintstatus == XID_COMMITTED)
+ SetHintBits(tuple, buffer, HEAP_XMIN_COMMITTED, HeapTupleHeaderGetXmin(page, tuple));
+ // 如果事务回滚，则打上回滚标记
+ if (hintstatus == XID_ABORTED) {
+ ...
+ SetHintBits(tuple, buffer, HEAP_XMIN_INVALID, InvalidTransactionId);
+ }
+ // 如果xmin不可见，则该元组不可见
+ if (!visible) {
+ ...
+ return false;
+ }
+ }
+ }
+ // 根据hint bit，若xmin已经被标记为已提交，则通过函数接口CommittedXidVisibleInSnapshot判断是否对本次快照可见
+ else {
+ /* xmin is committed, but maybe not according to our snapshot */
+ if (!HeapTupleHeaderXminFrozen(tuple) &&
+ !CommittedXidVisibleInSnapshot(HeapTupleHeaderGetXmin(page, tuple), snapshot, buffer)) {
+ if (...) {
+ return false; /* treat as still in progress */
+ }
+ }
+ }
+ // 到此为止认为xmin visible，继续判断xmax的可见性
+
+recheck_xmax:
+ // 根据hint bit，xmax已经被标记为invalid，即已经回滚
+ if (tuple->t_infomask & HEAP_XMAX_INVALID) /* xid invalid or aborted */
+ return true;
+
+ ... // 还有一些其他状态判断
+
+ // 根据hint bit，xmax没有被标记为commited
+ if (!(tuple->t_infomask & HEAP_XMAX_COMMITTED)) {
+ bool sync = false;
+ TransactionId xmax = HeapTupleHeaderGetXmax(page, tuple);
+
+ // 如果xmax为当前事务
+ if (TransactionIdIsCurrentTransactionId(HeapTupleHeaderGetXmax(page, tuple))) {
+ // 如果删除该元组的命令后发生于快照扫描时刻
+ if (HeapTupleHeaderGetCmax(tuple, page) >= snapshot->curcid)
+ return true; /* deleted after scan started */
+ else
+ return false; /* deleted before scan started */
+ }
+
+ visible = XidVisibleInSnapshot(HeapTupleHeaderGetXmax(page, tuple), snapshot, &hintstatus, buffer, &sync);
+ /*
+ * If sync wait, xmax may be modified by others. So we need to check xmax again after acquiring the page lock.
+ */
+ if (sync && (xmax != HeapTupleHeaderGetXmax(page, tuple))) {
+ goto recheck_xmax;
+ }
+ // 根据hintstatus在元组头部打标记 hint bit
+ if (hintstatus == XID_COMMITTED) {
+ SetHintBits(tuple, buffer, HEAP_XMAX_COMMITTED, HeapTupleHeaderGetXmax(page, tuple));
+ }
+ if (hintstatus == XID_ABORTED) {
+ ...
+ SetHintBits(tuple, buffer, HEAP_XMAX_INVALID, InvalidTransactionId);
+ }
+ if (!visible) {
+ if (...) {
+ if (sync && (xmax != HeapTupleHeaderGetXmax(page, tuple))) {
+ goto recheck_xmax;
+ }
+ return true; /* treat as still in progress */
+ }
+ }
+ }
+ // 根据hint bit，xmax被标记为commited
+ else {
+ /* xmax is committed, but maybe not according to our snapshot */
+ if (!CommittedXidVisibleInSnapshot(HeapTupleHeaderGetXmax(page, tuple), snapshot, buffer)) {
+ if (...) {
+ return true; /* treat as still in progress */
+ }
+ }
+ }
+ return false;
+}
+```
+
+
+
+
+
+
+
+### 隔离级别的实现
+
+| 隔离级别 | P0：脏写 | P1：脏读 | P4:更新丢失 | P2：不可重复读 | P3:幻读 | A5A:读偏斜 | A5B:写偏斜 |
+| ------------ | -------- | -------- | ----------- | -------------- | ------- | ---------- | ---------- |
+| 读未提交 | 不可能 | 可能 | 可能 | 可能 | 可能 | 可能 | 可能 |
+| 读已提交 | 不可能 | 不可能 | 可能 | 可能 | 可能 | 可能 | 可能 |
+| 可重复读 | 不可能 | 不可能 | 不可能 | 不可能 | 可能 | 不可能 | 不可能 |
+| 快照一致性读 | 不可能 | 不可能 | 不可能 | 不可能 | 偶尔 | 不可能 | 可能 |
+| 可串行化 | 不可能 | 不可能 | 不可能 | 不可能 | 不可能 | 不可能 | 不可能 |
+
+（1）**脏写（dirty write）**：两个事务分别写入，两个事务分别提交或回滚，则事务的结果无法确定，即一个事务可以回滚另一个事务的提交。
+
+（2）**脏读（dirty read）**：一个事务可以读取另一个事务未提交的修改数据。
+
+（3）**不可重复读（fuzzy read）**：一个事务重复读取前面读取过的数据，数据的结果被另外的事务修改。
+
+（4）**幻读（phantom）**：一个事务重复执行范围查询，返回一组符合条件的数据，每次查询的结果集因为其他事务的修改发生改变(条数)。
+
+（5）**更新丢失(lost update)**：一个事务在读取元组并更新该元组的过程中，有另一个事务修改了该元组的值，导致最终这次修改丢失。
+
+（6）**读偏斜(read skew)**：假设数据x，y有隐式的约束x+y=100；事务一读取x=50；事务二写x=25并更新y=75保证约束成立，事务二提交，事务一再读取y=75，导致事务一中读取x+y=125，不满足约束。
+
+（7）**写偏斜(write skew)**：假设数据x，y有隐式的约束x+y<=100；事务一读取x=50，并写入y=50；事务二读取y=30并写入x=70，并提交；事务一再提交；最终导致x=70，y=50不满足x+y<=100的约束。
+
+
+
+隔离级别越高，在一个事务执行过程中，它能“感知”到的并发事务的影响越小。在最高的可串行化隔离级别下，任意一个事务的执行，均“感知”不到有任何其他并发事务执行的影响，并且所有事务执行的效果就和一个个顺序执行的效果完全相同。
+
+在openGauss中，隔离级别的实现基于MVCC和快照机制，因此这种隔离方式被称为快照隔离(`Snapshot Isolation`，SI)。目前，openGauss支持读已提交和可重复读这两种隔离级别。两者实现上的差别在于在一个事务中获取快照的次数。(在实现上可重复读隔离级别无幻读问题，有A5B写偏斜问题)
+
+
+如果采用读已提交的隔离级别，那么在一个事务块中每条语句的执行开始阶段，都会去获取一次最新的快照，从而可以看到那些在本事务块开始以后、在前面语句执行过程中提交的并发事务的效果。
+
+如果采用可重复读的隔离级别，那么在一个事务块中，只会在第一条语句的执行开始阶段，获取一次快照，后面执行的所有语句都会采用这个快照，整个事务块中的所有语句均不会看到该快照之后提交的并发事务的效果。
+
+
+
+
+
+
+
+## 总结
+- **元组版本号的实现**：使用元组头部信息的字段来标示元组的版本号
+- **快照的实现**：活跃事务数组方法和时间戳方法
+- **判断数据有效性、可见性、可更新性的算法的实现**： `XidVisibleInSnapshot`和`HeapTupleSatisfiesMVCC`
+- **不同隔离级别的实现**：在一个事务中获取快照的次数
+
+
+
+## 参考资料
+
+[知乎：openGauss数据库源码解析系列文章](https://www.zhihu.com/column/c_1358363246349635584)
+
+[CSDN：openGauss事务机制](https://blog.csdn.net/GaussDB/article/details/116058155)
+
+[The Internals of PostgreSQL](https://www.interdb.jp/pg/pgsql05.html)
+
+[PgSQL · 特性分析 · MVCC机制浅析](http://mysql.taobao.org/monthly/2017/10/01)
+
+[PosrgreSQL 学习计划——Vacuum 清理机制](https://blog.yasking.org/a/postgresql-vacuum.html)
+
+[PostgreSql pageinspect 更深的理解PG](https://www.modb.pro/db/24577)
+
+[openGauss的MVCC以及vacuum机制源码解析—CSN LOG](https://blog.opengauss.org/zh/post/minshengyunwei/opengauss%E7%9A%84mvcc%E4%BB%A5%E5%8F%8Avacuum%E6%9C%BA%E5%88%B6%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90csn-log/)
+
+[浅谈数据库并发控制 - 锁和 MVCC](https://draveness.me/database-concurrency-control/)
+
+[PostgreSQL MVCC可见性判断](https://cloud.tencent.com/developer/article/1598195)
+
+
+
+
diff --git a/content/zh/post/luooofan/title/openGauss.png b/content/zh/post/luooofan/title/openGauss.png
new file mode 100644
index 0000000000000000000000000000000000000000..86a420b92fb8289658d807d49f137b6d13862f6d
Binary files /dev/null and b/content/zh/post/luooofan/title/openGauss.png differ
diff --git a/content/zh/post/luooofan/title/title1.png b/content/zh/post/luooofan/title/title1.png
new file mode 100644
index 0000000000000000000000000000000000000000..830c8bc490a1b830e759df1f04b453909a097406
Binary files /dev/null and b/content/zh/post/luooofan/title/title1.png differ
diff --git "a/content/zh/post/luoyuchen/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md" "b/content/zh/post/luoyuchen/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md"
new file mode 100644
index 0000000000000000000000000000000000000000..6d3397d9c001bfe0427f35d6dd84d63e78b1b14c
--- /dev/null
+++ "b/content/zh/post/luoyuchen/OpenGauss\346\225\260\346\215\256\345\272\223\345\256\211\350\243\205\344\270\216\344\275\277\347\224\250.md"
@@ -0,0 +1,224 @@
++++
+
+title = "OpenGauss数据库安装与使用"
+
+date = "2021-11-27"
+
+tags = ["OpenGauss数据库安装与使用"]
+
+archives = "2021-11"
+
+author = "罗宇辰"
+
+summary = "OpenGauss数据库安装与使用"
+
+img = "/zh/post/luoyuchen/title/1.png"
+
+times = "13:50"
+
++++
+
+# OpenGauss数据库安装与使用报告
+
+### 1.获取openGauss安装包
+
+在 https://opengauss.org/zh/download.html 官网上下载安装包
+
+
+
+这里我安装的是极简版。
+
+
+
+### 2.CentOS设置
+
+####1）CentOS版本
+CentOS7
+
+
+####2）centos网络连接设置
+>cd /etc/sysconfig/network-scripts #进入网络配置文件目录
+ls #找到目录下第一个文件
+vi 文件名 #用vi修改配置
+
+
+最后一行改为yes。
+>service network restart #重启网卡，使配置生效
+
+####3）yum安装图形化界面（非必须）
+>yum groupinstall -y "GNOME Desktop"
+
+安装完重启。在命令行界面输入
+>startx
+
+进入图形化界面。
+
+
+####4）配置yum源
+
+####5）yum安装依赖的软件包
+以下环境配置均参考 https://zhuanlan.zhihu.com/p/402928515
+>yum install libaio-devel flex bison ncurses-devel glibc-devel patch redhat-lsb-core readline-devel -y
+
+####6）关闭防火墙
+
+>systemctl status firewalld
+systemctl disable firewalld.service
+systemctl stop firewalld.service
+
+
+####7）关闭SELinux
+
+>sed -i '/SELINUX=/d' /etc/selinux/config
+echo "SELINUX=disabled" >> /etc/selinux/config
+cat /etc/selinux/config|grep -v ^#|grep -v '^$'
+
+
+
+####8）设置时区
+
+>rm -fr /etc/localtime
+ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
+ll /etc/localtime
+
+
+
+####9）关闭swap
+修改分区表文件，删除SWAP挂载信息
+>cp /etc/fstab /etc/fstab.bak
+sed -i '/swap/s/^/#/' /etc/fstab
+cat /etc/fstab|grep -v ^#|grep -v '^$'
+
+关闭swap
+>swapoff -a
+
+####10）创建dbgrp的组，创建新用户omm并授权
+
+>groupadd -g 1001 dbgrp
+useradd -u 2001 -g dbgrp omm
+chown -R omm:dbgrp /opt
+
+####11)配置操作系统内核参数
+
+>cat >> /etc/sysctl.conf << EOF
+net.ipv4.tcp_max_tw_buckets = 10000
+net.ipv4.tcp_tw_reuse = 1
+net.ipv4.tcp_tw_recycle = 1
+net.ipv4.tcp_keepalive_time = 30
+net.ipv4.tcp_keepalive_probes = 9
+net.ipv4.tcp_keepalive_intvl = 30
+net.ipv4.tcp_retries1 = 5
+net.ipv4.tcp_syn_retries = 5
+net.ipv4.tcp_synack_retries = 5
+net.ipv4.tcp_retries2 = 12
+vm.overcommit_memory = 0
+net.ipv4.tcp_rmem = 8192 250000 16777216
+net.ipv4.tcp_wmem = 8192 250000 16777216
+net.core.wmem_max = 21299200
+net.core.rmem_max = 21299200
+net.core.wmem_default = 21299200
+net.core.rmem_default = 21299200
+net.ipv4.ip_local_port_range = 26000 65535
+kernel.sem = 250 6400000 1000 25600
+vm.min_free_kbytes = 102400 ##suggest to set as physical memory * 5%
+net.core.somaxconn = 65535
+net.ipv4.tcp_syncookies = 1
+net.core.netdev_max_backlog = 65535
+net.ipv4.tcp_max_syn_backlog = 65535
+net.ipv4.tcp_fin_timeout = 60
+kernel.shmall = 1152921504606846720
+kernel.shmmax = 18446744073709551615
+net.ipv4.tcp_sack = 1
+net.ipv4.tcp_timestamps = 1
+vm.extfrag_threshold = 500
+vm.overcommit_ratio = 90
+EOF
+sysctl -p
+
+###3.安装OpenGauss
+####1）创建用于安装openGauss的文件夹
+>mkdir -p /opt/software/openGauss
+
+将本机上下载的xxx.tar.bz2拖动到图形化界面中的任意文件夹
+右键打开properties找到压缩包所在位置
+
+
+）
+
+解压到创建的文件夹
+>cd /home/louie
+tar -jxf openGauss-2.0.1-CentOS-64bit.tar.bz2 -C /opt/software/openGauss/
+
+####2）安装OpenGauss
+进入解压好的文件夹中
+>cd /opt/software/openGauss/simpleInstall/
+
+根据文件夹中readme文件中的指导开始安装
+>sh install.sh -w gauss@123
+
+极简版采用安装脚本
+
+
+####3）安装成功
+
+
+###4.OpenGauss使用测试
+####1）加入PATH
+
+
+####2）连接默认数据库测试
+
+
+####3）创建新数据库test（指令后要加分号）
+
+####4）测试直接建表
+
+####5）测试使用JDBC连接数据库
+Ifconfig命令查找安装opengauss的虚拟机所在IP地址（inet后面的地址）
+
+根据找到的ip地址修改pg_hba.conf文件
+
+
+在原电脑编写测试连接的java文件，例如openGaussDemo.java
+
+配置好jdk，解压下载好的jdbc，获得postgresql.jar文件。
+将postgresql.jar openGaussDemo.java放在同一文件夹中，在cmd中进入该目录，执行：
+>javac -encoding utf-8 -cp d:\Download\postgresql.jar openGaussDemo.java
+
+编译java文件。
+再执行：
+>java -cp .;D:/Download/postgresql.jar openGaussDemo
+
+运行测试代码。
+
+连接成功。
+
+###5.过程中遇到的问题
+####1）安装step1报错
+
+解决：不能在root下进行安装。
+
+####2）安装step2报错
+
+解决：在/etc/sysctl.conf中加入语句kernel.sem = 250 32000 100 999，然后执行sysctl -p。
+实际上这个报错是在没有进行系统内核参数修改时出现的，执行完上面centos的环境配置后可以一步到位。
+
+####3）step3报错
+解决：需要用chown -R 用户名:dbgrp /opt授权。
+
+####4）创建用户组dbgrp时报错
+
+解决：在root下操作
+
+####5）测试新建数据库，发现没完成指令。
+解决：sql指令后加分号。
+
+####6）虚拟机卡死
+原因：原先设置的分配虚拟机内存为2G，估计是安装了centos的图形化界面，导致卡死。
+解决：虚拟机分配4G内存。
+
+####7）jdbc连接虚拟机上的数据库报错：FATAL: Forbid remote connection with trust method!
+
+解决：参考https://bbs.huaweicloud.com/forum/thread-102401-1-1.html
+进入安装目录中/opt/software/openGauss/data/single_node中修改pg_hba.conf 将其中trust改为sha56
+
diff --git a/content/zh/post/luoyuchen/figures/1.png b/content/zh/post/luoyuchen/figures/1.png
new file mode 100644
index 0000000000000000000000000000000000000000..c0766c878d2df76297a0e599c3ab07e75a417d07
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/1.png differ
diff --git a/content/zh/post/luoyuchen/figures/10.png b/content/zh/post/luoyuchen/figures/10.png
new file mode 100644
index 0000000000000000000000000000000000000000..69e422b7b8214227b629a82e035162bc14e64a8b
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/10.png differ
diff --git a/content/zh/post/luoyuchen/figures/11.png b/content/zh/post/luoyuchen/figures/11.png
new file mode 100644
index 0000000000000000000000000000000000000000..5945694fed68c166e904226a943b9fd35edd29cd
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/11.png differ
diff --git a/content/zh/post/luoyuchen/figures/12.png b/content/zh/post/luoyuchen/figures/12.png
new file mode 100644
index 0000000000000000000000000000000000000000..eb8899c31a96abba83da4970853e9545a3fb6b55
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/12.png differ
diff --git a/content/zh/post/luoyuchen/figures/13.png b/content/zh/post/luoyuchen/figures/13.png
new file mode 100644
index 0000000000000000000000000000000000000000..805876c5700b4be674aa04e21d3576b4c795ee06
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/13.png differ
diff --git a/content/zh/post/luoyuchen/figures/14.png b/content/zh/post/luoyuchen/figures/14.png
new file mode 100644
index 0000000000000000000000000000000000000000..5eb07059426f68c0a9d4f3d1145fb8f6cd6dbbdb
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/14.png differ
diff --git a/content/zh/post/luoyuchen/figures/15.png b/content/zh/post/luoyuchen/figures/15.png
new file mode 100644
index 0000000000000000000000000000000000000000..17c54ce53e7b79b4123f6419f0224b37055f82f6
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/15.png differ
diff --git a/content/zh/post/luoyuchen/figures/16.png b/content/zh/post/luoyuchen/figures/16.png
new file mode 100644
index 0000000000000000000000000000000000000000..66d6879f5ce8d2c83e25ac7151fdaed56a38de9f
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/16.png differ
diff --git a/content/zh/post/luoyuchen/figures/17.png b/content/zh/post/luoyuchen/figures/17.png
new file mode 100644
index 0000000000000000000000000000000000000000..4a1b24758f9544c97781b3c3503ed0c16e45f914
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/17.png differ
diff --git a/content/zh/post/luoyuchen/figures/18.png b/content/zh/post/luoyuchen/figures/18.png
new file mode 100644
index 0000000000000000000000000000000000000000..b27712a4a64a44c8379feaff8a52cc69bb7c998f
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/18.png differ
diff --git a/content/zh/post/luoyuchen/figures/19.png b/content/zh/post/luoyuchen/figures/19.png
new file mode 100644
index 0000000000000000000000000000000000000000..a078bbb82adcd494f07b7009f2f4a75fdf556163
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/19.png differ
diff --git a/content/zh/post/luoyuchen/figures/2.png b/content/zh/post/luoyuchen/figures/2.png
new file mode 100644
index 0000000000000000000000000000000000000000..10d6d32ae5b14ad677bdd217885016a5dc7c2916
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/2.png differ
diff --git a/content/zh/post/luoyuchen/figures/20.png b/content/zh/post/luoyuchen/figures/20.png
new file mode 100644
index 0000000000000000000000000000000000000000..e002e0d1f13249320275e92412a3af39b0924629
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/20.png differ
diff --git a/content/zh/post/luoyuchen/figures/21.png b/content/zh/post/luoyuchen/figures/21.png
new file mode 100644
index 0000000000000000000000000000000000000000..b3d07f93b0d98b1b6cb243c58edb291271ff1bdd
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/21.png differ
diff --git a/content/zh/post/luoyuchen/figures/22.png b/content/zh/post/luoyuchen/figures/22.png
new file mode 100644
index 0000000000000000000000000000000000000000..96dd498496327339586b2e4594895a1edfefb85e
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/22.png differ
diff --git a/content/zh/post/luoyuchen/figures/23.png b/content/zh/post/luoyuchen/figures/23.png
new file mode 100644
index 0000000000000000000000000000000000000000..682fdee0c0b6cc2c89657cf3a1f21545cc56c9de
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/23.png differ
diff --git a/content/zh/post/luoyuchen/figures/24.png b/content/zh/post/luoyuchen/figures/24.png
new file mode 100644
index 0000000000000000000000000000000000000000..42f2e9faebb879437ebf58590f28b5edb198cad7
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/24.png differ
diff --git a/content/zh/post/luoyuchen/figures/25.png b/content/zh/post/luoyuchen/figures/25.png
new file mode 100644
index 0000000000000000000000000000000000000000..11deb6e9af9c641d7cc70347ddb34a09ea78eafe
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/25.png differ
diff --git a/content/zh/post/luoyuchen/figures/26.png b/content/zh/post/luoyuchen/figures/26.png
new file mode 100644
index 0000000000000000000000000000000000000000..14aba54c7481132a8cda88ba7b3394ca3fc94a11
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/26.png differ
diff --git a/content/zh/post/luoyuchen/figures/3.png b/content/zh/post/luoyuchen/figures/3.png
new file mode 100644
index 0000000000000000000000000000000000000000..af1466ae5403bbc6518a7cb055c264a520480e5c
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/3.png differ
diff --git a/content/zh/post/luoyuchen/figures/4.png b/content/zh/post/luoyuchen/figures/4.png
new file mode 100644
index 0000000000000000000000000000000000000000..f4484aba9a466b5e791e3321e6ac1c8c1a824822
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/4.png differ
diff --git a/content/zh/post/luoyuchen/figures/5.png b/content/zh/post/luoyuchen/figures/5.png
new file mode 100644
index 0000000000000000000000000000000000000000..f3081daf3d83a2651860ed40ccd30273d15a357d
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/5.png differ
diff --git a/content/zh/post/luoyuchen/figures/6.png b/content/zh/post/luoyuchen/figures/6.png
new file mode 100644
index 0000000000000000000000000000000000000000..f8da3a74ec63049cc77041c8a6e98897f6c2b930
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/6.png differ
diff --git a/content/zh/post/luoyuchen/figures/7.png b/content/zh/post/luoyuchen/figures/7.png
new file mode 100644
index 0000000000000000000000000000000000000000..b83661e7e305e5c5d46d34442a0ab16e6459a411
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/7.png differ
diff --git a/content/zh/post/luoyuchen/figures/8.png b/content/zh/post/luoyuchen/figures/8.png
new file mode 100644
index 0000000000000000000000000000000000000000..d8c8b63c703e5594927717fe996ef7b6cb13ea10
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/8.png differ
diff --git a/content/zh/post/luoyuchen/figures/9.png b/content/zh/post/luoyuchen/figures/9.png
new file mode 100644
index 0000000000000000000000000000000000000000..247beb379fe0380a01392b7620dc52f5aaa88714
Binary files /dev/null and b/content/zh/post/luoyuchen/figures/9.png differ
diff --git a/content/zh/post/luoyuchen/title/1.png b/content/zh/post/luoyuchen/title/1.png
new file mode 100644
index 0000000000000000000000000000000000000000..c0766c878d2df76297a0e599c3ab07e75a417d07
Binary files /dev/null and b/content/zh/post/luoyuchen/title/1.png differ
diff --git a/content/zh/post/mingruifu/image/1.jpg b/content/zh/post/mingruifu/image/1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..0b7fac59c9955d78d6b0d8b9a8dc99e37adafbed
Binary files /dev/null and b/content/zh/post/mingruifu/image/1.jpg differ
diff --git a/content/zh/post/mingruifu/image/2.jpg b/content/zh/post/mingruifu/image/2.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7870fdeea0c60f5f7b6f996cecaec49017d101cf
Binary files /dev/null and b/content/zh/post/mingruifu/image/2.jpg differ
diff --git "a/content/zh/post/mingruifu/openGauss\345\256\211\350\243\205\345\271\266\344\275\277\347\224\250DataStudio\345\267\245\345\205\267\350\277\236\346\216\245\344\275\277\347\224\250.md" "b/content/zh/post/mingruifu/openGauss\345\256\211\350\243\205\345\271\266\344\275\277\347\224\250DataStudio\345\267\245\345\205\267\350\277\236\346\216\245\344\275\277\347\224\250.md"
new file mode 100644
index 0000000000000000000000000000000000000000..ebace71b4dc5843b45bd8d33a7740dd983e6ae3e
--- /dev/null
+++ "b/content/zh/post/mingruifu/openGauss\345\256\211\350\243\205\345\271\266\344\275\277\347\224\250DataStudio\345\267\245\345\205\267\350\277\236\346\216\245\344\275\277\347\224\250.md"
@@ -0,0 +1,177 @@
++++
+title = "本地安装单机版openGauss并使用DataStudio工具连接使用"
+date = "2021-12-20"
+tags = ["openGauss安装及DataStudio工具简单使用"]
+archives = "2021-12"
+author = "mingruifu"
+summary = "openGauss安装及DataStudio工具简单使用"
+img="/zh/post/mingruifu/title/title1.png"
+times = "11:30"
++++
+
+### 1.虚拟机的安装
+
+#### 1.1安装virtualbox
+
+1. 访问[https://www.virtualbox.org/wiki/Downloads](https://www.virtualbox.org/wiki/Downloads) 安装对应平台的版本
+2. 按照提示步骤安装好virtualbox环境
+
+#### 1.2安装vagrant
+
+1. 访问[https://www.vagrantup.com/downloads](https://www.vagrantup.com/downloads) 安装对应平台的vagrant
+
+2. 按照提示步骤安装好vagrant环境
+
+3. 执行`vagrant -v`,显示如下信息，则安装成功
+
+ ```shell
+ Vagrant 2.2.19
+ ```
+
+#### 1.3安装centos7
+
+1. 建立一个文件夹创建虚拟机环境
+
+2. 使用国内镜像源初始化Vagrantfile文件
+
+ ```shell
+ vagrant init centos7 https://mirrors.ustc.edu.cn/centos-cloud/centos/7/vagrant/x86_64/images/CentOS-7.box
+ ```
+
+3. 修改Vagrantfile文件，配置虚拟机
+
+```ruby
+Vagrant.configure("2") do |config|
+ # 镜像名称
+ config.vm.box = "centos7"
+ # 国内镜像源
+ config.vm.box_url = "https://mirrors.ustc.edu.cn/centos-cloud/centos/7/vagrant/x86_64/images/CentOS-7.box"
+ # 使用公共网络
+ config.vm.network "public_network"
+ config.vm.provider "virtualbox" do |vb|
+ # 配置虚拟机名称
+ vb.name = "openGauss"
+ # 配置虚拟机cpu个数
+ vb.cpus = 2
+ # 配置虚拟机内存
+ vb.memory = 1024
+ end
+end
+```
+
+ 4.启动并进入虚拟机
+
+```shell
+# 启动虚拟机
+vagrant up
+# 进入虚拟机
+vagrant ssh
+# 关闭防火墙
+systemctl disable firewalld.service
+systemctl stop firewalld.service
+# 关闭SELinux
+sed -i s/SELINUX=.*/SELINUX=disabled/ /etc/selinux/config
+# 将各数据库节点的字符集设置为相同的字符集，可以在/etc/profile文件中添加“export LANG=XXX”（XXX为Unicode编码）
+vim /etc/profile
+# 关闭交换内存
+swapoff -a
+# 更新yum
+yum -y update
+# 清除缓存
+yum clean all
+# 安装openjdk
+yum install -y java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64
+yum install -y java-1.8.0-openjdk-devel-1.8.0.212.b04-0.el7_6.x86_64
+# 配置jdk环境变量
+vi /etc/profile
+export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.212.b04-0.el7_6.x86_64
+export CLASSPATH=.:$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
+export PATH=$PATH:$JAVA_HOME/bin
+# 生效环境变量
+source /etc/profile
+# 重启虚拟机
+vagrant reload
+```
+
+### 2.安装单机版openGauss
+
+1. 访问`https://opengauss.org/zh/download.html`下载`openGauss_2.1.0 极简版`
+2. 使用vagrant用户安装openGauss
+
+```shell
+# 将安装包放在Vagrantfile同级目录，并重启虚拟机
+vagrant reload
+#进入安装包所在目录
+cd /vagrant
+# 解压openGauss压缩包到安装目录
+tar -jxf openGauss-2.1.0-CentOS-64bit.tar.bz2 -C /opt/openGauss
+# 进入解压后目录下的simpleInstall
+cd /opt/openGauss/simpleInstall
+# 执行install.sh脚本安装openGauss
+sh install.sh -w test@123 -p 40200
+-w 初始化密码
+-p 指定端口 默认5432
+# 使用如下命令连接数据库
+gs_ctl start|stop|restart -D $GAUSSHOME/data/single_node -Z single_node
+```
+
+> 执行时，如果出现报错“the maximum number of SEMMNI is not correct, the current SEMMNI is xxx. Please check it.”，请使用有root权限的用户执行如下命令 。
+
+```shell
+sysctl -w kernel.sem="250 85000 250 330"
+```
+
+3. 修改`/opt/openGauss/data/single_node/pg_hba.conf`文件
+
+```shell
+# 在文件末尾追加客户端host认证方式
+host all all 0.0.0.0/0 sha256
+```
+
+4. 修改`/opt/openGauss/data/single_node/postgresql.conf`文件
+
+```shell
+# 将监听地址设置为*或者指定的客户端ip地址
+listen_addresses = '*'
+```
+
+5. 重启数据库
+
+```shell
+cd /opt/openGauss/bin
+# 重启数据库
+./gs_ctl restart -D /opt/openGauss/data/single_node/ -Z single_node
+```
+
+6. 连接数据库，创建用户
+
+```shell
+# 连接数据库
+/opt/openGauss/bin/gsql -d postgres -p 40200 -W 'test@123' -r
+# 创建一个用户
+create role test with createddb password "test@1234";
+# 创建数据库
+create database testdb owner test;
+# 授予用户对数据库的全部权限
+grant all privileges on database testdb to test;
+# 授予该用户管理员权限
+grant all privileges to test;
+```
+
+7. 使用新用户连接数据库
+
+```shell
+/opt/openGauss/bin/gsql -d postgres -p 40200 -U test -W 'test@123' -r
+```
+
+### 3.下载安装DataStudio
+
+1. 访问[https://opengauss.org/zh/download.html](https://opengauss.org/zh/download.html) 下载DataStudio_2.1.0
+2. 打开DataStudio连接数据库
+
+3. 连接上之后可以看见DataStudio的功能操作界面
+
+- 1：工具栏菜单
+- 2：数据库对象浏览器
+- 3：数据库操作终端，书写业务sql
+- 4: sql助手
diff --git a/content/zh/post/mingruifu/title/title1.png b/content/zh/post/mingruifu/title/title1.png
new file mode 100644
index 0000000000000000000000000000000000000000..70953c80a88ba62ea617a60b8527e6e739a8f9ea
Binary files /dev/null and b/content/zh/post/mingruifu/title/title1.png differ
diff --git "a/content/zh/post/mqq/OpenGauss SQL\350\247\243\346\236\220\346\272\220\347\240\201\345\210\206\346\236\220.md" "b/content/zh/post/mqq/OpenGauss SQL\350\247\243\346\236\220\346\272\220\347\240\201\345\210\206\346\236\220.md"
new file mode 100644
index 0000000000000000000000000000000000000000..1d1b4fb6d393f5e15e72dead837b0ba6fbaae43b
--- /dev/null
+++ "b/content/zh/post/mqq/OpenGauss SQL\350\247\243\346\236\220\346\272\220\347\240\201\345\210\206\346\236\220.md"
@@ -0,0 +1,186 @@
++++
+title = "OpenGauss SQL解析源码分析"
+date = "2021-11-27"
+tags = ["OpenGauss SQL解析源码分析"]
+archives = "2021-11"
+author = "mqq"
+summary = "OpenGauss SQL解析源码分析"
+img = "/zh/post/mqq/title/title.png"
++++
+
+# OpenGauss SQL解析源码分析
+
+
+## SQL 引擎简介：
+
+SQL引擎整个编译的过程如下图所示，在编译的过程中需要对输入的SQL语言进行词法分析、语法分析、语义分析，从而生成逻辑执行计划，逻辑执行计划经过代数优化和代价优化之后，产生物理执行计划。
+
+SQL解析通常包含词法分析、语法分析、语义分析几个子模块。SQL是介于关系演算和关系代数之间的一种描述性语言，它吸取了关系代数中一部分逻辑算子的描述，而放弃了关系代数中"过程化"的部分，SQL解析主要的作用就是将一个SQL语句编译成为一个由关系算子组成的逻辑执行计划。
+
+数据库的SQL引擎是数据库重要的子系统之一，它对上负责承接应用程序发送过来的SQL语句，对下则负责指挥执行器运行执行计划。其中优化器作为SQL引擎中最重要、最复杂的模块，被称为数据库的"大脑"，优化器产生的执行计划的优劣直接决定数据库的性能。右图为SQL引擎的各个模块的响应过程。下图的绿色部分代表解析树的生成，；蓝色部分代表查询树的生成部分。
+
+
+
+
+## 理论分析
+**SQL解析各模块功能介绍：**
+
+ 假设要在student表里找到查找序号为1的学生姓名，其SQL语句如下：
+
+> Select name
+>
+>from student
+>where no=1
+
+1. **词法分析:**
+
+> 从查询语句中识别出系统支持的关键字、标识符、运算符、终结符等，确定每个词固有的词性。分析结果如下图所示，可以看到一个SQL语句按一个一个的字词或符号分开，形成可以被解读语义的字符。
+
+ | **词性** | **内容** |
+ | ------------ | --------- |
+ | **关键字** | **Select、from、where** |
+ | **标识符** | **name、student、no** |
+ | **操作符** | **=** |
+ | **常量** | **1** |
+
+###### **（2）语法分析:**
+
+根据SQL的标准定义语法规则，使用词法分析中产生的词去匹配语法规则，如果一个SQL语句能够匹配一个语法规则，则生成对应的抽象语法树（AST）。
+
+下图中的\+ + +## 硬件要求 +- 内存 >= 32GB + +- CPU >= 8核 2.0GHZ + +- 硬盘 >= 40GB + +## 软件要求 +- 操作系统：CentOS 7.6 x86_64 + +- Python：Python 3.6.X + +- 虚拟机：VMware：16.1.2 + + + +# 配置CentOS7.6 + +安装完成CentOS7.6后进入系统，开始配置。 + +## 设置语言，时区： + +## 设置网络连接： + + + +设置完成后，来到设备选项界面按照如下配置即可。 + +## 设置用户名和密码 + +###安装net-tools工具 + + + +安装完成后可以看到 “complete！” + +## 使用SSH连接并设置相关 + + + +_可能遇到的问题：过程试图写入的管道不存在_ + + +_解决方法：重新检查Host地址是否变更，每次输入的Host可能会发生变化_ + +## yum源更新 + +## 安装python3.6 + +## 安装其他相关文件 + +# 开始安装 +
+ +## 关闭防火墙和Selinux +命令如下： +``` +systemctl disable firewalld.service +systemctl stop firewalld.service +sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config +setenforce 0 +``` +设置字符集参数并检查设置时区： + +## 创建用户组与用户 +创建用户组dbgrp、用户omm，将该用户添加至root组,并修改用户omm的密码 + +## 解压 + +_可能遇到的问题：解压不成功_ + +_解决方案：尝试重新安装VMware Tools_ + + +## 安装脚本： +命令格式：`sh install.sh -w xxxx` + +由于openGauss端口号默认为5432默认生成名称为postgres的数据库： + +使用ps和gs_ctl查看进程是否正常： + +## 命令行访问数据库 +*以下以默认数据库里的school数据库为例* + +查看数据库school的class表结构： + +school数据库相关信息： + +# 以JDBC的方式访问数据库并查找 +*以查找school数据库中的class表为例，查找其中的 cla_id, cla_name, cla_teacher并输出：* + +```java +import java.sql.Connection; +import java.sql.DriverManager; +import java.sql.ResultSet; +import java.sql.SQLException; +import java.sql.Statement; + +class openGaussTest { + public static void main(String[] args) { + Connection conn = getConnect("mqq", "Mqq123123"); + + Statement stmt = null; + try { + stmt = conn.createStatement(); + ResultSet rs = null; + try { + rs = stmt.executeQuery( + "select cla_id, cla_name, cla_teacher from class;"); + while (rs.next()) { + int cla_id = rs.getInt(1); + String cla_name = rs.getString(2); + int cla_teacher = rs.getInt(3); + System.out.println(cla_id +" "+ cla_name + " "+cla_teacher); + } + } catch (SQLException e) { + if (rs != null) { + try { + rs.close(); + } catch (SQLException e1) { + e1.printStackTrace(); + } + } + e.printStackTrace(); + } + + stmt.close(); + } catch (SQLException e) { + if (stmt != null) { + try { + stmt.close(); + } catch (SQLException e1) { + e1.printStackTrace(); + } + } + e.printStackTrace(); + } + + try { + conn.close(); + } catch (SQLException e) { + e.printStackTrace(); + } + } + + public static Connection getConnect(String username, String passwd) { + // 驱动类 + String driver = "org.postgresql.Driver"; + // 数据库连接描述符 + String sourceURL = "jdbc:postgresql://192.168.195.129:5432/school"; + Connection conn = null; + + try { + // 加载驱动 + Class.forName(driver); + } catch (Exception e) { + e.printStackTrace(); + return null; + } + + try { + // 创建连接 + conn = DriverManager.getConnection(sourceURL, username, passwd); + System.out.println("Connection succeed!"); + } catch (Exception e) { + e.printStackTrace(); + return null; + } + + return conn; + } + +} +``` + +*查询结果如下：* + + + + diff --git a/content/zh/post/mqq/title/title.png b/content/zh/post/mqq/title/title.png new file mode 100644 index 0000000000000000000000000000000000000000..557eeb0f0228faee274149d39dc2bd6885ce7159 Binary files /dev/null and b/content/zh/post/mqq/title/title.png differ diff --git "a/content/zh/post/opengauss_deploy/ECS\344\270\212\351\203\250\347\275\262openGauss\346\225\260\346\215\256\345\272\223.md" "b/content/zh/post/opengauss_deploy/ECS\344\270\212\351\203\250\347\275\262openGauss\346\225\260\346\215\256\345\272\223.md" new file mode 100644 index 0000000000000000000000000000000000000000..b95bb4a17ec41146cd4dc0742caeb2fa21a04f8f --- /dev/null +++ "b/content/zh/post/opengauss_deploy/ECS\344\270\212\351\203\250\347\275\262openGauss\346\225\260\346\215\256\345\272\223.md" @@ -0,0 +1,609 @@ + + + +## 在ECS上安装部署openGauss数据库指导手册 + +文档下载：[在ECS上安装部署openGauss数据库指导手册.docx](../docs/在ECS上安装部署openGauss数据库指导手册.docx) + + + +## 前 言 +### 简介 +openGauss是关系型数据库，采用客户端/服务器，单进程多线程架构，支持单机和一主多备部署方式，备机可读，支持双机高可用和读扩展。 +本实验主要描述openGauss数据库在弹性云服务器（openEuler）上的安装部署。 +#### 内容描述 +本实验主要内容为弹性云服务器（openEuler）上安装部署openGauss数据库，并进行简单的数据库相关操作。 +#### 前置条件 +由于本实验主要是在openEuler操作系统上进行openGauss数据库的部署，需要掌握Linux系统的基本操作和系统命令，详细请参见附录一。 +#### 实验环境说明 + 1. 组网说明 +本实验环境为华为云环境，需要购买弹性云服务器。 + 2. 设备介绍 +为了满足openGauss安装部署实验需要，建议每套实验环境采用以下配置： +软件类型和配置描述如下： + +| 设备名称 | 设备型号 | +| --- | --- | +| Linux操作系统 | openEuler20.3LTS | +| Python | Python 3.7.X | + +### 实验概览 + +本实验概览图 + + + +## 1 openGauss数据库安装 + +### 1.1 实验介绍 + +1.1.1 关于本实验 + +本实验主要描述openGauss数据库在openEuler弹性云服务器上的安装部署。 + +1.1.2 实验目的 + +> 了解openGauss数据库部署方式；\ +> 掌握openGauss数据库安装部署方法。 +> +### 1.2 购买弹性云服务器ECS（openEuler ARM 操作系统） +1.2.1 登录华为云 \ +步骤 1进入华为云官网。\ +华为云官网：https://www.huaweicloud.com/，进入华为云官网，点击登录。\ + + +步骤 2输入账号名和密码，点击登录。 + + +如果还没有注册，点击免费注册，按步骤进行注册后进行登录。 + +1.2.2 购买弹性云服务器ECS \ +步骤 1 在华为云主页(https://www.huaweicloud.com/)点击产品，选择基础服务，再选择弹性云服务器ECS。 + + +步骤 2 进入弹性云服务器ECS购买界面。 + + +步骤 3 自定义购买进行基础配置。 +表1-1ECS基础配置 + +| 配置选项 | 配置值 | +| --- | --- | +|计费| 华北-北京四（推荐，其他区域可能会导致无法选择openEuler公共镜像）| +|CPU架构| 鲲鹏计算| +|规格| 最新系列 2vCPUs|4GB| +|镜像| 公共镜像：openEuler openEuler 20.03 64bit with ARM(40GB) | + + + + + +其余默认即可，点击下一步网络配置。 + +步骤 4 自定义购买进行网路配置。 +表1-2ECS网络配置 + +| 配置选项 | 配置值 | +| --- | --- | +|网络| Vpc-default（192.168.0.0/16）（选现有默认网络即可） | +|弹性公网IP| 现在购买| +|公网带宽| 按流量计费| +|带宽大小| 5| + + + + + +其余默认即可，点击下一步高级配置。 + +步骤 5 自定义购买进行高级配置。\ + +记住用户名为root，然后输入自定义密码和确认密码，其余默认即可。点击下一步确认设置。 + + +步骤 6 确认配置购买成功。 + + +确认设置信息，尤其是配置费用，然后勾选协议“我已经阅读并同意《华为镜像免责声明》”，点击立即购买。 + + +查看云服务器列表 + + + +购买成功！ +注意：本次购买鲲鹏服务器价格为公测价格，具体价格以华为云官网为准。 + +### 1.3 修改操作系统配置 + +为了操作方便，可以使用SSH工具（比如：PuTTY等）从本地电脑通过配置弹性云服务器的弹性公网IP地址（如:124.70.36.251）来连接ECS，并使用ROOT用户来登录。 + + +1.3.2 设置字符集参数 + +将各数据库节点的字符集设置为相同的字符集，可以在/etc/profile文件中添加"export LANG=XXX"（XXX为Unicode编码）。 +步骤 1在/etc/profile文件中添加"export LANG= en_US.UTF‐8"。 +``` +[root@ecs-c9bf ~]# cat >>/etc/profile<
| + | ++ | +
| + | ++ | +
| + | ++ | +
| + | ++ | +
+
+> **说明：**
+>本文档中描述的时间仅供参考，实际操作时间以现场情况为准。
+
+**表 1** 升级流程执行效率估计
+
+
+| + | ++ | ++ | ++ | ++ | +
|---|---|---|---|---|
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | ++ | ++ | +
|---|---|---|---|---|---|
| + | ++ | ++ | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | +
| + | ++ | ++ | ++ | +
+
+ 安装位置默认在C盘，点击**更改**可以修改安装位置，我安装到了`E:\VMware\`下，安装路径尽量不要有中文，记得**勾选**PATH按钮，这样不用自己再添加环境变量，可勾选增强型键盘驱动程序，此功能可更好地处理国际键盘和带有额外按键的键盘：
+
+
+
+ 一直点击下一步：
+
+
+
+
+
+
+
+
+
+ 点击输入许可证，密钥可以自己购买，或者百度搜索以下，多尝试几个，下面是我当时安装使用的密钥，不知道现在失效没有：
+
+
+
+ 安装后可能要求重启系统，重启后进入软件。依次点击导航栏中的 `帮助 -> 关于 VMware Workstation` ，查看许可证信息的状态，如下图所示即为激活成功。
+
+
+
+### 1.2 虚拟机部署centos
+
+ 可以在官方网站下载centos7，只有centos7.6支持安装opengauss，如果找不到7.6版本的centos，也可安装稍高版本的centos，安装完之后需要在系统文件中做相关修改，我下载的是[centos7.9](https://mirrors.aliyun.com/centos/7.9.2009/isos/x86_64/)，文件太大了，需要下一段时间，记得更改下载保存的位置，我放在了`E:\Linux\`下。`我第一次安装时不知道必须安装centos7，安装成了centos8，而重新安装时部分截图忘记保存，所以下面部分截图出现的centos8，大家视为centos7就好`。
+
+
+
+ 下载完成，打开VMware选择新建虚拟机：
+
+
+
+
+
+ 浏览文件，选择centos7的下载目录，选择镜像文件：
+
+
+
+ 设置虚拟机的名称和账户名，以及密码：
+
+
+
+ 选择虚拟机的安装位置：
+
+
+
+ 设置磁盘的容量，默认为20GB，我修改为了40GB，点击下一步即可：
+
+
+
+ 自定义硬件可以根据自己的需求，修改centos的设置：
+
+
+
+ 内存大小默认为1GB，我设置为了2GB：
+
+
+
+ 网络适配器选择NAT模式，设置完成之后点击确定：
+
+
+
+
+
+ 等待安装：
+
+
+
+
+
+
+
+
+
+
+
+ 中间会出现这个页面让你设置，如果你没赶快进行操作，就跳过去了，设置不设置都没有关系，安装完成之后也可以设置：
+
+
+
+ 如下是，点击各个按钮进行时间、显示、输入法的设置：
+
+
+
+
+
+
+
+
+
+ 设置完成之后继续安装，安装完毕，输入设置的密码之后，回车：
+
+
+
+ 安装成功！
+
+
+
+### 1.3 centos配置
+
+#### 1.3.1 设置系统版本
+
+ 因为opengauss要求的centos版本是7.6，因此我们需要修改`/etc/redhat-release`文件：
+
+
+
+```shell
+#进入管理员模式
+su
+#打开文件，进行编辑
+vi /etc/redhat-release
+```
+
+ 
+
+ 修改成如下内容`CentOS Linux release 7.6 (Core)`：
+
+ 
+
+#### 1.3.2 网络设置
+
+ 使用`ifconfig`或者`ip addr`可以查看自己的ip地址
+
+ 
+
+ 我的网卡的名字为ens-33，接下来，给网卡增加DNS：`echo 'DNS1=114.114.114.114'>>/etc.sysconfig/network-scripts/ifcfg-ens33`
+
+ 重启网卡：`systemctl restart network`，测试是否可以访问：`ping www.baidu.com`
+
+ 
+
+ 如上图所示，则可以访问。
+
+#### 1.3.3 修改主机名
+
+```shell
+echo "vector" > /etc/hostname
+echo "192.168.48.128 vector" >>/etc/hostd
+```
+
+ 最后系统重启后记得查看主机名是否修改成功：
+
+```
+cat /etc/hostname
+```
+
+#### 1.3.4 配置YUM源
+
+- 删除系统自带的yum源
+
+ ```shell
+ rm -rf /etc/yum.repos.d/*
+ ```
+
+- 下载阿里云yum源
+
+ ```shell
+ wget -O /etc/yum.repos.d/CentOS-Base http://mirrors.aliyun.com/repo/Centos7.repo
+ ```
+
+- 生成仓库缓存
+
+ ```shell
+ yum makecache
+ ```
+
+- 安装python3.6，一定要装3.6版本
+
+ ```shell
+ sudo yum install epel-release
+ sudo yum install python36
+ ```
+
+#### 1.3.5 关闭防火墙
+
+```shell
+sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config
+```
+
+#### 1.3.6 设置字符集
+
+```shell
+cat >>/etc/profile<
+
+ 如上表示预安装成功！
+
+### 2.2 执行安装
+
+#### 2.2.1 检查
+
+ 检查安装包和openGauss配置文件在规划路径下是否已存在，如果没有，重新执行预安装，确保预安装成功，再执行以下步骤。
+
+#### 2.2.2 切换用户
+
+ 登录到openGauss的主机，并切换到omm用户：
+
+```shell
+su omm
+```
+
+- omm指的是前置脚本gs_preinstall中-U参数指定的用户。
+- 安装脚本gs_install必须以前置脚本中指定的omm执行，否则，脚本执行会报错。
+
+#### 2.2.3 安装
+
+ 使用gs_install安装openGauss。
+
+```shell
+gs_install -X /opt/software/openGauss/cluster_config.xml
+```
+
+ `/opt/software/openGauss/cluster_config.xml`为openGauss配置文件的路径。在执行过程中，用户需根据提示输入数据库的密码，密码具有一定的复杂度，为保证用户正常使用该数据库，请记住输入的数据库密码。
+
+ 设置的密码要符合复杂度要求：
+
+- 最少包含8个字符。
+- 不能和用户名、当前密码（ALTER）、或当前密码反序相同。
+- 至少包含大写字母（A-Z），小写字母（a-z），数字，非字母数字字符（限定为~!@#$%^&*()-_=+\|[{}];:,<.>/?）四类字符中的三类字符。
+
+
+
+ 执行如下命令检查数据库状态是否正常:
+
+```shell
+gs_om -t status
+```
+
+
+
+ `cluster_state` 显示“Normal”表示数据库可正常使用。
+
+
+
+ 如首次安装数据库不成功，则卸载后重新安装，卸载方式如下：
+
+```shell
+gs_uninstall ‐‐delete‐data
+```
+
+
+
+#### 2.2.4 初始化数据库
+
+使用SQL语句**创建数据库**database时，指定数据库的字符集为GBK。
+
+```shell
+#后面跟的是端口号,我的是15400
+gsql -d postgres -p 15400
+```
+
+```sql
+CREATE DATABASE mydb WITH ENCODING 'GBK' template = template0;
+```
+
+
+
+ 显示如下信息:
+
+```sql
+CREATE DATABASE
+```
+
+创建**schema**：
+
+```sql
+CREATE SCHEMA tpcds;
+```
+
+创建表：
+
+```sql
+CREATE TABLE tpcds.warehouse_t1
+(
+ W_WAREHOUSE_SK INTEGER NOT NULL,
+ W_WAREHOUSE_ID CHAR(16) NOT NULL,
+ W_WAREHOUSE_NAME VARCHAR(20) ,
+ W_WAREHOUSE_SQ_FT INTEGER ,
+ W_STREET_NUMBER CHAR(10) ,
+ W_STREET_NAME VARCHAR(60) ,
+ W_STREET_TYPE CHAR(15) ,
+ W_SUITE_NUMBER CHAR(10) ,
+ W_CITY VARCHAR(60) ,
+ W_COUNTY VARCHAR(30) ,
+ W_STATE CHAR(2) ,
+ W_ZIP CHAR(10) ,
+ W_COUNTRY VARCHAR(20) ,
+ W_GMT_OFFSET DECIMAL(5,2)
+);
+```
+
+
+
+查看表信息： 
+
+```sql
+insert into tpcds.warehouse_t1(w_warehouse_sk,w_warehouse_id) values(12,'000001');
+insert into tpcds.warehouse_t1(w_warehouse_sk,w_warehouse_id) values(25,'000002');
+select w_warehouse_sk, w_warehouse_id from tpcds.warehouse_t1;
+```
+
+向数据库中添加数据之后查看：
+
+如果不知道自己的端口号,可根据以下方式查看:
+
+- 查看自己的cluster_config.xml文件,查看自己将端口号设置为了多少.
+- 使用如下命令查看:
+
+```shell
+gs_om -t status --detail
+cd /opt/huawei/install/data/dn
+```
+
+
+
+### 2.3 JDBC连接数据库
+
+#### 2.3.1 准备java环境
+
+ 查看centos的java环境，centos自带java1.8，需要安装配套的javac，注意要是1.8.0版。
+
+```shell
+yum install java-1.8.0-openjdk-devel.x86_64
+```
+
+ 下载驱动包2.0.0版本[postgresql.jar](https://opengauss.obs.cn-south-1.myhuaweicloud.com/2.0.0/x86/openGauss-2.0.0-JDBC.tar.gz)，放在路径`/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.302.b08-0.el7_9.x86_64/jre/lib/ext`下：
+
+```shell
+cp postgresql.jar /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.302.b08-0.el7_9.x86_64/jre/lib/ext
+```
+
+
+
+ 测试是否具备运行java代码的环境：
+
+```shell
+java -version
+javac -version
+```
+
+ 
+
+ 已具备运行环境！
+
+#### 2.3.2 准备好连接的java代码
+
+ 记得替换成你设置的用户名、密码、端口号，如果你是按照我前面的操作，用户名应该是omm，
+
+```java
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.SQLException;
+import java.sql.Statement;
+import java.sql.CallableStatement;
+
+public class test{//keep
+ public static Connection getConnect(String username, String passwd)
+ {
+ //驱动类。
+ String driver = "org.postgresql.Driver";
+ //数据库连接描述符。将15400替换为自己的端口号
+ String sourceURL = "jdbc:postgresql://127.0.0.1:15400/postgres";
+ Connection conn = null;
+
+ try
+ {
+ //加载驱动。
+ Class.forName(driver);
+ }
+ catch( Exception e )
+ {
+ e.printStackTrace();
+ return null;
+ }
+
+ try
+ {
+ //创建连接。
+ conn = DriverManager.getConnection(sourceURL, username, passwd);
+ System.out.println("Connection succeed!");
+ }
+ catch(Exception e)
+ {
+ e.printStackTrace();
+ return null;
+ }
+
+ return conn;
+ };
+
+ //try to connect
+ public static void main(String[] args)
+ {
+ // TODO Auto-generated method stub
+ Connection conn = getConnect("user", "password");//replace by my user and password
+ //BatchInsertData(conn);
+ try
+ {
+ conn.close();
+ }
+ catch (SQLException e)
+ {
+ e.printStackTrace();
+ }
+ }
+}
+```
+
+#### 2.3.3 配置服务端远程连接
+
+- 以操作系统用户omm登录数据库。
+
+- 配置listen_addresses，即远程客户端连接使用的数据库主节点ip或者主机名。
+
+ 使用如下命令查看数据库主节点目前的listen_addresses配置。
+
+ ```shell
+ gs_guc check -I all -c "listen_addresses"
+ ```
+
+- 使用如下命令把要查询出的ip追加到listen_addresses后面，多个配置项之间用英文逗号分隔。例如，追加ip地址10.11.12.13。
+
+ ```shell
+ gs_guc set -I all -c "listen_addresses='localhost,10.11.12.13'"
+ ```
+
+- 执行如下命令重启openGauss
+
+ ```shell
+ gs_om -t stop && gs_om -t start
+ ```
+
+ 
+
+#### 2.3.4 连接
+
+- 首先需要启动数据库
+
+ ```shell
+ su omm
+ gs_om -t start
+ ```
+
+- 运行java代码
+
+ ```shell
+ javac test.java
+ java test
+ ```
+
+ 
+
+#### 2.3.5 操纵数据
+
+ 使用如下java代码访问并对表中数据进行查询（记得替换用户、密码和端口）：
+
+```java
+import java.sql.Connection;
+import java.sql.DriverManager;
+import java.sql.PreparedStatement;
+import java.sql.SQLException;
+import java.sql.Statement;
+import java.sql.CallableStatement;
+import java.sql.ResultSet;
+import java.sql.SQLException;
+
+public class gausstest{//keep
+ public static Connection getConnect(String username, String passwd)
+ {
+ //驱动类。
+ String driver = "org.postgresql.Driver";
+ //数据库连接描述符。
+ String sourceURL = "jdbc:postgresql://127.0.0.1:15400/postgres";
+ Connection conn = null;
+
+ try
+ {
+ //加载驱动。
+ Class.forName(driver);
+ }
+ catch( Exception e )
+ {
+ e.printStackTrace();
+ return null;
+ }
+
+ try
+ {
+ //创建连接。
+ conn = DriverManager.getConnection(sourceURL, username, passwd);
+ System.out.println("Connection succeed!");
+ }
+ catch(Exception e)
+ {
+ e.printStackTrace();
+ return null;
+ }
+
+ return conn;
+ };
+
+ //try to connect
+ public static void main(String[] args) throws SQLException
+ {
+ // TODO Auto-generated method stub
+ Connection conn = getConnect("user", "password");//replace by my user and password
+ //BatchInsertData(conn);
+ Statement st = conn.createStatement();
+ String sql = "select w_warehouse_sk,w_warehouse_id from tpcds.warehouse_t1";
+ ResultSet rs = st.executeQuery(sql);
+ while(rs.next()) {
+ int w_warehouse_sk = rs.getInt("w_warehouse_sk");
+ String w_warehouse_id = rs.getString("w_warehouse_id");
+ System.out.println("w_warehouse_sk = " + w_warehouse_sk + "; w_warehouse_id = " + w_warehouse_id);
+ }
+ try
+ {
+ conn.close();
+ st.close();
+ rs.close();
+ }
+ catch (SQLException e)
+ {
+ e.printStackTrace();
+ }
+ }
+}
+```
+
+ 
+
+## 3. 遇到的问题
+
+ 我感觉我把所有能遇到的问题都遇到了,最后成功是重装一遍,什么问题没遇到。
+
+### 3.1 使用gs_ctl提示找不到命令
+
+ 如下图所示：
+
+
参看博客[Linux下解决命令未找到的问题 - ML。 - 博客园 (cnblogs.com)](https://www.cnblogs.com/mnote/p/8832806.html)，对于本问题主要使用的命令是：
+
+```shell
+#进入管理员模式
+su
+which gs_ctl
+```
+
+
+
+ 接下来需要做的是把查找出的路径直接链接到/usr/bin下。操作如下：
+
+```shell
+ln -s xxx/xxx /usr/bin
+```
+
+ 以上xxx代表你查出来的路径。
+
+
+
+### 3.2 gs_om命令找不到
+
+ 不得不说极简版安装包下没有gs_om文件，我搜遍了也没有，在企业版中，我因为懒得重装把我同学下载的企业版中的gs_之类的文件全拷过来了，但是后来遇到了其他问题，我又重装了，不知道我这个操作最终会带来什么影响。
+
+### 3.3 sudo和su都用不了
+
+ sudo chmod -R 777 / 修改根目录权限问题修复，参考了[ 关于不小心777导致没法sudo权限后的修改解决办法_空木格子的博客-CSDN博客](https://blog.csdn.net/qq_39543212/article/details/84107240)
+
+ 我应该是因为sudo用不了提示sudo: must be setuid root，然后我进入根目录下修改了某个文件为777，直接导致su也用不了。这下好了，要用su让我先用sudo修改相关文件，要用sudo让我先用su修改文件！
+
+ 解决这个问题需要先进入安全模式，进入方法为：在开机的过程中按shift或ESC键，好像在系统中按F1还是F2也可以。
+
+ 此时，已经进入到具有root权限的字符界面，输入以下命令解决了。
+
+```shell
+ls -l /usr/bin/sudo
+chown root:root /usr/bin/sudo
+chmod 4755 /usr/bin/sudo
+```
+
+### 3.4 预安装失败
+
+ 
+
+ 本问题先参考了链接[openGaussDB 初体验（上） - 云+社区 - 腾讯云 (tencent.com)](https://cloud.tencent.com/developer/article/1675265)以下内容，但是没有解决。
+
+ 
+
+ 我解决这个问题的过程是这样的：
+
+ 找到虚拟网络编辑器，电脑连了自己的热点（我听我同学说她的用校园网就不行），然后还原默认设置：
+
+
+
+
+
+ 然后配置了静态的ip地址，参考了[ CentOS 7 连接不到网络解决方法(设置静态ip)_gaokcl的博客-CSDN博客_centos7无法连接网络](https://blog.csdn.net/gaokcl/article/details/82834925?utm_medium=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-2.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-2.no_search_link)。但是神奇的是，这样就可以了。不过后来还是重装了。
+
+### 3.5 重装openGauss时端口被占用
+
+ 报错：[GAUSS-50601] : The port [15400] is occupied or the ip address is incorrectl，有两种方法：
+
+- 修改xml文件中的端口号
+- 杀掉占用端口的进程
+
+### 3.6 右上角网络连接图标消失
+
+ 参考了[centos7右上角网络连接图标消失_shuest的博客-CSDN博客_centos7右上角没有网络图标](https://blog.csdn.net/zs391077005/article/details/106885104?utm_medium=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-1.no_search_link&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2~default~CTRLIST~default-1.no_search_link)
+
+```
+chkconfig network off
+chkconfig network on
+service NetworkManager stop
+service NetworkManager start
+```
+
+ 但是有可能遇到后两条命令用不了，然后又去查怎么办，最后也没解决，我重装了。累了累了。
+
+### 3.7 循环显示登录界面无法进入
+
+ 看图吧，我最后又进安全模式解决的，最后修改/etc/selinux/config配置，将SELINUX选项由SELINUX=enforcing改成SELINUX=disabled，重启系统后发现就可以正常登陆系统了：
+
+
+
+### 3.8 Connection refused
+
+- 首先需要启动数据库，不启动数据库会出现如下错误：
+
+- 未设置服务端远程连接也会出现以上问题，见2.3.3
+
+ 
+
+### 3.9 加载驱动出现问题
+
+ 以下是开发流程：
+ 
+
+驱动需要按照2.3.1所说，放在指定文件夹下，不然在加载驱动的时候会出现问题。
+
+### 3.10 unreported exception SQLException
+
+ 在本地编译java服务的时候，编译报错：未报告的异常错误; 必须对其进行捕获或声明以便抛出。
+
+ 添加代码throw SQLException即可：
+
diff --git "a/content/zh/post/vector524/\345\215\216\344\270\272OpenGauss\346\225\260\346\215\256\345\272\223\350\241\214\345\255\230\345\202\250\346\272\220\344\273\243\347\240\201\350\247\243\346\236\220.md" "b/content/zh/post/vector524/\345\215\216\344\270\272OpenGauss\346\225\260\346\215\256\345\272\223\350\241\214\345\255\230\345\202\250\346\272\220\344\273\243\347\240\201\350\247\243\346\236\220.md"
new file mode 100644
index 0000000000000000000000000000000000000000..96461cdb5bb323b64df8470d809d2de44ea50efe
--- /dev/null
+++ "b/content/zh/post/vector524/\345\215\216\344\270\272OpenGauss\346\225\260\346\215\256\345\272\223\350\241\214\345\255\230\345\202\250\346\272\220\344\273\243\347\240\201\350\247\243\346\236\220.md"
@@ -0,0 +1,306 @@
++++
+
+title = "华为OpenGauss数据库行存储源代码解析"
+date = "2021-12-01"
+tags = ["华为OpenGauss数据库行存储源代码解析"]
+archives = "2021-12"
+author = "vector"
+summary = "华为OpenGauss数据库行存储源代码解析"
+times = "17:30"
+
++++
+
+# 华为OpenGauss数据库行存储源代码解析
+
+ 根据存储介质和并发控制机制，存储引擎分为磁盘引擎和内存引擎两大类。磁盘引擎主要面向通用的、大容量的业务场景，内存引擎主要面向容量可控的、追求极致性能的业务场景。在磁盘引擎中，为了满足不同业务场景对于数据不同的访问和使用模式，openGauss进一步提供了astore（append-store，追加写优化格式）、cstore（column store，列存储格式）以及可拓展的数据元组和数据页面组织格式。astore为行存储格式，向上提供元组形式的读、写。
+
+## 1. 数据库表的创建
+
+ 查找到了关于数据库创建表的内容：在opengauss数据库源码中位于`src\gausskernel\optimizer\commands\tablecmds.cpp`，DefineRelation此函数是最终创建表结构的函数，最主要的参数是CreateStmt这个结构，该结构如下：
+
+```c++
+typedef struct CreateStmt {
+ NodeTag type;
+ RangeVar *relation; /* relation to create */
+ List *tableElts; /* column definitions (list of ColumnDef) */
+ List *inhRelations; /* relations to inherit from (list of
+ * inhRelation) */
+ TypeName *ofTypename; /* OF typename */
+ List *constraints; /* constraints (list of Constraint nodes) */
+ List *options; /* options from WITH clause */
+ List *clusterKeys; /* partial cluster key for table */
+ OnCommitAction oncommit; /* what do we do at COMMIT? */
+ char *tablespacename; /* table space to use, or NULL */
+ bool if_not_exists; /* just do nothing if it already exists? */
+ bool ivm; /* incremental view maintenance is used by materialized view */
+ int8 row_compress; /* row compression flag */
+ PartitionState *partTableState; /* the PartitionState */
+#ifdef PGXC
+ DistributeBy *distributeby; /* distribution to use, or NULL */
+ PGXCSubCluster *subcluster; /* subcluster of table */
+#endif
+
+ List *tableEltsDup; /* Used for cstore constraint check */
+ char *internalData; /* Used for create table like */
+
+ List *uuids; /* list of uuid, used for create sequence(like 'create table t(a serial))' */
+ Oid oldBucket; /* bucketoid of resizing table */
+ List *oldNode; /* relfilenode of resizing table */
+ List *oldToastNode; /* toastnode of resizing table */
+ char relkind; /* type of object */
+} CreateStmt;
+```
+
+ 结构中relation中包含了catalogname,schemaname,relname此时的relname就能够顺利的拿到。`DefineRelation`函数中用到的函数的功能和执行流程如下（参考了postgre数据库的执行流程）：
+
+DefineRelation->
+
+| Permission check | 进行权限检査，确定当前用户是否有权限创建表。 |
+| ------------------------------ | ------------------------------------------------------------ |
+| transformRelOptions() | 对表创建语句中的WITH子句进行解析 |
+| heap_reloptions() | 调用heap_reloptions对参数进行合法性验证。 |
+| MergeAttributes() | 使用MergeAttributes，将继承的属性合并到表属性定义中。 |
+| BuildDescForRelation() | 调用BuildDescForRelation利用合并后的属性定义链表创建tupleDesc结构（这个结构用于描述元组各属性结构等信息）。 |
+| interpretOidsOption() | 决定是否使用系统属性OID (interpretOidsOption)。 |
+| CONSTR_DEFAULT or CONSTR_CHECK | 对属性定义链表中的每一个属性进行处理，査看是否有默认值、表达式或约束检査。 |
+| heap_create_with_catalog() | 使用heap_create_with_catalog创建表的物理文件并在相应的系统表中注册。 |
+| StoreCatalogInheritance() | 用StoreCataloglnheritance存储表的继承关系。 |
+| AddRelationNewConstraints() | 处理表中新增的约束与默认值 |
+| ObjectAddressSet() | |
+
+ 
+
+## 2. 页面组织和元组结构
+
+ astore的设计遵从段页式，存储结构以页面为单位，页面大小一般默认为8KB。
+
+### 2.1 页面组织结构
+
+
+
+ `\src\include\storage\buf\bufpage.h`
+
+```c++
+typedef struct {
+ PageXLogRecPtr pd_lsn; /* 页面最新一次修改的日志lsn */
+ uint16 pd_checksum; /* 页面CRC */
+ uint16 pd_flags; /* 标志位 */
+ LocationIndex pd_lower; /* 空闲位置开始出（距离页头） */
+ LocationIndex pd_upper; /* 空闲位置结尾处（距离页头） */
+ LocationIndex pd_special; /* 特殊位置起始处（距离页头） */
+ uint16 pd_pagesize_version;
+ ShortTransactionId pd_prune_xid;
+ TransactionId pd_xid_base;
+ TransactionId pd_multi_base;
+ ItemIdData pd_linp[FLEXIBLE_ARRAY_MEMBER];
+} HeapPageHeaderData;
+```
+
+1. pd_lsn：该页面最后一次修改操作的预写日志结束位置的下一个字节，用于检查点推进和保持恢复操作的幂等性（幂等指对接口的多次调用所产生的结果和调用一次是一致的）。
+2. pd_checksum：页面的CRC校验值。
+3. pd_flags：页面标记位，用于保存各类页面相关的辅助信息，如页面是否有空闲的元组指针、页面是否已满、页面元组是否都可见、页面是否被压缩、页面是否是批量导入的、页面是否加密、页面采用的CRC校验算法等。
+4. pd_lower：页面中间空洞的起始位置，即当前已使用的元组指针数组的尾部。
+5. pd_upper：页面中间空洞的结束位置，即下一个可以插入元组的起始位置。
+6. pd_special：页面尾部特殊区域的起始位置。该特殊位置位于第一条元组记录和页面结尾之间，用于存储一些变长的页面级元信息，如采用的压缩算法信息、索引的辅助信息等。
+7. pd_pagesize_version：页面的大小和版本号。
+8. pd_prune_xid：页面清理辅助事务号（32位），通常为该页面内现存最老的删除或更新操作的事务号，用于判断是否要触发页面级空闲空间整理。实际使用的64位prune事务号由“pd_prune_xid”字段和“pd_xid_base”字段相加得到。
+9. pd_xid_base：该页面内所有元组的基准事务号（64位）。该页面所有元组实际生效的64位xmin/xmax事务号由“pd_xid_base”（64位）和元组头部的“t_xmin/t_xmax”字段（32位）相加得到。
+10. pd_multi_base：类似“pd_xid_base”字段，当对元组加锁时，会将持锁的事务号写入元组中，该64位事务号由“pd_multi_base”字段（64位）和元组头部的“t_xmax”字段（32位）相加得到。
+11. pd_linp：元组指针变长数组。
+
+ 页面头部分对应HeapPageHeaderData结构体。其中，pd_multi_base以及之前的部分对应定长成员，存储了整个页面的重要元信息；pd_multi_base之后的部分对应元组指针变长数组，其每个数组成员存储了页面中从后往前的、每个元组的起始偏移和元组长度。如图所示，真正的元组内容从页面尾部开始插入，向页面头部扩展；相应的，记录每条元组的元组指针从页面头定长成员之后插入，往页面尾部扩展；整个页面中间形成一个空洞，供后续插入的元组和元组指针使用。
+ 对于一个一条具体元组，有一个全局唯一的逻辑地址，即元组头部的t_ctid，其由元组所在的页面号和页面内元组指针数组下标组成；该逻辑地址对应的物理地址，则由ctid和对应的元组指针成员共同给出。通过页面、对应元组指针数组成员、页面内偏移和元组长度的访问顺序，就可以完整获取到一条元组的完整内容。t_ctid结构体和元组指针结构体的定义代码如下。
+
+ `src\include\storage\item\itemid.h`
+
+```c++
+/* t_ctid结构体*/
+typedef struct ItemPointerData {
+ BlockIdData ip_blkid; /* 页号 */
+ OffsetNumber ip_posid; /* 页面偏移，即对应的页内元组指针下标 */
+} ItemPointerData;
+/* 页面内元组指针结构体 */
+typedef struct ItemIdData {
+ unsigned lp_off : 15, /* 元组起始位置（距离页头） */
+ lp_flags : 2, /* 元组指针状态 */
+ lp_len : 15; /* 元组长度 */
+} ItemIdData;
+```
+
+ 如上两级的元组访问设计，主要有两个优点。
+
+- 在索引结构中，只需要保存元组的t_ctid值即可，无须精确到具体字节偏移，从而降低了索引元组的大小（节约两个字节），提升索引查找效率；
+- 将页面内元组的地址查找关系自封闭在页面内部的元组指针数组中，和外部索引解耦，从而在某些场景下可以让页面级空闲空间整理对外部索引数据没有影响，降低空闲空间回收的开销和设计复杂度。
+
+### 2.2 元组数据部分结构
+
+
+
+ `src\include\access\htup.h`
+
+```
+typedef struct HeapTupleFields {
+ ShortTransactionId t_xmin; /* 插入元组事务的事务号 */
+ ShortTransactionId t_xmax; /* 删除元组事务的事务号 */
+ union {
+ CommandId t_cid; /* 插入或删除命令在事务中的命令号 */
+ ShortTransactionId t_xvac;
+ } t_field3;
+} HeapTupleFields;
+
+typedef struct HeapTupleHeaderData {
+ union {
+ HeapTupleFields t_heap;
+ DatumTupleFields t_datum;
+ } t_choice;
+ ItemPointerData t_ctid; /* 当前元组或更新后元组的行号 */
+ uint16 t_infomask2; /* 字段个数和标记位 */
+ uint16 t_infomask; /* 标记位 */
+ uint8 t_hoff; /* 包括NULL字段位图、对齐填充在内的元组头部大小 */
+ bits8 t_bits[FLEXIBLE_ARRAY_MEMBER]; /* NULL字段位图 */
+ /* 实际元组数据再该元组头部结构体之后，距离元组头部处偏移t_hoff字节 */
+} HeapTupleHeaderData;
+```
+
+下面是元组头部结构体定义：
+
+1. 插入元组的事务号
+2. t_xmax，如果元组还没有被删除，那么为零。
+3. t_cid，插入或删除元组的命令号。
+4. t_ctid，当前元组的页面和页面内元组指针下标。如果该元组被更新，为更新后元组的页面号和页面内元组指针下标。
+5. t_hoff，元组数据距离元组头部结构体起始位置的偏移。
+6. t_bits，所有字段的NULL空值bitmap。每个字段对应t_bits中的一个bit位，因此是变长数组。
+
+ 数据结构中并没有出现存储元组实际数据的属性，这是因为通过编程技巧，巧妙的将数组的实际数据存放在heapTupleHeaderData结构后面的空间。
+
+### 2.3 元组结构
+
+ 上述元组结构体在内存中使用时嵌入在一个更大的元组数据结构体中，该结构体的定义代码如下。除了保存元组内容的t_data成员之外，其他的成员保存了该元组的一些其他系统信息，这些信息构成了该元组剩余的一些系统字段内容：
+
+ `src\include\access\htup.h`
+
+```c++
+typedef struct HeapTupleData {
+ uint32 t_len; /* 包括元组头部和数据在内的元组总大小 */
+ ItemPointerData t_self; /* 元组行号 */
+ Oid t_tableOid; /* 元组所属表的OID */
+ TransactionId t_xid_base;
+ TransactionId t_multi_base;
+ HeapTupleHeader t_data; /* 指向元组头部 */
+} HeapTupleData;
+```
+
+ HeapTupleData是元组在内存中的拷贝，它是磁盘格式的元组读入内存后的存在方式。
+
+## 3. 元组的插入
+
+ 代码位于`src\gausskernel\storage\access\heap\heapam.cpp`
+
+插入元组之前，首先根据元组内数据和描述符等信息初始化HeapTuple结构，函数heap_form_tuple实现了这一功能，函数如下：
+
+```c++
+HeapTuple heap_form_tuple(TupleDesc tupleDescriptor, Datum *values, bool *isnull)
+```
+
+ 其中，values参数是将要插入的元组的各属性数组，isnull数组用于标识哪些属性为空值。heap_form_tuple根据values和isnull数组调用函数`tableam_tops_computedatasize_tuple`，计算形成元组所需要的内存大小，然后为元组分配足够的空间。
+
+
+
+
+
+ 在进行必要的头部设置后，调用函数`tableam_heap_fill_tuple`向元组中填充实际数据。
+
+ 
+
+当完成元组在内存的构成后，下一步就可以准备向表中插入元组了，插入元组的接口为`tableam_heap_insert`，但最终真正起作用的是使用heap_insert函数向表中插入元组。heap_insert的作用流程如下：
+
+
+
+1. 首先我们会为新插入的元组（tup）调用newoid函数为其分配一个OID。
+
+2. 初始化tup，包括设置t_xmin和t_cmin为当前事务ID和当前命令ID、将t_xmax置为无效、设置tableOid（包含此元组的表的OID）。
+
+3. 找到属于该表且空闲空间（freespace）大于newtup的文件块，将其载入缓冲区以用来插入tup（调用函数RelationGetBufferForTuple）。
+
+4. 有了插入的元组tup和存放元组的缓冲区后，就会调用RelationPutHeapTuple函数将新元组插入至选中的缓冲区。
+
+5. 向事务日志（XLog）写入一条XLog。
+
+6. 当完成上述过程后，将缓冲区解锁并释放，并返回插入元组的OID。
+
+ 流程如下：
+
+ 
+
+## 4. 元组的删除
+
+ `src\gausskernel\storage\access\heap\heapam.cpp`
+
+```c++
+TM_Result heap_delete(Relation relation, ItemPointer tid, CommandId cid,
+ Snapshot crosscheck, bool wait, TM_FailureData *tmfd, bool allow_delete_self)
+```
+
+ 这是删除一个元组的详细流程，使用heap_delete完成，这是我看的有关postgre删除元组流程，在刚刚删除元组流程图上多出来一步，就是判断是否则正在被当前事务修改，如果是要将元组的ctid指向被修改后的元组物理位置，然后对缓冲区解锁释放，
+ 删除元组主要调用函数heap_delete来实现，其主要流程如下:
+
+1. 根据要删除的元组tid得到相关的缓冲区，并对其加排他锁。
+
+2. 调用HeapTupleSatisfiesUpdate函数检查元组对当前事务的可见性。如果元组对当前事务是不可见的（HeapTupleSatisfiesUpdate函数返回HeapTupleInvisible），那么对缓冲区解锁并释放，再返回错误信息。
+
+3. 如果元组正在被本事务修改（HeapTupleSatisfiesUpdate函数返回HeapTupleSelfUpdated）或已经修改（HeapTupleSatisfiesUpdate函数返回HeapTupleUpdated），则将元组的ctid字段指向被修改后的元组物理位置，并对缓冲区解锁、释放，再分别返回HeapTupleSelfUpdated和HeapTupleUpdated信息。
+
+ 
+
+4. 如果元组正在被其他事务修改（HeapTupleSatisfiesUpdate函数返回HeapTupleBeingUpdated），那么将等待该事务结束再检测。如果事务可以修改（HeapTupleSatisfiesUpdate函数返回HeapTupleMayBeUpdated），那么heap_delete会继续向下执行。
+
+5. 设置t_max为当前事务ID。到此为止该元组已经被标记删除，或者可以说该元组已经被删除了。
+
+6. 记录XLog。
+
+7. 如果此元组存在线外数据，即经过TOAST（过长字段存储技术）的数据，那么还需要将其TOAST表中对应的数据删除。调用函数toast_delete完成相关工作。
+
+8. 如果是系统表元组，则发送无效消息。
+
+9. 设置FSM表中该元组所处文件块的空闲空间值。
+
+ 
+
+
+
+## 5. 多版本元组机制
+
+ `src\gausskernel\storage\access\heap\heapam.cpp`
+
+```c++
+TM_Result heap_update(Relation relation, Relation parentRelation, ItemPointer otid, HeapTuple newtup,
+ CommandId cid, Snapshot crosscheck, bool wait, TM_FailureData *tmfd, bool allow_update_self)
+```
+
+ 下面是对元组的修改，因为opengauss是进行更新元组是不是就地修改，所以会存在一个页面会存在元组的多个版本。
+多版本元组机制，即为同一条记录保留多个历史版本的物理元组以解决对同一条记录的读、写并发冲突（读事务和写事务工作在不同版本的物理元组上）。下面是举例插入一个元组之后，两次进行更新:
+
+
+
+
+
+1. 首先事务号为10的事务插入一条值为value1的新记录。对应的页面修改为：在0号物理页面的第一个元组指针指向位置，插入一条“xmin”字段为10、“xmax”字段为0、“ctid”字段为（0，1）、“data”字段为value1的物理元组。该事务提交，将CSN从3推进到4，并且在CSN日志中对应事务号10的槽位处记下该CSN的值。
+2. 然后事务号为12的事务将上面这条记录的值从value1修改为value2。对应的页面修改为：在0号物理页面的第二个元组指针指向位置，插入另一条“xmin”字段为12、“xmax”字段为0、“ctid”字段为（0，2）、“data”为value2的物理元组。同时保留上面第一条插入的物理元组，但是将其“xmax”字段从0修改为12，将其“ctid”字段修改为（0，2），即新版本元组的物理位置。该事务提交，将CSN从7推进到8，并且在CSN日志中对应事务号12的槽位处记下该CSN的值。
+3. 最后事务号为15的事务将上面这条记录的值从value2又修改为value3，对应的页面修改为：（假设0号页面已满）在1号物理页面的第一个元组指针指向位置，插入一条“xmin”字段为15、“xmax”字段为0、“ctid”字段为（1，1）、“data”字段为value3的物理元组；同时，保留上面第1、第2条插入的物理元组，但是将第2条物理元组的“xmax”字段从0修改为15，将其“ctid”字段修改为（1，1），即最新版本元组的物理位置。该事务提交，将CSN从9推进到10，并且在CSN日志中对应事务号15的槽位处记下该CSN的值。
+4. 对于并发的读事务，其在查询执行开始时，会获取当前的全局CSN值作为查询的快照CSN。对于上面同一条记录的3个版本的物理元组来说，该读查询操作只能看到同时满足如下两个条件的这个物理元组版本。
+ 元组“xmin”字段对应的CSN值小于等于读查询的快照CSN。
+ 元组“xmax”字段为0，或者元组“xmax”字段对应的CSN值大于读查询的快照CSN。
+
+ 那么如何知道应该读取哪一个版本的记录？ 与CSN有关，CSN是一个步长为1的自增长的全局变量，在事务提交阶段，获取该值，每个非只读事务在运行过程中会取得一个xid号，在事务提交时会推进CSN，同时会将当前CSN与事务的xid映射关系保存起来（CSNLOG）。
+对于上面同一条记录的3个版本的物理元组来说，该读查询操作只能看到同时满足如下两个条件的这个物理元组版本。
+
+- 元组“xmin”字段对应的CSN值小于等于读查询的快照CSN。
+- 元组“xmax”字段为0，或者元组“xmax”字段对应的CSN值大于读查询的快照CSN。
+
+ 并发的读事务会根据自己的查询快照在同一个记录的多个历史版本元组中选择合适的那个来返回。并且即使是在可重复读的事务隔离级别下，只要使用相同的快照总可以筛选出相同的那个历史版本元组。在整个过程中读事务不阻塞任何对该记录的并发写操作（更新和删除）。
+可重复读的事务隔离级别，可能发生幻读：一个事务(同一个read view)在前后两次查询同一范围的时候，后一次查询看到了前一次查询没有看到的行。
+
+ 如下是更新元组的详细流程：
+
+
+
diff --git a/content/zh/post/wangrui/PowerDesigner_for_openGauss.md b/content/zh/post/wangrui/PowerDesigner_for_openGauss.md
new file mode 100644
index 0000000000000000000000000000000000000000..6ce0d62f7c195265fbd378e9d626990ec445cdf4
--- /dev/null
+++ b/content/zh/post/wangrui/PowerDesigner_for_openGauss.md
@@ -0,0 +1,92 @@
++++
+title = "PowerDesigner使用JDBC连接openGauss指导"
+date = "2021-03-16"
+tags = ["PowerDesigner使用JDBC连接openGauss指导"]
+archives = "2021-03-16"
+author = "wangrui"
+summary = "PowerDesigner使用JDBC连接openGauss指导"
+img = "/zh/post/xingchen/title/img1.png"
+times = "9:30"
++++
+
+
+
+# PowerDesigner简介
+
+
+PowerDesigner是Sybase的企业建模和设计解决方案，采用模型驱动方法，将业务与IT结合起来，可帮助部署有效的企业体系架构，并为研发生命周期管理提供强大的分析与设计技术。
+在部分业务场景下，没有数据库PDM文件，数据库中表之间的各种关系无法直观地看清楚，此时可以使用PowerDesigner进行逆向工程，从已有的数据库生成PDM文件。
+
+
+# 环境准备
+
+
+(1)下载并安装PowerDesigner 16.6版本，进入{PowerDesigner_insatll_dir}/Resource Files/DBMS，导入opengauss.xdb文件；
+
+[openGauss配置文件下载](../images/opengauss.xdb)
+
+(2)输入cmd命令“java –version”确认本地JDK版本在1.5以上，低于1.5需要在系统环境变量中配置JAVA_HOME和CLASSPATH；
+
+(3)进入openGauss官网https://opengauss.org/ ，下载对应的JDBC版本到本地；
+
+
+# PowerDesigner配置
+
+
+(1)打开PowerDesigner软件，“File”->“Reverse Engineer”->“Database…”
+
+
+
+(2)选择“General”页签，输入自定义Model name，在DBMS下拉框中选择数据库类型openGauss；
+
+
+
+(3)选择“Using a data source”，点击右侧按编辑数据库连接信息；
+
+
+
+(4)选择“Connection profile”，首次连接需点击“Configure”进行配置；
+
+
+
+(5)新增连接配置文件，配置项如下所示：
+Connection profile name: 配置文件名称
+Directory: 配置文件本地保存路径
+Description:配置文件描述，可根据实际用途填写
+Connection type：连接方式，此处选择JDBC
+DBMS type：数据库类型，提供大部分主流数据库选择，此处选择PostgreSQL
+User name：登录数据库的用户名，此处可以不填
+JDBC driver class：指定驱动类，使用默认的org.postgresql.Driver
+JDBC connection URL：连接URL，格式jdbc:postgresql://{host}:{port}/{database}
+JDBC driver jar files：指定jar包路径，点击右侧选择下载的opengauss驱动
+
+
+
+(6)点击左下方的“Test Connection”测试连接，注意需要在数据库服务端将客户端IP写入白名单，同时使用普通用户连接；
+
+
+
+(7)出现提示“Connection test successful”时，测试连接成功。
+
+
+# 常见问题
+
+
+(1)Non SQL Error : Could not load class com.postgresql.jdbc.Drive.
+错误原因：无法找到JDBC驱动；
+解决方法：可以在系统环境变量中配置CLASSPATH，将jar包路径写入，并重启PowerDesigner；
+
+
+
+(2)Fatal Error. Unable to initialize DatabaseMetaData class.
+错误原因：本地JAVA环境错误；
+解决方法：在任务管理器中查看PowerDesigner版本为32位，需要32位的JDK环境，重新安装32位JDK并重启PowerDesigner；
+
+
+
+(3)Connection to 90.90.52.60:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
+错误原因：数据库拒绝连接；
+解决方法：
+1、确认URL中IP和port是否填写正确；
+2、确认数据库监听地址是否正确；
+3、确认服务器防火墙是否关闭。
diff --git a/content/zh/post/wangrui/images/image001.jpg b/content/zh/post/wangrui/images/image001.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..90374efd2da76d9530654ae2b5313b82559c8481
Binary files /dev/null and b/content/zh/post/wangrui/images/image001.jpg differ
diff --git a/content/zh/post/wangrui/images/image002.jpg b/content/zh/post/wangrui/images/image002.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..b65e5852921076389dd025e2dadac26ec075b528
Binary files /dev/null and b/content/zh/post/wangrui/images/image002.jpg differ
diff --git a/content/zh/post/wangrui/images/image003.jpg b/content/zh/post/wangrui/images/image003.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7bc845f3956e212a3c9db0bfeaad5614d5f48491
Binary files /dev/null and b/content/zh/post/wangrui/images/image003.jpg differ
diff --git a/content/zh/post/wangrui/images/image004.jpg b/content/zh/post/wangrui/images/image004.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..9777b98ff6348020236814ad7ae1145f8fdb47e0
Binary files /dev/null and b/content/zh/post/wangrui/images/image004.jpg differ
diff --git a/content/zh/post/wangrui/images/image005.jpg b/content/zh/post/wangrui/images/image005.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..04541677aefb03706ab36bd98977eae60c90d7af
Binary files /dev/null and b/content/zh/post/wangrui/images/image005.jpg differ
diff --git a/content/zh/post/wangrui/images/image006.jpg b/content/zh/post/wangrui/images/image006.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..057a3496b1adca88885373e1a7f534114e6d100b
Binary files /dev/null and b/content/zh/post/wangrui/images/image006.jpg differ
diff --git a/content/zh/post/wangrui/images/image007.jpg b/content/zh/post/wangrui/images/image007.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..b957091aaabede1c6bb87d5245075283aa3de95e
Binary files /dev/null and b/content/zh/post/wangrui/images/image007.jpg differ
diff --git a/content/zh/post/wangrui/images/image008.jpg b/content/zh/post/wangrui/images/image008.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..c07d89a420b6380566a96943514dadda9d745afd
Binary files /dev/null and b/content/zh/post/wangrui/images/image008.jpg differ
diff --git a/content/zh/post/wangrui/images/image009.jpg b/content/zh/post/wangrui/images/image009.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..4b4dbf1369cb1e1a9ac8aaa63ef1238b0b3d3cef
Binary files /dev/null and b/content/zh/post/wangrui/images/image009.jpg differ
diff --git a/content/zh/post/wangrui/images/opengauss.xdb b/content/zh/post/wangrui/images/opengauss.xdb
new file mode 100644
index 0000000000000000000000000000000000000000..92f1e498f80955601a0a5ee76f0d69441a98840e
--- /dev/null
+++ b/content/zh/post/wangrui/images/opengauss.xdb
@@ -0,0 +1,4432 @@
+
+
+
+
+| gcc7.3 | +http://ftp.gnu.org/gnu/gcc/gcc-7.3.0/ | +
| gmp | +http://ftp.gnu.org/gnu/gmp/gmp-6.1.1.tar.xz | +
| mpc | +http://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz | +
| isl | +https://gcc.gnu.org/pub/gcc/infrastructure/isl-0.18.tar.bz2 | +
+下载链接：[https://opengauss.org/zh/download.html](http://) +2) 创建配置文件和解压缩安装包
+具体可参考openGauss安装流程: [https://gitee.com/opengauss/openGauss-server#%E5%AE%89%E8%A3%85）](http://) +3) 初始化安装环境：修改initdb配置参数(增加-c参数，使能dn创建paxosIndex信息文件)
+具体的修改文件: script/gspylib/component/Kernel/DN_OLAP/DN_OLAP.py；修改函数：initInstance(搜索关键字“gs_initdb”有两处match位置)
+修改示例： +```c{.line-num} +cmd = "%s/gs_initdb --locale=C -D %s -X %s --nodename=%s %s -c -C %s" +``` +4) 执行预安装和正式安装 +##### 2、使能DCF配置 +1) 进入到DN目录，通过修改postgresql.conf文件配置使能paxos dcf特性
+配置示例（在此以集群3节点配置为例, **注意：每个节点均需要修改** ）: +```c{.line-num} +#1. 使能dcf特性开关 +enable_dcf = on +#2. 当前节点id, 如果集群为3节点则每个节点可分别配置为1、2、3 +dcf_node_id = 1 +#3. 指定dcf数据目录 +dcf_data_path = '/xxx/cluster/data1/dn1/dcf_data' +#4. 指定dcf集群配置信息，每个节点上dcf_config内容一致，其中配置的ip/端口专用于dcf节点间通信链路，注意与所有其他已使用的ip/端口不要配置冲突 +dcf_config = '[{"stream_id":1,"node_id":1,"ip":"x.x.x.21","port":xx,"role":"LEADER"},{"stream_id":1,"node_id":2,"ip":"x.x.x.22","port":xx,"role":"FOLLOWER"},{"stream_id":1,"node_id":3,"ip":"x.x.x.23","port":xx,"role":"FOLLOWER"}]' +``` +##### 3、集群DCF模式运行 +- 切换到用户角色，依次启动节点1/2/3： +```c{.line-num} +gaussdb -D /xxx/cluster/data1/dn1 -M standby & +``` +待集群多数派节点启动成功后，即可以paxos模式运行；
+通过：gs_om -t status --detail指令可查询节点状态信息； + +##### 4、（可选）集群故障模式恢复参考 +集群故障模式下，可通过以下少数派和重建流程来恢复集群paxos模式正常运行： +- 手动设置存活节点为少数派模式运行 +```c{.line-num} +gs_ctl setrunmode -D PATH -v 1 -x minority +``` +- 集群其他节点主动重建拉起 +```c{.line-num} +gs_ctl build -b full -Z single_node -D PATH +``` +- 存活节点重回多数派 +```c{.line-num} +gs_ctl setrunmode -D PATH -x normal +``` +至此，集群已经可以paxos多数派模式正常运行，对外提供服务了； +- 状态信息验证查询 +```c{.line-num} +gs_ctl query -D PATH +``` +通过该指令可以验证查询到本节点HA状态和Paxos复制状态相关信息。 \ No newline at end of file diff --git a/content/zh/post/yanghaiyan/title/.keep b/content/zh/post/yanghaiyan/title/.keep new file mode 100644 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git a/content/zh/post/yanghaiyan/title/img1.png b/content/zh/post/yanghaiyan/title/img1.png new file mode 100644 index 0000000000000000000000000000000000000000..480384c2637ed6569224a30e246ded6d2ce613b7 Binary files /dev/null and b/content/zh/post/yanghaiyan/title/img1.png differ diff --git "a/content/zh/post/yanzongshuai/openguass-NUMA\351\200\202\351\205\215\344\271\213\347\272\277\347\250\213\347\273\221\346\240\270.md" "b/content/zh/post/yanzongshuai/openguass-NUMA\351\200\202\351\205\215\344\271\213\347\272\277\347\250\213\347\273\221\346\240\270.md" new file mode 100644 index 0000000000000000000000000000000000000000..b88d7f3461685b99ab1e92e33900c16d4f7841aa --- /dev/null +++ "b/content/zh/post/yanzongshuai/openguass-NUMA\351\200\202\351\205\215\344\271\213\347\272\277\347\250\213\347\273\221\346\240\270.md" @@ -0,0 +1,135 @@ +title = "opengauss NUMA适配之线程绑核" + +date = "2021-06-29" + +tags = ["opengauss NUMA适配之线程绑核"] + +archives = "2021-06" + +author = "闫宗帅" + +summary = "opengauss NUMA适配之线程绑核构" + +img = "/zh/post/lihongda/title/title.png" + +times = "19:30" + ++++ + +# opengauss NUMA适配之线程绑核 + +## 1、多核NUMA结构 + +NUMA（Non-uniform memory access，非统一内存访问架构）出现前，CPU通过内存控制器访问内存，随着CPU核的增加，内存控制器成为评价。内存控制器一般拆分内存平均分配到各个node节点上，CPU访问本地内存速度快，跨片访问慢。NUMA距离定义为：NUMA node的处理器和内存块的物理距离。通过numactl工具可以查看到CPU访问的距离信息。 + +## 2、NUMA绑核优化思路 + +避免线程在运行中在不同核上漂移，从而引起访问NUMA远端内存。openGauss通过配置参数thread\_pool\_attr控制CPU绑核分配，该参数仅在enable\_thread\_pool打开后生效。参数分为3部分：’thread\_num,group\_num,cpubind\_info’。 + +其中thread\_num：线程池中线程总数，取值0-4096。0表示根据CPU核数量自动配置线程池中线程数。如果大于0，线程池中线程数等于该值 + +group\_num：线程池中线程分组个数。0-64。0表示根据NUMA组个数自动配置线程池中分组个数，否正为group\_num个数。 + +cpubind\_info：线程池是否绑核的配置参数。可以配置： + +1（nobind），线程不绑核 + +2（allbind），利用当前系统所有能查询到的CPU核做线程绑核； + +3 （nodebind:1,2），利用NUMA组1，2中CPU核进行绑核； + +4 （cpubind:0-30）,利用0-30号CPU核进行绑核。 + +默认值‘16，2，（nobind）’ + +为充分利用CPU，线程数略大于核数。因为可能由线程等待，此时切换大其他线程进行。 + +## 3、源码解析 + +**操作流程** + + + +- 在PostmasterMain中开始设置线程绑定动作 +- 如果设置enable\_thread\_pool，才会调用SetThreadPoolInfo函数 + 1. 首先InitCpuInfo将CPU信息结构m\_cpuInfo初始化 + 2. 判定是否已有CPU进行了绑定GetInstanceBind + 3. GetCpuAndNumaNum计算CPU个数及NUMA节点个数 + 4. ParseAttr函数解析thread\_pool\_attr字符串 + 5. GetSysCpuInfo函数获取CPU信息 + 6. SetGroupAndTreadNum设定组个数及每个组中线程数 + +- 在ServerLoop函数中接收用户端连接，并进行CPU绑定 + - 由函数g\_threadPoolControler-\>Init完成 + - 完成线程创建及CPU绑定的函数是TreadPoolGroup::Init完成 + + +**GetCpuAndNumaNum** + +通过lscpu命令来计算CPU核、NUMA个数。 + +``` +void ThreadPoolControler::GetCpuAndNumaNum() +{ + char buf[BUFSIZE]; + FILE* fp = NULL; + if ((fp = popen("lscpu", "r")) != NULL) { + while (fgets(buf, sizeof(buf), fp) != NULL) { + if (strncmp("CPU(s)", buf, strlen("CPU(s)")) == 0 && + strncmp("On-line CPU(s) list", buf, strlen("On-line CPU(s) list")) != 0 && + strncmp("NUMA node", buf, strlen("NUMA node")) != 0) { + char* loc = strchr(buf, ':'); + m_cpuInfo.totalCpuNum = pg_strtoint32(loc + 1); + } else if (strncmp("NUMA node(s)", buf, strlen("NUMA node(s)")) == 0) { + char* loc = strchr(buf, ':'); + m_cpuInfo.totalNumaNum = pg_strtoint32(loc + 1); + } + } + pclose(fp); + } +``` + +**GetSysCpuInfo** + +- 通过fp = popen\(“lscpu -b -e=cpu,node”, “r”\);执行lscpu命令获取cpuid和numaid +- 通过CPU\_ISSET判断CPU是否绑定，最后计算出活跃未绑定的CPU个数m\_cpuInfo.activeNumaNum + +**SetGroupAndThreadNum** + +- 进行线程绑定，默认情况下线程组个数2，每组里面线程个数16 +- ConstrainThreadNum限定线程池大小m\_maxPoolSize为min\(4096,max\_connection,\)，线程个数m\_threadNum = Min\(m\_threadNum, m\_maxPoolSize\); + +**ThreadPoolGroup::Init** + +``` +m_listener->StartUp();//开启一个新线程 +InitWorkerSentry(); +|-- AddWorker + |-- AttachThreadToNodeLevel:: pthread_setaffinity_np +CPU_SET(m_groupCpuArr[i], &m_nodeCpuSet);//循环将CPU加入CPU集合 +``` + +**NUMA优化相关函数** + +openGauss中所有numa相关函数都可以通过宏定义ifdef \_\_USE\_NUMA找到其定义及调用的地方。 + +``` +int numa_available(void)：NUMA的API是否可以在平台上正常使用 +int numa_max_node(void)：当前系统上最大NUMA节点号 +void * numa_alloc_onnode(size_t size,int node)：在一个指定NUMA节点分配内存 +void numa_free(void *start,size_t size)：释放起始地址指定的内存 +int numa_run_on_node(int node)：运行当前任务在指定NUMA节点上 +void numa_set_localalloc(void)：设置当前的任务内存分配策略为本地化分配 +void numa_set_preferred(int node)：为当前任务设置偏好NUMA节点 +void numa_set_interleave_mask(struct bitmask*nodemask)：在一系列numa节点上分配交叉内存 +int pthread_getaffinity_np(pthread_t thread,size_t cpusetsize，cpu_set_t *cpuset)：设置线程在某个CPU上运行。 +``` + +1. sched\_getaffinity和pthread\_getaffinity\_np都是绑核的函数。 +2. numa\_set\_preferred设置当前线程优先分配内的结点。内存分配器先尝试从这个结点上分配内存。如果这个结点没有足够的空间，它会尝试其他结点。 +3. numa\_set\_interleave\_mask函数可以让当前线程以交错（interleaving）方式分配内存。未来所有的内存，将会从掩码给定的结点上轮询（round robing）分配。numa\_all\_nodes将内存分配交错（interleaving）在所有的node上。numa\_no\_nodes将会关闭交错分配内存。numa\_get\_interleave\_mask函数返回当前的交错掩码。这可以将当前的内存分配策略保存到文件中，在策略修改后，再次恢复。 + +**参考** + +\}https://www.bilibili.com/video/BV1gD4y1o7qB?from=search&seid=11985947230954507904 + diff --git "a/content/zh/post/yushanXD/2021-12-11-OpenGauss\345\206\205\345\255\230\345\274\225\346\223\216\344\270\255\347\232\204\347\264\242\345\274\225.md" "b/content/zh/post/yushanXD/2021-12-11-OpenGauss\345\206\205\345\255\230\345\274\225\346\223\216\344\270\255\347\232\204\347\264\242\345\274\225.md" new file mode 100644 index 0000000000000000000000000000000000000000..f484ddd5202bd9a2aa082e1eaffe2686f5cb9428 --- /dev/null +++ "b/content/zh/post/yushanXD/2021-12-11-OpenGauss\345\206\205\345\255\230\345\274\225\346\223\216\344\270\255\347\232\204\347\264\242\345\274\225.md" @@ -0,0 +1,189 @@ +# OpenGauss内存引擎中的索引 + +## 一、索引 + +索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树， B+树和 Hash。 + +索引的作用就相当于目录的作用。打个比方: 我们在查字典的时候，如果没有目录，那我们就只能一页一页的去找我们需要查的那个字，速度很慢。如果有目录了，我们只需要先去目录里查找字的位置，然后直接翻到那一页就行了。 + + + +## 二、内存引擎 + +在OpenGauss中内存引擎全称为内存优化表（MOT）存储引擎。 + +内存引擎作为在openGauss中与传统基于磁盘的行存储、列存储并存的一种高性能存储引擎，基于全内存态数据存储，为openGauss提高了高吞吐的实时数据处理分析能力及极低的事务处理时延，在不同业务负载场景下可以达到其他引擎事务处理能力的3~10倍。内存引擎之所以有较强的事务处理能力，更多因为其全面利用内存中可以实现的无锁化的数据及其索引结构、高效的数据管控，基于NUMA架构的内存管控，优化的数据处理算法及事务管理机制。 + +MOT与基于磁盘的普通表并排创建。MOT的有效设计实现了几乎完全的SQL覆盖，并且支持完整的数据库功能集，如存储过程和自定义函数。通过完全存储在内存中的数据和索引、非统一内存访问感知（NUMA-aware）设计、消除锁和锁存争用的算法以及查询原生编译，MOT可提供更快的数据访问和更高效的事务执行。MOT有效的几乎无锁的设计和高度调优的实现，使其在多核服务器上实现了卓越的近线性吞吐量扩展。 + + + +图1 OpenGauss内存引擎架构图 + +## 三、Masstree + +### 1．概要 + +Trie 树和 B+ 树结合而成的并发算法——MassTree。 + +#### 1.1 因此首先介绍一下字典树(Trie树)。 + +Trie树，又叫字典树、前缀树（Prefix Tree）、单词查找树 或 键树，是一种多叉树结构。 + + + +图2 一棵Trie树，表示了关键字集合{“a”, “to”, “tea”, “ted”, “ten”, “i”, “in”, “inn”}。 + +***\*Trie树的基本性质：\**** + +1.根节点不包含字符，除根节点外的每一个子节点都包含一个字符。 + +2.从根节点到某一个节点，路径上经过的字符连接起来，为该节点对应的字符串。 + +3.每个节点的所有子节点包含的字符互不相同。 + +一般会在节点结构中设置一个标志，用来标记该结点处是否构成一个单词（关键字）。 + +#### 1.2然后再介绍一下B+树。 + + + +图3 B+树样例 + +B+树是B树的一种变种，有着比B-树更高的查询性能 + +***\*一个m阶的B+树具有如下几个特征：\**** + +1.有k个子树的中间节点包含有k个元素（B树中是k-1个元素），每个元素不保存数据，只用来索引，所有数据都保存在叶子节点。 + +2.所有的叶子结点中包含了全部元素的信息，及指向含这些元素记录的指针，且叶子结点本身依关键字的大小自小而大顺序链接。 + +3.所有的中间节点元素都同时存在于子节点，在子节点元素中是最大（或最小）元素。 + +从结构上来说，Mass Tree 是由一层或多层 B+ 树组成的 Trie 树。 + + + +图4 + +图4中，圆形代表内部节点（interior node，也就是 B+ 树的 branch node），矩形代表边缘节点（border node，也就是 B+ 树的 leaf node），五角星代表 value。border node 的 value 域可能存放的是数据，也可能存放的是下一层子树的根节点。 + +Masstree以键(key)的前缀作为索引，每k 个字节形成一层 B+ 树结构，在每层中处理键中这k 个 字 节 对 应 所 需 的INSERT/LOOKUP/ UPDATE/DELETE流程。图4为k=8的情况。 + +### 2．Masstree静态数据结构 + + + +图5 + +## 四、OpenGauss中基于Masstree的索引 + +下面所有提到的大部分文件位于 + +openGauss-server-master\openGauss-server-master\src\gausskernel\storage\mot\core\src\storage\index中 + +### 1．数据结构 + +对应文件位置： + +openGauss-server-master\openGauss-server-master\src\gausskernel\storage\mot\core\src\storage\index\Masstree + +OpenGauss中对应Masstree的索引类名为MasstreePrimaryIndex， + +继承Index超类。 + +类MasstreePrimaryIndex拥有图6中的成员属性。 + + + +图6 + +其超类Index拥有图7中的成员属性。 + + + +图7 + +### 2．并发控制 + +为了防止读线程读到中间状态，叶节点被设计成最多存放 15 个 key，引入了一个8字节64位的 permutation(uint64_t)，这个 permutation 被划分成16份，每份4位，其中1份代表当前节点的 key 数量，另外15份用于存放每个 key 在节点中实际位置的索引，key 的插入是顺序插入，之后只需要修改 permutation 来更新节点内 key 的索引信息，然后施加一个 release 语义，当读线程对这个节点的 permutation 施加 acquire 语义时，可以获取到完整的节点信息。 + +并发情况一般有两种竞争，OpenGauss采用一个32bit的version参数应对并发控制。 + + + +图8 + +write-write 竞争：同一时刻只有一个线程可以对当前节点进行写操作 + +read-write 竞争：开始前和读结束后都需要获取当前节点的最新 version，来判断在读过程中当前节点是否发生了写操作（插入或分裂），同时对节点的写操作都需要先修改 version，在插入 key 之前需要设置 inserting 标记，插入完成之后将 insert 的 vinsert + 1；在分裂之前需要设置 splitting 标记，分裂完成之后将 split 的 vsplit + 1。 + +### 3．查找操作 + + + +图9 + +首先，在开始读取节点之前，必须获得节点的 stable version，即 version 中的 inserting 和 splitting 位都为0。 + +其次，在下降之前，需要获取最新的 root，因为在开始下降前，根节点可能分裂了，导致其发生了改变。 + +最后，如果当前节点已经是叶节点，那么可以返回，否则需要进行下降，读取内部结点根据 key[x, x+8)(8字节) 获得下降节点之后，分为3种情况处理： + +1.节点在我们读取期间没有发生任何变化，我们可以安全地进行下降； + +2.节点发生了变化，而且是分裂，那么我们需要从根节点重新进行下降； + +3.节点发生了变化，但只是插入，只需要重新对当前节点进行下降。 + +### 4. 插入操作 + + + +图10 + +查找key，如果找到key则tree不做改变；如果没找到， + +1.先锁住应该持有待插入key的节点 + +2.将相应节点version修改为inserting + +3.将相应节点state修改为insert + +4.更新树结构，以满足约束 + +5.更新在叶节点中的key slice ，keylen， key suffix ，key vaule + +6.Add the key's location in permutation's back.在解锁节点并将密钥输入到排列中之后将在finish_insert(从lp.finish调用)中完成。 + + + +图11 OpenGauss内存引擎索引上插入操作代码部分 + + + +图12 + +在lp.finish传入第一个参数为1时，调用finish_insert，finish_insert函数中实现通过在permutation插入新增节点的index使得节点对外可见。 + +### 5．删除操作 + +这里只讨论逻辑删除。 + +逻辑删除和B+树的类似，但是并不对 key 少的节点进行合并，当节点 key 减少到0时，需要标记这个节点为 deleted，然后将其从父节点删除，同时如果是叶节点的话，还需要维护叶节点的双向连接。如果某棵子树为空的话也可以删除整棵子树。当其他线程发现节点处于 deleted 状态时，需要进行重试，因为这个节点逻辑上是不存在的。 + + + +图13 + +删除操作可能会遇到图13的情况，左边的线程根据 k1 定位到了位置 i，在读取 v1 之前这个节点发生了删除位于位置 i 的 k1，同时在位置 j 处插入 k2，如果 i 等于 j，可能导致左边的线程读取到 v2，为了解决这个问题，需要在索引 i 被删除后重新利用时增加节点的 vinsert 域。 + + + +图14 OpenGauss内存引擎索引上删除操作代码部分 + + + +图 15 lp.finish传入参数为-1时，调用finish_remove函数，通过在permutation中删除节点索引已达到逻辑删除作用 + + \ No newline at end of file diff --git "a/content/zh/post/yushanXD/2021-12-11-Opengauss\345\215\225\346\234\272\351\203\250\347\275\262.md" "b/content/zh/post/yushanXD/2021-12-11-Opengauss\345\215\225\346\234\272\351\203\250\347\275\262.md" new file mode 100644 index 0000000000000000000000000000000000000000..7162e339b20c09d04b805bc0edfda2443bbf87a5 --- /dev/null +++ "b/content/zh/post/yushanXD/2021-12-11-Opengauss\345\215\225\346\234\272\351\203\250\347\275\262.md" @@ -0,0 +1,411 @@ +Opengauss单机部署 + +[TOC] + + + +## 一、安装环境 + +### 1．操作系统：虚拟机VMware、CentOS7.9 + +### 2．环境设置： + +#### （1）虚拟机内存3G、磁盘100G + +#### （2）系统版本修改 + +一开始使用了centos8，无法安装，因此降低版本，选用7.9后依然存在一些问题，因此修改/etc/redhat-release文件中系统版本为CentOS Linux release 7.6(Core) + +#### （3）配置YUM源 + +##### ①删除系统自带yum源 + +```shell +rm -rf /etc/yum.repos.d/* +``` + +##### ②下载阿里云yum源 + +```shell +wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo +``` + +##### ③生成仓库缓存 + +```shell +yum makecache +``` + +#### （4）安装依赖包 + +```shell +1 yum install ‐y libaio‐devel flex bison ncurses‐devel glibc.devel patch lsb_release +2 yum install ‐y openssl* python3 +``` + +#### （5）关闭SELINUX和Firewall + +```shell +1 setenforce 0 +2 systemctl disable firewalld.service +3 systemctl stop firewalld.service +``` + +#### （6）关闭交换内存 + +```shell +swapoff -a +``` + +#### （7）关闭透明大页 + +```shell +1 vim /etc/rc.d/rc.local +2 if test ‐f /sys/kernel/mm/transparent_hugepage/enabled; +3 then +4 echo never > /sys/kernel/mm/transparent_hugepage/enabled +5 fi +6 if test ‐f /sys/kernel/mm/transparent_hugepage/defrag; +7 then +8 echo never > /sys/kernel/mm/transparent_hugepage/defrag +9 fi +``` + + （8）修改主机名 + +```shell +1 echo "node1" > /etc/hostname +2 echo “ 192.168.17.129 node1” >>/etc/hosts +``` + + + +## 二、安装详细步骤 + +### 1．Opengauss安装 + +#### （1）下载opengauss安装包及创建用户组和目录 + +```shell +1 groupadd dbgrp +2 useradd -g dbgrp -d /home/omm -m -s /bin/bash omm +3 echo "omm" | passwd -‐stdin omm +4 mkdir -p /opt/software/openGauss +5 chmod 755 -R /opt/software +6 chown -R omm:dbgrp /opt/software/openGauss + cd /opt/software/openGauss/ +7 wget https://opengauss.obs.cn-south-1.myhuaweicloud.com/2.0.0/x86/openGauss-2.0.0-CentOS-64bit-all.tar.gz +8 tar -zxvf openGauss-2.0.0-CentOS-64bit-all.tar.gz +9 tar -zxvf openGauss-2.0.0-CentOS-64bit-om.tar.gz +``` + +#### （2）单机xml配置文件 + +首先从如下地址复制文件至当前位置 + +```shell +cp script/gspylib/etc/conf/cluster_config_template.xml . +``` + +修改配置文件具体如下，配置文件中要注意配置一下几个参数：nodeNAMES、backips + +```xml + +
本文主要介绍openGauss中常见的索引结构，索引相关元数据，并结合代码重点讲解B-tree索引使用过程中的重要流程，希望对大家理解openGauss中的索引有所帮助。
+索引方法
+B-Tree索引
+B-tree索引适合比较查询和范围查询，当查询条件使用(>,=,<,>=,<=)时，可以使用B-tree索引。B-tree索引是PostgreSQL和OpenGauss的默认索引方式。
+
+
+图-1 B-tree索引结构
+B-tree索引页分为几种：meta-page、root-page、branch-page和leaf-page，如图-1所示。
+meta-page: B-tree索引的元数据页，主要存储B-tree索引的元数据信息，可以通过meta page找到root page信息。
+root-page：B-tree的根节点。
+branch-page：内部节点，B-tree中根节点和叶子节点外的其他节点。
+leaf-page：叶子节点，其中的ctid指向heap tuple，非叶子节点的ctid指向其子节点。
+安装pageinspect后，可以通过
+select * from bt_metap(‘tab_pkey’) 查看meta-page 信息
+select * from bt_page_stats(‘tab_pkey’,1) 查看索引页信息
+select * from bt_page_items(‘tab_pkey’,1) 查看页内tuple信息
+index page 结构如图-2所示，
+High-Key表示此page的右兄弟节点的最小值，由于page之间数据是有序的，当前page内所有key <= High-Key的值。对unique index而言，当前page内所有key < High-Key的值。
+每一层的最右侧节点，由于没有右兄弟节点，因此page内没有High-Key。
+Special Space为索引页特有，由于存储每个page左右两边page的页号，可通过Special Space找到左右page。
+
+
+图-2 B-tree索引页结构
+以上是行存引擎的B-tree索引结构，列存的B-tree索引整体结构上与行存相同。leaf-page上行存存储的是key到ctid的映射关系，行存可以直接ctid中的block number及offset找到heap tuple的位置。列存的ctid中记录的是（cu_id, offset），还需要再对应的CUDesc表中根据cu_id列的索引找到对应的CUDesc记录，打开对应的CU文件，根据offset找到数据。
+列存上的B-tree索引不支持创建表达式索引、部分索引和唯一索引。
+GiST索引
+GiST(Generalized Search Tree)也是一棵平衡树，B-tree和比较语义强关联，适用于（>、>=、=、<=、<）这五个操作符。但现代数据库中存储的一些数据，如地理位置、图像数据等这五个操作符可能没有实际意义，GiST索引允许定义规则来将数据分布到平衡树中，并允许定义方法来访问数据。例如，GiST索引可以定义一棵存储空间数据的R-Tree，支持相对位置运算符（如 位于左侧、右侧、包含等）。
+GiST屏蔽了数据库的内部工作机制，比如锁的机制和预写日志，使得实现新的GiST索引实例（或称作索引操作符类）的工作相对比较轻松。基于GiST架构的索引操作符类只需实现预定义的几个接口。
+GIN索引
+Generalized Inverted Tree倒排索引。主要用于多值类型，如数组、全文索引等。如果对应的TID的列表很小，可以和元素放在一个页面内（称为posting list）。如果TID列表很大，需要使用更高效的数据结构B-tree，这棵B-tree存储在单独的页面中（称为posting tree）。
+
+
+图-3 GIN索引结构
+行存表支持的索引类型：B-tree（缺省值）、GIN、GiST。列存表支持的索引类型：Psort（缺省值）、B-tree、GIN。
+索引相关系统表
+pg_am
+PG_AM系统表存储有关索引访问方法的信息。系统支持的每种索引访问方法都有一行。表中各个字段的含义可以参考官方文档：https://opengauss.org/zh/docs/2.0.0/docs/Developerguide/PG_AM.html
+pg_index
+PG_INDEX系统表存储索引的一部分信息，其他的信息大多数在PG_CLASS中。
+对于分区表的partition local index，除了在pg_index中有一行数据外，每个分区的索引信息存储在pg_partition中。
+表中具体字段含义参考官方文档：
+https://opengauss.org/zh/docs/2.0.0/docs/Developerguide/PG_INDEX.html
+其中indisvalid、indisready、indcheckxmin等字段会在后续内容详细介绍。
除了上述两张表外，索引使用流程中涉及的相关的系统表还有很多，如 pg_class、pg_attribute、pg_depend、pg_constraint等不一一介绍了，大家参考官方文档。
+索引使用流程
+创建索引
+创建索引入口函数
+DefineIndex
+-
+
- 创建索引相关参数检查及校验 +
- 调用index_create 完成索引创建主要工作。所有索引创建都需要调用index_create，通过入参决定是不是需要构建索引结构。有一些流程，如create index concurrently，或者 分区表的partition local index，在这一步实际只是创建索引相关元数据，构建索引结构在后续流程完成。非分区表的index、分区表的global index构建索引结构在这一步完成。 +
- 如果是创建分区表的partition local index ，遍历所有分区，逐个分区调用 partition_index_create 创建分区索引。 +
- 如果是create index concurrently，执行create index concurrently的流程。此流程中表上加的锁类型是ShareUpdateExclusiveLock，不会阻塞对表的read及DML操作，普通建索引流程加的锁类型是ShareLock，会阻塞DML操作。分区表不允许create index concurrently。 +
index_create
+-
+
- 参数检查及校验 +
- 创建 index tuple descriptor，tuple descriptor用于描述tuple的结构，index tuple descriptor中很多属性是从对应的表的tuple descriptor中拷贝过来的。最终relcache中索引的tuple descriptor很多信息来自这里创建的tuple descriptor。 ConstructTupleDescriptor +
- 为索引生成新的 OID。 GetNewRelFileNode +
- 将索引信息插入relcache中；在磁盘上创建索引文件，新建索引文件会记录WAL，新建索引时relfilenode设置为和OID相同；如果是concurrent create index或者创建分区表的partition local index，会跳过创建索引文件。heap_create +
- 插入 pg_class 、pg_attribute、pg_index、pg_constraint、pg_depend等系统表。 +
- 执行构建索引流程，非分区表的index，及分区表的global index会在这一步真正构建索引结构。分区表的partition local index，会跳过这一步；如果是create index concurrently，跳过这一步。 index_build +
- 在pg_object中记录索引创建时间。 +
index_build
+执行构建索引，在调用index_build之前，索引相关元数据已经插入，空的索引文件已经创建。index_build根据pg_am中ambuild指定的创建索引的处理函数，执行构建索引的流程。
+-
+
- 根据pg_am和索引类型找到构建索引对应的procedure，例如：btree索引的ambuild是btbuild、gin索引的ambuild是ginbuild。调用对应的处理函数。index_build_storage +
- 索引构建完成后，如果构建过程中不是hot safe的，需要将pg_index中索引的indcheckxmin设置为true。设置indcheckxmin的目的是告诉其他事务，本索引可能是unsafe的。对应的事务在生成执行计划的收，如果发现索引的indcheckxmin标记为true，则需要比较创建索引的事务和当前事务的先后顺序，决定是否能使用索引。 +
- 更新 pg_class 中表和索引相关字段，如表中是否有索引的字段relhasindex设置为true，relallvisible 设置为true。 +
btbuild
+不同类型的索引，对应的建索引的处理函数不同。btbuild是B-tree索引对应的处理函数。
+-
+
- 构建一个BTBuildState对象，用于btbuild。BTBuildState中包含两个BTSpool对象指针，用于将heap tuple加载到内存中，以及heap tuple的排序。BTSpool中包含一个Tuplesortstate 类型的指针，Tuplesortstate 中用于记录tuple sort过程中的状态，维护tuple sort所需的内存空间/磁盘空间。 +
- 执行heap scan。如果是普通建索引，需要读取所有heap tuple（SNAPSHOT_ANY），然后判断heap tuple是否需要被索引。如果是create index concurrently 基于MVCC snapshot读取heap tuple（SNAPSHOT_MVCC），每个读取出来的heap tuple抽取出索引需要的列信息。 对于heap-only-tuple，index tuple中的tid指向hot-chain的root。IndexBuildHeapScan ? GlobalIndexBuildHeapScan +
- 对扫描出的heap tuple进行排序；基于排完序的index tuple，构建完整的B-tree索引。_bt_leafbuild +
_bt_leafbuid
+-
+
- 对index tuple进行排序。tuplesort_performsort +
- 基于排完序的index tuple，构建完整的B-tree索引。_bt_load +
_bt_load
+-
+
- 遍历所有排好序的index tuple，逐个调用_bt_buildadd加入到B-tree page中。B-tree从叶子节点开始构建，每一层从左向右构建。如果page写满了会触发下盘，同时创建同层右侧page；如果上层父page不存在，还会创建父page；如果已经存在父page，则将本page 的minkey 和 页号插入父节点。插入父节点的过程和插入子节点类似，可能触发父节点下盘等动作。index page会在special space记录左右两侧page的页号。每个page都会记WAL。
+
+
+
+图-4 B-tree索引页构建
+-
+
- 由于构建B-tree的过程是自左向右、自底向上，触发page下盘是page写满时，所以所有index tuple遍历完后，每一层的最右侧page可能还没有下盘及加入父节点。因此所有index tuple遍历完成后，还需要对每一层的最右侧节点做一次处理。每一层的最右侧节点没有HK，所以最终所有的ItemPointer需要向左移动一个位置。 B-tree索引构建完成后，还需要构建meta-page，所有page都会写WAL，在流程结束前会主动调一次fsync，让WAL下盘。 _bt_uppershutdown
+
+
+
+图-5 B-tree索引每层最右侧page结构
+partition_index_create
+用于创建分区表的partition local index。创建分区表的partition local index时，先获取分区信息，然后遍历每一个分区执行partition_index_create。
+-
+
- 为partition local index生成新的OID +
- 向partcache中插入索引相关信息，创建partition local index索引文件，记录WAL。 heapCreatePartition +
- 在pg_partition中插入partition local index相关信息。insertPartitionEntry +
- 执行索引构建。index_build +
- 更新pg_class中表和索引信息。 +
create index concurrently
+用于在不阻塞DML操作的情况下创建索引。
+Phase 1
+-
+
- 开启事务 tx1 +
- 插入relcache，插入索引相关元数据pg_class… ，和普通建索引相同，只是其中 pg_index 的 indisvalid、indisready 设置为false +
- 在表上 加一个 session-level ShareUpdateExclusiveLock，加锁目的是防止在建索引的流程中表和索引元数据被其他流程修改 +
- 提交事务 tx1。tx1 提交后，新开启的事务将会看到索引信息，索引状态为不可读(indisvalid = false)、不可写(indisready = false)，看到索引元数据的事务在插入数据时会考虑HOT-safe。
+Phase 2
+ - 开启事务 tx2 +
- 等待当前在执行的DML事务结束。具体实现是：找出当前所有持有的锁与ShareLock冲突的事务ID，等待这些事务提交或者Abort 。这一步等待的目的是什么？ 举例：表有两列{id, name}，数据如图-6所示，在id字段建索引。在Phase 1结束前开始的事务tx，无法看到索引元数据，所以在更新数据时做HOT update；Case1：由于流程中没有等待事务结束，建索引流程扫描heap tuple时，对应的heap tuple 为{id：3，name: ‘dd’}，index中对应的key是3，tx在索引扫描完后更新{id：3，name: ‘dd’} 这行数据为 {id：4，name: ‘dd’}，因此索引中的数据实际是错误的。普通建索引流程，因为阻塞DML操作，因此不会出现该问题。 Case2： 如果 tx是一个在Phase 1之后开启的事务，由于索引元数据可见，update操作发现对应的列上有索引，在更新数据时不会知道这不是一个HOT update，此时因为建索引和update的执行顺序，也会出现索引数据遗漏，索引数据如图-7所示。 由于现在索引本身还是一个中间状态，对读写操作都不可见，所以这里数据有偏差不是什么大问题，只需要最终索引数据正确即可。Case2索引数据出现的遗漏，会在Phase 3中补全；而Case1出现的错误不会被修复，因为一条hot-chain上的所有tuple只会有一个index entry。
+
+
+
+图-6 不等待Phase 1之前的DML结束导致的索引数据错误
+
+
+图-7 不等待Phase 1之后的DML结束导致的索引数据遗漏
+-
+
- 获取快照 snapshot1 +
- 扫描表中的所有可见元组，构建索引 +
- 设置索引的 indisready 为 true（索引对写操作可见） +
- 提交 tx2。tx2提交后新开启的事务更新数据时，会同时更新索引。
+Phase 3
+ - 开启事务 tx3 +
- 等待当前在执行的DML事务结束。这里时为了等待Phase 2结束前开始的事务，这些事务看不到索引indisready = true，在更新数据时没有更新索引。 +
- 获取快照 snapshot2 +
- 为Phase2开始后没有更新索引的DML操作执行索引更新。 validate_index +
- 记录 snapshot2’s 中的xmin +
- 提交事务 tx3
+Phase 4
+ - 开启事务 tx4 +
- 等待Phase 3之前开启的事务结束，这些事务可能持有一个比较老的snapshot，如果不等待这些事务结束就将索引的indisvalid 设置为true，这些事务可能出现读不一致的情况。如图-8所示，事务 txA 在Phase 3之前开启，读取数据r1，紧接着 txB delete r1；Phase 3中tx3 执行建索引时，由于对应的数据删除了，因此索引中没有r1的记录，tx3提交后索引的indisvalid设置为true，索引读可见，t’xA第二次读数据时使用索引，发现没有对应的数据，出现数据读一致的情况。为防止这种情况，需要在把索引的indisvalid设置为true之前，等待这些事务结束。
+
+
+
+图-8 等待读事务结束
+-
+
- 将索引的indisvalid 设置为true +
- 提交 tx4 +
删除索引
+和创建索引类似，删除索引也有concurrent和非concurrent两种方式，对应的加锁类型分别是ShareUpdateExclusiveLock和AccessExclusiveLock。
+index_drop
+concurrently
+-
+
- 开启事务 tx1 +
- 索引indisvalid设置为false，记WAL。index_set_state_flags(indexId, INDEX_DROP_CLEAR_VALID) +
- 表的relcache失效，表和索引上加会话级别的ShareUpdateExclusiveLock，防止流程执行期间，其他流程修改元数据，例如 drop table +
- 提交事务 tx1。tx1提交后，新的事务查询不会使用该索引。 +
- 开启事务tx2 +
- 等待所有的事务结束，有一些事务在tx1提交前已经开启，要确保没有事务查询使用该索引，需要等这些事务结束。 +
- 设置索引的indisready为false，indisvalid为true ? 有疑问，表的relcache失效 +
- 提交事务tx2 +
- 开启事务tx3 +
- 等待所有的事务结束，有一些事务在tx2提交前已经开启，要确保没有事务更新该索引，需要等这些事务结束。 +
- 表加ShareUpdateExclusiveLock，索引上加AccessExclusiveLock，为删除索引文件做准备 +
- 删除索引文件 +
- 删除pg_index中索引数据，删除pg_class、pg_attribute中索引相关数据，刷新缓存 +
- 释放会话级ShareUpdateExclusiveLock +
非concurrent删除索引流程上更简单一些，在表和索引上加AccessExclusiveLock，删除索引文件和相关元数据，刷新缓存。
+限于篇幅，索引相关其他内容，如重建索引，索引插入，索引的读写并发等内容下次再补充。