diff --git a/app/zh/blogs/wangshifei/.keep b/app/zh/blogs/wangshifei/.keep new file mode 100644 index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 diff --git a/app/zh/blogs/wangshifei/20241102.assets/image-20241104164958909.png b/app/zh/blogs/wangshifei/20241102.assets/image-20241104164958909.png new file mode 100644 index 0000000000000000000000000000000000000000..d41b8fb02d37474ea1f889b95e0daaeff919d997 Binary files /dev/null and b/app/zh/blogs/wangshifei/20241102.assets/image-20241104164958909.png differ diff --git a/app/zh/blogs/wangshifei/20241102.assets/image-20241104170751474.png b/app/zh/blogs/wangshifei/20241102.assets/image-20241104170751474.png new file mode 100644 index 0000000000000000000000000000000000000000..e394d06fd9d03fcfae69f0efa34e593e8b1d24b8 Binary files /dev/null and b/app/zh/blogs/wangshifei/20241102.assets/image-20241104170751474.png differ diff --git a/app/zh/blogs/wangshifei/20241102.assets/image-20241104170854961.png b/app/zh/blogs/wangshifei/20241102.assets/image-20241104170854961.png new file mode 100644 index 0000000000000000000000000000000000000000..7a5e24db01de9a908cce68e1aaf06a60ff210203 Binary files /dev/null and b/app/zh/blogs/wangshifei/20241102.assets/image-20241104170854961.png differ diff --git "a/app/zh/blogs/wangshifei/DBeaver\350\277\234\347\250\213\350\277\236\346\216\245openGauss\346\225\260\346\215\256\345\272\223\346\212\245\351\224\231\346\261\207\346\200\273" "b/app/zh/blogs/wangshifei/DBeaver\350\277\234\347\250\213\350\277\236\346\216\245openGauss\346\225\260\346\215\256\345\272\223\346\212\245\351\224\231\346\261\207\346\200\273" new file mode 100644 index 0000000000000000000000000000000000000000..a29c7a942adf5a0c48f68a124a80c85fe709dc3e --- /dev/null +++ "b/app/zh/blogs/wangshifei/DBeaver\350\277\234\347\250\213\350\277\236\346\216\245openGauss\346\225\260\346\215\256\345\272\223\346\212\245\351\224\231\346\261\207\346\200\273" @@ -0,0 +1,125 @@ +--- +title: '【第七届openGauss技术文章征集】DBeaver远程连接openGauss数据库报错汇总' +date: '2024-10-15' +category: 'blog' +tags: ['openGauss'] +archives: '2024-04' +author: '墨竹' +summary: 'Just about everything you'll need to style in the theme：headings, paragraphs, blockquotes, tables, code blocks, and more.' +--- + +# DBeaver远程连接openGauss数据库报错汇总 + +在openGauss 6.0.0版本正式上线后，在上手练习的过程就遇到Invalid username/password问题解决过程就用不少的时间来解决问题。因此就产生想按照PG配置习惯配置参数文件，看看会遇到哪些问题，顺便也整理测试过程中遇到的各种连接报错，以供初学者参考。 + +## Connection refused: connect + +``` +Connection to 192.168.181.20:15400 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. + Connection refused: connect +``` + +当客户端提示该报错，我们可以通过三个方向进行排查 + +1、查看防火墙状态，看是否关闭 + +2、查看客户端的IP、端口填写是否正确 + +3、查看postgresql.conf文件中listen_addresses是否配置 + +如果参数是已经注释的，可以取消注释并配置*或者主机IP；如果已经配置参数，则需要检查配置的IP是否正确 + +``` +--主机IP +listen_addresses = '192.168.181.20' +或 +listen_addresses = '*' +``` + +## The connection attempt failed + +``` +The connection attempt failed. + Connection reset +``` + +当客户端提示该报错，我们应该通过以下几点进行排查 + +1、pg_hba.conf中是否新增认证规则 + +2、pg_hba.conf中ADDRESS参数对应的IP和子网验证是否正确 + +``` +--这里的IP和子网掩码，如果设置的时候也需要注意。当子网掩码的位数为32时，IP需要设置为固定的IP。假如不小心设置为192.168.181.0/32就会报如上的错误。 +host all all 192.168.181.1/32 sha256 +--对于测试环境我们访问不做控制我们可以设置为 +host all all 0.0.0.0/0 sha256 +--也可以对整个网段进行设置 +host all all 192.168.181.0/24 sha256 +``` + +3、可能是参数配置后未生效导致，重启或者执行select pg_reload_conf()命令 + +## Invalid username/password + +``` +[192.168.181.1:62786/192.168.181.20:15400] FATAL: Invalid username/password,login denied. +``` + +当客户端报错提示Invalid username/password时，目前遇到的该问题有两种场景，分别是密码不正确和认证加密方式不一致。 + +### 密码不正确 + +这种情况应该是我们遇到该问题的时候，首先应该检查输入是否正确。如果在不确认密码是否正确的时候，建议可以先修改密码，然后再测试是否可以正确连接数据库。 + +``` +alter user test identified by 'openGauss@2024'; +``` + +### 认证加密方式配置是否正确 + +先查看openGauss数据库的参数password_encryption_type的值。 + +``` +show password_encryption_type; +``` + +在未修改数据库中该参数的时候，该参数默认为2，即表示采用sha256方式对密码加密。然后再查看pg_hba.conf中新增规则的METHOD参数，是否为sha256，如果参数文件中配置的是其他加密方式，比如md5，则有如下两种方法解决该问题 + +(1)、修改pg_hba.conf中加密方式为sha256 + +(2)、修改password_encryption_type的参数值为1或0，这个时候我们配置md5，其实也是可以适用。但是需要注意修改password_encryption_type参数的配置不会自动触发已有用户密码加密方式的修改，只会影响新创建用户或修改用户密码操作。所以我们需要在修改参数后并重启数据库使参数生效，然后还需要修改数据库用户口令。 + +``` +alter user test identified by 'openGauss@0430'; +``` + +该问题可以详细查看《DBeaver连接openGauss报错Invalid username/password问题排查》https://www.modb.pro/db/1784591381011976192文章中详细介绍。 + +## no pg_hba.conf entry for host + +``` +[192.168.181.1:64658/192.168.181.20:15400] FATAL: no pg_hba.conf entry for host "192.168.181.1", user "test", database "testdb", SSL off +``` + +当客户端提示该报错的时候，其实提示还是比较清晰的，检查一下pg_hba.conf中是否对数据库或用户做了限制。如果在配置文件中有对数据库和用户有限制，则检查配置是否正确或者是否新增对应访问控制规则。 + +## FATAL: database "testdb2" does not exist + +``` +[192.168.181.1:64924/192.168.181.20:15400] FATAL: database "testdb2" does not exist +``` + +这条信息说明尝试连接的数据库不存在，请检查连接的数据库名输入是否有误。 + +## Forbid remote connection with trust method! + +``` +[192.168.181.1:54091/192.168.181.20:15400] FATAL: Forbid remote connection with trust method! +``` + +采用这种认证模式时，openGauss只完全信任从服务器本机使用gsql且不指定-U参数的连接，此时不需要口令。设置文件系统权限只能Unix域套接字连接，它不会限制本地TCP/IP连接。为保证本地TCP/IP安全，**openGauss不允许远程连接使用trust认证方法** + +## 总结 + +上述报错都是最近测试并使用openGauss 6.0.0的过程遇到的问题，我也对这些报错逐个模拟并对解决办法进行详细的验证。同时受限于个人能力，给出的解决方法并不一定全面，请各位老师多多包涵。后续有其他新的问题或者同类型错误场景，再对文档进行补充完善。 \ No newline at end of file diff --git "a/app/zh/blogs/wangshifei/DBeaver\350\277\236\346\216\245openGauss\346\212\245\351\224\231Invalid username password\351\227\256\351\242\230\346\216\222\346\237\245" "b/app/zh/blogs/wangshifei/DBeaver\350\277\236\346\216\245openGauss\346\212\245\351\224\231Invalid username password\351\227\256\351\242\230\346\216\222\346\237\245" new file mode 100644 index 0000000000000000000000000000000000000000..3c95ef2f58756cfb5a3e44d065c99807da1e3b51 --- /dev/null +++ "b/app/zh/blogs/wangshifei/DBeaver\350\277\236\346\216\245openGauss\346\212\245\351\224\231Invalid username password\351\227\256\351\242\230\346\216\222\346\237\245" @@ -0,0 +1,95 @@ +--- +title: '【第七届openGauss技术文章征集】DBeaver连接openGauss报错Invalid username/password问题排查' +date: '2024-10-15' +category: 'blog' +tags: ['openGauss'] +archives: '2024-04' +author: '墨竹' +summary: 'Just about everything you'll need to style in the theme：headings, paragraphs, blockquotes, tables, code blocks, and more.' +--- +# DBeaver连接openGauss报错Invalid username/password问题排查 + +## 问题现象 + +最近openGauss6.0版本发布后，也想练练手。但是安装成功后，使用DBeaver连接数据库时报如下错误 + +``` +[192.168.181.1:62786/192.168.181.20:15400] FATAL: Invalid username/password,login denied. +``` +![20240428_152338.jpg](https://oss-emcsprod-public.modb.pro/image/editor/20240429-5a7bccdf-290f-49ce-81ef-ba6dedfa8af9.jpg) +## 问题定位与分析 + +当客户端报错提示Invalid username/password时，根据目前已有的经验，大概率是黑白名单pg_hba.conf的配置文件配置不正确或者输入的密码错误。 + +### 密码不正确 + +这种情况应该是我们遇到该问题的时候，首先应该检查输入是否正确。如果在不确认密码是否正确的时候，建议可以先修改密码，然后再测试是否可以正确连接数据库。 + +``` +alter user test identified by 'openGauss@2024'; +``` + +### 配置文件的问题 + +当我们在上一步确认密码正确的情况，我们可以在服务器端通过gsql指定用户名密码连接验证，看是否可以正常连接数据库。 + +``` +[omm@openGauss dn]$ gsql -d testdb -p 15400 -Utest -WopenGauss@2024 +gsql ((openGauss 6.0.0-RC1 build ed7f8e37) compiled at 2024-03-31 11:59:31 commit 0 last mr ) +Non-SSL connection (SSL connection is recommended when requiring high-security) +Type "help" for help. + +testdb=> \q +``` + +当服务器端可以正常连接，但是客户端通过DBeaver客户端连接的时候报Invalid username/password时，这个时候我们再来查看pg_hba.conf配置文件中新增的内容，前四项都没有任何的限制，目前只能猜测加密方式的问题。其实当时自己心里也没底，当时自己受PG的经验认知，openGauss是用PG的内核，应该也支持md5加密吧。通过查看openGauss的文档，password_encryption_type参数决定了采用何种加密方式对用户密码进行加密存储。默认值为2，即表示模式采用sha256方式对密码加密。这个时候我们再查看pg_hba.conf中参数配置项，发现新增的一条规则的METHOD，配置的是md5。再对METHOD参数修改为sha256后，客户端可以正常连接了。 + +``` +host all all 0.0.0.0/0 sha256 +``` + +## 问题处理 + +当我们知道该问题的原因，那么解决问题就相当容易了，总结来说可以通过如下两种方式解决 + +### 修改pg_hba.conf配置文件 + +修改pg_hba.conf中之前新增规则中的METHOD的参数值为sha256，保持和password_encryption_type默认加密类型一致 + +``` +host all all 0.0.0.0/0 sha256 +``` + +### 修改password_encryption_type参数配置 + +我们可以修改password_encryption_type的参数值为1或0，这个时候我们配置md5，其实也是可以适用。 + +按照这个思路，修改password_encryption_type参数为1或0，且启动数据库后，由于未修改加密方式pg_hba.conf的METHOD参数，仍然为md5，执行reload命令使参数生效。 + +``` +gs_guc reload -D /data/openGauss/install/data/dn -c "password_encryption_type=0" +``` + +但是在客户端测试连接的时候，仍然报Invalid username/password错误。刚开始以为是bug的，但是经过查看password_encryption_type的参数介绍，当修改改参数的配置不会自动触发已有用户密码加密方式的修改，只会影响新创建用户或修改用户密码操作。所以我们需要执行修改数据库用户命令，同时会有如下的提示。 + +``` +openGauss=# alter user test identified by 'openGauss@0428'; +NOTICE: The encrypted password contains MD5 ciphertext, which is not secure. +ALTER ROLE +``` + +当我们再次通过DBeaver连接数据库，可以正常使用。 + +## 问题总结 + +问题虽然解决了，但是回顾产生问题的原因，是由于自己根据PG对的pg_hba.conf规则配置的经验认为，以为两者相差不大，所以在未查阅文档的情况，按照经验配置为了md5。在这里只想说有时经验真的不靠谱啊！另外在最后，我们看一下password_encryption_type的详细介绍： + +**参数说明：**该字段决定采用何种加密方式对用户密码进行加密存储。修改此参数的配置不会自动触发已有用户密码加密方式的修改，只会影响新创建用户或修改用户密码操作。 + +**取值范围：**0、1、2、3 + +- 0表示采用md5方式对密码加密。 +- 1表示采用sha256和md5两种方式分别对密码加密。 +- 2表示采用sha256方式对密码加密。 +- 3表示采用sm3方式对密码加密 + diff --git "a/app/zh/blogs/wangshifei/openGauss\344\270\200\347\247\215\347\264\242\345\274\225\345\256\236\347\216\260\344\270\211\347\247\215\346\211\253\346\217\217\346\226\271\345\274\217\357\274\232\344\275\215\345\233\276\343\200\201\347\264\242\345\274\225\345\222\214\344\273\205\347\264\242\345\274\225" "b/app/zh/blogs/wangshifei/openGauss\344\270\200\347\247\215\347\264\242\345\274\225\345\256\236\347\216\260\344\270\211\347\247\215\346\211\253\346\217\217\346\226\271\345\274\217\357\274\232\344\275\215\345\233\276\343\200\201\347\264\242\345\274\225\345\222\214\344\273\205\347\264\242\345\274\225" new file mode 100644 index 0000000000000000000000000000000000000000..44682e2a10ebcacc44e4e811224b21c51865a752 --- /dev/null +++ "b/app/zh/blogs/wangshifei/openGauss\344\270\200\347\247\215\347\264\242\345\274\225\345\256\236\347\216\260\344\270\211\347\247\215\346\211\253\346\217\217\346\226\271\345\274\217\357\274\232\344\275\215\345\233\276\343\200\201\347\264\242\345\274\225\345\222\214\344\273\205\347\264\242\345\274\225" @@ -0,0 +1,298 @@ +--- +title: '【第八届openGauss技术文章征集】openGauss一种索引实现三种扫描方式：位图、索引和仅索引' +date: '2024-10-18' +category: 'blog' +tags: ['openGauss'] +archives: '2024-10' +author: '墨竹' +summary: 'Just about everything you'll need to style in the theme：headings, paragraphs, blockquotes, tables, code blocks, and more.' +--- +# openGauss一种索引实现三种扫描方式：位图、索引和仅索引 + +性能问题应该是我们日常运维过程中遇到最多的一类的问题，也是用户吐槽最多的问题之一，而解决性能问题最常见的方法就是为表创建合适的索引。索引可以节省大量数据访问时间以及引导查询以最快的方式获取结果，从而大幅度提升sql语句的查询性能。 + +在openGauss或者PG系列的数据库中，有不同的扫描方式可以利用索引来生成高效的执行计划。在这边文章中，我们将对openGauss的三种不同的索引扫描方式进行详细讲解，主要依据查询的表、查询检索的内容、使用的过滤器。三种不同的索引扫描类型： + +- 索引扫描 +- 仅索引扫描 +- 位图索引扫描 + +## 准备测试用例 + +在这里我们将使用只有一个单索引的表来演示，这样可以减少一些其他因素的影响，也会直观的感受到扫描方式又是受到什么样的过滤条件而改变。 + +先创建一个person的业务表 + +``` +create table person( + id serial primary key, + name text not null, + age integer not null, + email text not null, + register_date timestamp default now() not null, + is_active boolean DEFAULT true NOT NULL +); +``` + +然后使用SQL语句向表中插入100w行数据。 + +``` +INSERT INTO person(name,age,email,register_date,is_active) + SELECT md5(random()::text), + floor(random() * 99)::int, + md5(random()::text) || '@163.com', + now() - (random() * (interval '90 days')), + case when random() > 0.5 then true else false end +  FROM generate_series(1, 1000000); +``` + +## 创建索引 + +为了满足测试用例的要求，在这里我们需要添加一个复合索引，可以让我们看到不同的索引扫描方式。 + +``` +create index idx_person_age_date_active on person(age,register_date,is_active); +``` + +下面我们再来看一下，创建索引的三列的基数，即该列唯一键的数量。 + +age字段：我们使用random函数并通过floor函数限制了结果，使得结果的取值范围为[1,99] + +register_date字段：该字段的取值每行都不同，是这三个字段中值重复度最低的。 + +is_active字段：该列是布尔值，因此只能有true和false 两个不同的值 + +我们也可以通过查看数据库的pg_stats视图来验证索引列的基数。为了确保统计信息的准确性，我们需要对该表重新收集统计信息。 + +``` +ANALYZE person; +``` + +查看pg_stats视图 + +``` +SELECT tablename,attname AS column_name,n_distinct AS dist_val + FROM pg_stats + WHERE tablename = 'person' + AND attname IN ('age','register_date','is_active') + ORDER BY dist_val DESC; + tablename | column_name | dist_val +-----------+---------------+---------- + person | age | 99 + person | is_active | 2 + person | register_date | -1 +(3 rows) +``` + +针对n_distinct的字段，age列有99个不同的值，is_active有2个值，register_date列显示负值-1。 + +在通过查看openGauss的官网文档中对于pg_stats视图n_distinct列的解释： + +> -1表示一个唯一字段，独立数值的个数和行数相同 + +其实就可以理解为不同值的数量可能与总数量相同。 + +## 无索引-顺序扫描 + +我们先来看一下不带过滤条件的查询语句的执行计划 + +``` +test=# EXPLAIN ANALYZE SELECT * FROM person; + QUERY PLAN +------------------------------------------------------------------------------------------------------------------ + Seq Scan on person (cost=0.00..26394.00 rows=1000000 width=81) (actual time=0.010..86.210 rows=1000000 loops=1) + Total runtime: 123.725 ms +(2 rows) + +``` + +可以看到，由于需要从表中检索所有的数据，优化器决定使用顺序扫描方式，扫描了100W行，总耗时为123.725 ms + +## 位图索引扫描 + +### 使用索引 + +当查询需要访问大量的数据（可以利用批量读取（如顺序扫描）的优势）但又没有大到需要处理所有表数据时，优化器会选择位图索引扫描方式。位图索引扫描可以理解介于顺序扫描和索引扫描之间的方式，是一种折中处理的方式。 当我们看到执行计划使用了位图索引时，你会发现Bitmap Index Scan和Bitmap Heap Scan一般都是成对出现并配合使用，其中Bitmap Index Scan先在索引中查找符合条件的行并在内存中创建位图，而Bitmap Heap Scan使用该位图到表的数据文件中读取数据文件中的数据。 + +下面，我们来看看位图索引扫描的执行计划 + +``` +test=# EXPLAIN ANALYZE SELECT * FROM person where age =30; + QUERY PLAN + +------------------------------------------------------------------------------------------------------------------------ +--------------------- + Bitmap Heap Scan on person (cost=139.00..10860.76 rows=5000 width=81) (actual time=2.357..11.236 rows=10052 loops=1) + Recheck Cond: (age = 30) + Heap Blocks: exact=7502 + -> Bitmap Index Scan on idx_person_age_date_active (cost=0.00..137.75 rows=5000 width=0) (actual time=1.412..1.412 + rows=10052 loops=1) + Index Cond: (age = 30) + Total runtime: 11.839 ms +(6 rows) +``` + +在上述的执行计划中可知，首先使用了idx_person_age_date_active索引的位图索引扫描，把满足条件的行在内存中创建一个位图，并将其传递到父节点，即person表上的Bitmap Heap Scan路径，然后使用该位图到表中扫描，最后从表中读取完数据后仍需要重新检查一下过滤条件，并返回数据结果集。 + +### 未使用索引 + +我们再来看一下未使用索引时，执行计划是什么样的。需要禁用位图扫描参数. + +``` +set enable_bitmapscan =off; +``` + +下面，再次执行SQL语句 + +``` +test=# EXPLAIN ANALYZE SELECT * FROM person where age =30; + QUERY PLAN +-------------------------------------------------------------------------------------------------------------- + Seq Scan on person (cost=0.00..28894.00 rows=9600 width=91) (actual time=0.086..140.609 rows=10052 loops=1) + Filter: (age = 30) + Rows Removed by Filter: 989948 + Total runtime: 141.180 ms +(4 rows) + +``` + +从执行的结果中可知，使用位图索引扫描比顺序扫描，执行耗时上快了10倍多，cost降低1倍。也就是位图索引扫描利用批量读取有限数量的页面比直接顺序扫描执行速度更快，执行计划更优。 + +``` +--重置位图索引扫描参数 +reset enable_bitmapscan; +``` + +## 索引扫描 + +索引扫描的过程可以分成两步，第一步是从索引中获取行的物理位置，第二步是再到表的数据文件中读取相应的数据的过程，即从从堆或表页中读取数据。因此每次索引扫描访问都是两次读操作，但是该操作仍然是从表中检索数据的最有效的方式之一。当查询的行数较小时，优化器会选择这种扫描方式，因为索引扫描方式比顺序扫描读取数据有更低的cost且速度更快。 + +以下是索引扫描的执行计划 + +``` +test=# EXPLAIN ANALYZE SELECT * FROM person where age =8 and register_date ='2024-10-10 13:30:07.262557'::timestamp; + QUERY PLAN +------------------------------------------------------------------------------------------------------------------------------------- + [Bypass] + Index Scan using idx_person_age_date_active on person (cost=0.00..8.27 rows=1 width=91) (actual time=0.014..0.015 rows=1 loops=1) + Index Cond: ((age = 8) AND (register_date = '2024-10-10 13:30:07.262557'::timestamp without time zone)) + Total runtime: 0.160 ms +(4 rows) + +``` + +在上面的执行计划可知，本次使用的sql是在之前的sql的基础上，添加了一个过滤条件age =8 and register_date ='2024-10-10 13:30:07.262557'::timestamp。由于register_date是多列索引idx_person_age_date_active的一部分，且register_date重复度很高，因此基本就是从索引中一次读取就可以获取行位置，然后从该物理位置的表页中获取行数据，查询耗时0.160ms，速度是相当哇塞。 + +在上面的测试用例中，SQL语句中的register_date列使用了固定的时间戳值进行过滤，但是如果我们对register_date列使用范围过滤，结果集行数较少，优化器仍然会选择对多行进行索引扫描，就比如下面的测试用例。 + +``` +test=# EXPLAIN ANALYZE SELECT * FROM person where age =8 and register_date >'2024-10-10 10:00:00'::timestamp and register_date <'2024-10-10 11:00:00'::timestamp; + QUERY PLAN +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- + [Bypass] + Index Scan using idx_person_age_date_active on person (cost=0.00..24.36 rows=5 width=91) (actual time=0.015..0.023 rows=5 loops=1) + Index Cond: ((age = 8) AND (register_date > '2024-10-10 10:00:00'::timestamp without time zone) AND (register_date < '2024-10-10 11:00:00'::timestamp without time zone)) + Total runtime: 0.087 ms +(4 rows) + +Time: 0.901 ms + +``` + +从上面的执行计划看出，优化器估算的rows为5行，实际扫描的行数也是5行，尽管读取的数据行数增加，但是执行仍然很快，用时0.901ms。 + +## 仅索引扫描 + +### 仅索引扫描 + +仅索引扫描方式是对索引扫描方式的改进的一种方法。当SQl查询的数据都已经存在于索引中时，openGauss会使用该方法，通俗的讲就是SELECT和WHERE子句中的列或表达式应该是索引的一部分，因此索引扫描的第二步在这里就不需要了，仅从索引中读取数据返回结果。 + +下面，通过测试用例来说明一下 + +``` +test=# EXPLAIN ANALYZE SELECT age,register_date,is_active FROM person where age =8 and register_date ='2024-10-10 13:30:07.262557'::timestamp; + QUERY PLAN +------------------------------------------------------------------------------------------------------------------------------------------ + [Bypass] + Index Only Scan using idx_person_age_date_active on person (cost=0.00..8.27 rows=1 width=13) (actual time=0.055..0.056 rows=1 loops=1) + Index Cond: ((age = 8) AND (register_date = '2024-10-10 13:30:07.262557'::timestamp without time zone)) + Heap Fetches: 1 + Total runtime: 0.115 ms +(5 rows) +``` + +从上面的执行计划可以看出，EXPLAIN输出显示Index Only Scan，但是Heap Fetches的值为1，也就是准确扫描到数据块的个数是1。 + +>Heap Fetches表明需要扫描数据块的个数，虽然Index Only Scan 可以从索引直接输出结果，但是因为MVCC 机制的实现，需要对扫描的元组进行可见性判断，即检查visibility MAP 文件。当新建表之后，如果没有进行过vacuum和autovacuum操作，这时还没有VM文件，而索引并没有保存记录的版本信息，索引Index Only Scan 还是需要扫描数据块（Heap Fetches 代表需要扫描的数据块个数）来获取版本信息，这个时候可能会比Index Scan 慢。 + +执行一下vacuum操作 + +``` +vacuum; +``` + +再次执行查询语句 + +``` +test=# EXPLAIN ANALYZE SELECT age,register_date,is_active FROM person where age =8 and register_date ='2024-10-10 13:30:07.262557'::timestamp; + QUERY PLAN +------------------------------------------------------------------------------------------------------------------------------------------ + [Bypass] + Index Only Scan using idx_person_age_date_active on person (cost=0.00..4.27 rows=1 width=13) (actual time=0.013..0.014 rows=1 loops=1) + Index Cond: ((age = 8) AND (register_date = '2024-10-10 13:30:07.262557'::timestamp without time zone)) + Heap Fetches: 0 + Total runtime: 0.051 ms +(5 rows) +``` + +这一次，在执行计划中不止看到了Index Only Scan，而且Heap Fetches的值为0，也就是没有从表页中访问过数据块。时间相对比Index Scan还要好，只有0.051ms + +>执行计划中 Heap Fetches: 0 表示没有回表取数据， 存在2种情况： +>1）通过索引判断真的没有数据，所以不需要回表 +>2）通过索引判断真的有数据，再一次根据VM 判断，全部元祖是新的，所以从索引中就能获得最新的数据， 所以不需要回表 + +### 不合理的索引 + +如果对所有列建立索引，从而使的索引包含与表相同的所有数据，这应该是一种错误的认知也不是一个好的想法。如果是这种情况，将看不到使用索引的任何优势，优化器也将会选择顺序扫描方式。 + +下面，我们将在所有的列上建索引，然后观察sql的执行计划 + +``` +DROP INDEX idx_person_age_date_active; +CREATE INDEX idx_person_all ON person(id,name,age,email,register_date,is_active); +ANALYZE person; + +test=# EXPLAIN ANALYZE SELECT * FROM person where age =8 and register_date ='2024-10-10 13:30:07.262557'::timestamp; + QUERY PLAN +------------------------------------------------------------------------------------------------------- + Seq Scan on person (cost=0.00..31394.00 rows=1 width=91) (actual time=0.359..118.933 rows=1 loops=1) + Filter: ((age = 8) AND (register_date = '2024-10-10 13:30:07.262557'::timestamp without time zone)) + Rows Removed by Filter: 999999 + Total runtime: 119.077 ms +(4 rows) + +``` + +在上面的测试用例中，删除了之前新建的多列索引，并对所有列创建了一个新索引，然后执行ANALYZE刷新统计信息并执行查询语句。 + +在这里我们查询了所有的列，但是优化器选择了顺序扫描的方式，执行耗时为119.077ms。 + +## 总结 + +openGauss的优化器可以根据存储的数据和在查询过滤条件上使用单个索引的不同，可以产生不同的扫描方式。最后，我们大概最做一下总结。 + +1、在基数大的列上创建索引，在对该列进行查询过滤的时可以获得最佳的性能，但是如果在基数较低的列上创建索引会产生相反的效果，因为优化器大部分情况用不到该索引，而且还需要对该索引额为的维护。 + +2、当查询小结果集或精确查询时，索引扫描应该是最优的方法，可以快速的检索数据。 + +3、当查询需要访问大量的数据（可以利用批量读取（如顺序扫描）的优势）但又没有大到需要处理所有表数据时，优化器会选择位图索引扫描方式。 + +4、如果查询所需要的列且列很少，可以利用仅索引扫描方式可以避免从堆或表页中进行读取数据。另外，除了多列索引可以使得优化器选择Index Only Scan，还可以考虑使用索引覆盖，INCLUDE 子句指定将一些非键列（non-key columns）包含在索引中， 可以直接返回非键列中的内容，而不必去访问索引所对应的堆表。 + +## 参考 + +PostgreSQL修炼之道从小工到专家（第二版） + +https://www.modb.pro/db/449252 + +https://www.modb.pro/issue/18165 \ No newline at end of file diff --git "a/app/zh/blogs/wangshifei/\345\270\246\344\275\240\344\275\223\351\252\214\344\270\200\344\270\213openGauss6.0\345\205\250\351\223\276\350\267\257\350\267\237\350\270\252\350\203\275\345\212\233" "b/app/zh/blogs/wangshifei/\345\270\246\344\275\240\344\275\223\351\252\214\344\270\200\344\270\213openGauss6.0\345\205\250\351\223\276\350\267\257\350\267\237\350\270\252\350\203\275\345\212\233" new file mode 100644 index 0000000000000000000000000000000000000000..49b3e6576353bb31ba3e9d897cb512cca245dd87 --- /dev/null +++ "b/app/zh/blogs/wangshifei/\345\270\246\344\275\240\344\275\223\351\252\214\344\270\200\344\270\213openGauss6.0\345\205\250\351\223\276\350\267\257\350\267\237\350\270\252\350\203\275\345\212\233" @@ -0,0 +1,130 @@ +# 带你体验一下openGauss6.0全链路跟踪能力 + +在openGauss6.0版本中的可维护性中介绍全链路跟踪能力，主要是追踪并记录sql语句从客户端到数据库服务端网络耗时。这个功能主要是为了解决无法监控网络耗时，因为有些时候，当我们执行一个问题sql执行，有时会发现在服务器端执行没有问题，但是在客户端执行比较慢的问题。现在有全链路跟踪能力，就可以快速的知道一个sql的网络耗时，可以快速的定位sql性能是否与网络相关。 + +## 版本特性描述 + +可维护性：支持全链路跟踪能力 + +- 实现追踪并记录jdbc查询接口执行sql的端到端网络耗时，并记录在数据库dbe_perf.statement视图、statement_history表中。 + +## 支持条件 + +仅当**openGauss server版本和jdbc版本均大于6.0**时，才支持全链路跟踪能力。目前仅有jdbc版本的驱动。另外虽然该特性涉及与jdbc与数据库的交互能力，但是用户只需要在数据库内核设置enable_record_nettime参数是否开启该功能。 + +## enable_record_nettime说明 + +``` +参数说明：控制驱动全链路跟踪功能的开关，on为开，off为关。参数打开后将驱动执行的sql网络链路耗时记录在statement_history表中，通过dbe_perf.statement视图，standby_statement_history函数可以查询链路网络耗时net_trans_time，且wdr报告中TimeModel支持查看net_trans_time。当前仅支持6.0.0以上版本的JDBC驱动。 +该参数属于USERSET类型参数，请参考表1中对应设置方法进行设置。 +取值范围：布尔型 +默认值：off +``` + +## 网络链路耗时查询方式 + +可以查看dbe_perf.statement视图、statement_history表的net_trans_time字段来查看网络链路的耗时，单位是微妙。 + +``` +select query,net_trans_time,last_updated from dbe_perf.statement; +select query,start_time,finish_time,net_trans_time from statement_history; +``` + +## 准备测试用例表 + +在这里我们准备一个简单的测试用例表，来验证简单的增删改查。 + +``` +create table t1(id int primary key,name varchar(100),address varchar(100)); +insert into t1 values(1,'wang1','beijing'); +insert into t1 values(2,'wang2','beijing'); +insert into t1 values(3,'wang3','beijing'); +insert into t1 values(4,'wang4','beijing'); +``` + +## 查看enable_record_nettime默认的值 + +``` +openGauss=# show enable_record_nettime; + enable_record_nettime +----------------------- + off +(1 row) +``` + +## 开启全链路跟踪开关 + +可以使用guc命令来修改enable_record_nettime值为on，开启全链路跟踪功能。另外还需要修改log_min_duration_statement和track_stmt_stat_level参数。 + +**log_min_duration_statement**表示慢SQL阈值，如果为0则全量收集，时间单位为毫秒； + +**track_stmt_stat_level**表示信息捕获的级别，建议设置为track_stmt_stat_level='L0,L0' + +``` +gs_guc reload -N all -I all -c 'enable_record_nettime=on'; +gs_guc reload -N all -I all -c 'log_min_duration_statement=0'; +gs_guc reload -N all -I all -c "track_stmt_stat_level='L0,L0'"; +``` + +## 在客户端执行测试SQL语句 + +``` +select address,max(id) from t1 group by address; +``` + +![image-20241104164958909](20241102.assets/image-20241104164958909.png) + +## 查看dbe_perf.statement视图中的信息 + +``` +openGauss=# select query,net_trans_time,last_updated from dbe_perf.statement where user_name ='test' and query like '%t1%' order by last_updated desc; + query | net_trans_time | last_updated +----------------------------------------------------------------------------+----------------+------------------------------- + select address,max(id) from t1 group by address | 1294 | 2024-11-04 16:50:03.036603+08 + select * from t1 | 1793 | 2024-11-04 16:49:00.123864+08 + select max(name) from t1 | 978 | 2024-11-04 16:37:33.611782+08 + select max(?) from t1 | 2564 | 2024-11-04 16:32:55.269171+08 + vacuum t1; | 0 | 2024-11-04 16:32:19.137282+08 + select count(?) from t1 | 9708 | 2024-11-04 16:11:06.538974+08 + insert into t1 values(?,?,?) | 0 | 2024-11-04 14:53:35.988101+08 + create table t1(id int primary key,name varchar(100),address varchar(100)) | 0 | 2024-11-04 14:53:29.41779+08 +(8 rows) +``` + + + +![image-20241104170854961](20241102.assets/image-20241104170854961.png) + +通过测试结果，可以看出在dbe_perf.statement已经记录刚才执行的sql，并且网络消耗的时间为1294us。 + +## 查看statement_history表中的记录信息 + +``` +openGauss=# select query,start_time,finish_time,net_trans_time from statement_history t where user_name ='test' and query like '%t1%' order by start_time desc limit 10; + query | start_time | finish_time | net_trans_time +-------------------------------------------------+-------------------------------+-------------------------------+---------------- + select address,max(id) from t1 group by address | 2024-11-04 16:49:40.847096+08 | 2024-11-04 16:49:40.848015+08 | 1294 + select address,max(id) from t1 group by address | 2024-11-04 16:49:40.846453+08 | 2024-11-04 16:49:40.847074+08 | 0 + select * from t1 | 2024-11-04 16:48:55.543124+08 | 2024-11-04 16:48:55.543701+08 | 899 + select * from t1 | 2024-11-04 16:48:55.54295+08 | 2024-11-04 16:48:55.543113+08 | 0 + select * from t1 | 2024-11-04 16:37:33.611937+08 | 2024-11-04 16:37:33.61237+08 | 894 + select * from t1 | 2024-11-04 16:37:33.611803+08 | 2024-11-04 16:37:33.611931+08 | 0 + select max(name) from t1 | 2024-11-04 16:33:25.862634+08 | 2024-11-04 16:33:25.863255+08 | 978 + select max(name) from t1 | 2024-11-04 16:33:25.862076+08 | 2024-11-04 16:33:25.862622+08 | 0 + vacuum t1; | 2024-11-04 16:32:19.123703+08 | 2024-11-04 16:32:19.137293+08 | 0 + select max(?) from t1 | 2024-11-04 16:27:26.614458+08 | 2024-11-04 16:27:26.615534+08 | 2564 +(10 rows) + +``` + +![image-20241104170751474](20241102.assets/image-20241104170751474.png) + +通过上面的查询可知，在statement_history也已经有执行sql的记录，网络消耗的时间为1294us和dbe_perf.statement的值一致。 + +## 总结 + +全链路跟踪能力是对数据库问题定位工具的完善，对于数据库运维的老师来说又是一个好的消息。 在这边文章中我只是带领大家初步了解一下全链路跟踪能力怎么查看，但是详细的内部原理，大家可以参考openGauss官网视频号中对于该功能的详细介绍。 + +## 参考 + +【openGauss 6.0.0 LTS版本特性解读(四) | openGauss 全链路跟踪】https://www.bilibili.com/video/BV1gFSRYKErB?vd_source=0741f9621c39156deebce32bbdc2a50c \ No newline at end of file diff --git "a/app/zh/blogs/wangshifei/\346\204\217\345\244\226\345\217\221\347\216\260openGauss\345\205\274\345\256\271Oracle\347\232\204\345\207\240\344\270\252\346\235\241\344\273\266\350\241\250\350\276\276\345\274\217\345\207\275\346\225\260" "b/app/zh/blogs/wangshifei/\346\204\217\345\244\226\345\217\221\347\216\260openGauss\345\205\274\345\256\271Oracle\347\232\204\345\207\240\344\270\252\346\235\241\344\273\266\350\241\250\350\276\276\345\274\217\345\207\275\346\225\260" new file mode 100644 index 0000000000000000000000000000000000000000..b9e2702388f009b25ffbfc65cb301851b9f90e8d --- /dev/null +++ "b/app/zh/blogs/wangshifei/\346\204\217\345\244\226\345\217\221\347\216\260openGauss\345\205\274\345\256\271Oracle\347\232\204\345\207\240\344\270\252\346\235\241\344\273\266\350\241\250\350\276\276\345\274\217\345\207\275\346\225\260" @@ -0,0 +1,89 @@ +--- +title: '【第七届openGauss技术文章征集】意外发现openGauss兼容Oracle的几个条件表达式函数' +date: '2024-10-15' +category: 'blog' +tags: ['openGauss'] +archives: '2024-04' +author: '墨竹' +summary: 'Just about everything you'll need to style in the theme：headings, paragraphs, blockquotes, tables, code blocks, and more.' +--- +# 意外发现openGauss兼容Oracle的几个条件表达式函数 + +最近工作中发现openGauss在兼容oracle模式下，可以兼容常用的两个条件表达式函数，因此就随手测试了一下。 + +## 查看数据库版本 + +``` +[omm@openGauss ~]$ gsql -r +gsql ((openGauss 6.0.0-RC1 build ed7f8e37) compiled at 2024-03-31 11:59:31 commit 0 last mr ) +Non-SSL connection (SSL connection is recommended when requiring high-security) +Type "help" for help. + +openGauss=# select version(); + version +----------------------------------------------------------------------------------------------------------------------------------------------------------- + (openGauss 6.0.0-RC1 build ed7f8e37) compiled at 2024-03-31 11:59:31 commit 0 last mr on x86_64-unknown-linux-gnu, compiled by g++ (GCC) 10.3.0, 64-bit +(1 row) + + +``` + +## 查看openGauss数据库的兼容模式 + +``` +testdb=# select datname,datcompatibility from pg_database; + datname | datcompatibility +-----------+------------------ + template1 | A + template0 | A + testdb | A + postgres | A +(4 rows) + +``` + +## decode(expr1, expr2, result1 ,…) + +将表达式base_expr与后面的每个compare(n) 进行比较，如果匹配返回相应的value(n)。如果没有发生匹配，则返回default。 +![decode.png](https://oss-emcsprod-public.modb.pro/image/editor/20240525-3073290c-a4e5-4265-a30a-8a727cfbaf40.png) +``` +testdb=# select id,name,address,decode(address,'北京市','BJ','南京市','NJ','ZG') JC from t1; + id | name | address | jc +----+------+---------+---- + 2 | zs2 | 北京市 | BJ + 4 | zs4 | | ZG + 1 | zs1 | 南京市 | NJ +(3 rows) + +``` + +## nvl(expr1, expr2) + +如果value1为NULL则返回value2，如果value1非NULL，则返回value1。 +![nvl.jpg](https://oss-emcsprod-public.modb.pro/image/editor/20240525-afaa9177-90a4-46db-9a37-9f10103a8173.jpg) +``` +testdb=# select * from t1; + id | name | address +----+------+--------- + 2 | zs2 | 北京市 + 4 | zs4 | +(2 rows) +testdb=# select id,name,nvl(address,'上海') from t1; + id | name | nvl +----+------+-------- + 2 | zs2 | 北京市 + 4 | zs4 | 上海 +(2 rows) +``` +decode和nvl的使用方法与在Oracle中的使用方式一致，并无差别，这里不做详细介绍。在查看文档过程，官网文档函数和操作符章节与whale插件支持的函数相关章节两个地方都描述了对nvl、decode的支持情况，但是也未发现两处的区别在哪儿？不清楚当使用插件和不使用的情况的功能区别在哪儿呢？另外也发现在oracle中开发经常使用的nvl2条件表达式也支持，但是使用需要使用whale插件后才可以使用；后来想安装whale插件测试，但是也没有对应版本插件下载的地方，只能下载源码自行编译，对于这块感觉还是有点不方便。由于时间的问题也没有进一步编译插件源码进行测试。 + + + + + + + + + + + diff --git "a/app/zh/blogs/wangshifei/\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\211\350\243\205openGauss6.0\344\274\201\344\270\232\347\211\210\345\215\225\350\212\202\347\202\271-CentOS7.6" "b/app/zh/blogs/wangshifei/\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\211\350\243\205openGauss6.0\344\274\201\344\270\232\347\211\210\345\215\225\350\212\202\347\202\271-CentOS7.6" new file mode 100644 index 0000000000000000000000000000000000000000..3836e689dd108c6e1555ae36d4b72354423b3c3d --- /dev/null +++ "b/app/zh/blogs/wangshifei/\346\211\213\346\212\212\346\211\213\346\225\231\344\275\240\345\256\211\350\243\205openGauss6.0\344\274\201\344\270\232\347\211\210\345\215\225\350\212\202\347\202\271-CentOS7.6" @@ -0,0 +1,356 @@ +# 手把手教你安装openGauss6.0企业版单节点-CentOS7.6 + +这边文章主要是带领初学者安装openGauss6.0企业版单节点，让你快速上手。 + +## 软硬件环境介绍 + +| 软硬件名称 | 配置 | +| ---------- | --------------------------- | +| CPU | X86_64，8C | +| 内存 | 8G | +| 操作系统 | CentOS7.6 | +| Python版本 | Python2.7.5（后期会做更改） | + +## 获取安装包 + +### 用root用户登录主机，并创建存放安装软件的目录 + +``` +[root@ogdb ~]# mkdir -p /opt/software/openGauss +``` + +### 下载安装包 + +从openGauss社区[下载对应版本安装包](https://opengauss.org/zh/download/)，在这里我们下载的版本为x86_64架构且操作系统版本为CentOS7.6。将下载的版本上传到/opt/software/openGauss目录下。 + +``` +[root@ogdb openGauss]# ls -ll +total 149764 +-rw-r--r-- 1 root root 153356080 Nov 1 10:01 openGauss-All-6.0.0-CentOS7-x86_64.tar.gz +[root@ogdb openGauss]# +``` + +解压下载的安装包，解压安装包后，继续解压openGauss-OM-6.0.0-CentOS7-x86_64.tar.gz安装包 + +``` +[root@ogdb openGauss]# tar -xvf openGauss-All-6.0.0-CentOS7-x86_64.tar.gz +openGauss-CM-6.0.0-CentOS7-x86_64.tar.gz +openGauss-OM-6.0.0-CentOS7-x86_64.tar.gz +openGauss-Server-6.0.0-CentOS7-x86_64.tar.bz2 +openGauss-CM-6.0.0-CentOS7-x86_64.sha256 +openGauss-OM-6.0.0-CentOS7-x86_64.sha256 +openGauss-Server-6.0.0-CentOS7-x86_64.sha256 +upgrade_sql.tar.gz +upgrade_sql.sha256 +[root@ogdb openGauss]# +[root@ogdb openGauss]# tar -xvf openGauss-OM-6.0.0-CentOS7-x86_64.tar.gz +``` + +修改安装目录权限 + +``` +[root@ogdb ~]# chmod 755 -R /opt/software +``` + +## 配置安装环境 + +### 配置环境参数 + +- 修改SELINUX值 + +``` +vim /etc/selinux/config +--修改SELINUX值为disabled，然后保存并退出 +SELINUX=disabled +``` + +重启操作系统 + +``` +reboot +``` + +- 关闭防火墙 + +先查看当前防火墙的状态 + +``` +[root@ogdb ~]# systemctl status firewalld +● firewalld.service - firewalld - dynamic firewall daemon + Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) + Active: active (running) since Fri 2024-11-01 14:05:03 CST; 1s ago + Docs: man:firewalld(1) + Main PID: 21392 (firewalld) + Tasks: 2 + CGroup: /system.slice/firewalld.service + └─21392 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid + +Nov 01 14:05:03 ogdb systemd[1]: Starting firewalld - dynamic firewall daemon... +Nov 01 14:05:03 ogdb systemd[1]: Started firewalld - dynamic firewall daemon. +[root@ogdb ~]# +``` + +若防火墙状态显示为active (running)，则表示防火墙未关闭，请执行下面关闭防火墙的命令；否则跳过下面的步骤 + +关闭防火墙并禁止开机重启 + +``` +systemctl disable firewalld +systemctl stop firewalld +``` + +- 设置字符集参数 + +``` +[root@ogdb ~]# cat >> /etc/profile < export LANG=en_US.UTF-8 +> EOF +``` + +执行命令使得配置生效 + +``` +[root@ogdb ~]# source /etc/profile +``` + +### 使用yum安装系统依赖项 + +备份原来的yum配置文件 + +``` +[root@ogdb yum.repos.d]# mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak +``` + +下载可用源的repo文件，在这里我们https://mirrors.huaweicloud.com/repository/conf获取服务器对应的repo配置文件CentOS-7-anon.repo + +``` +[root@ogdb yum.repos.d]# curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.huaweicloud.com/repository/conf/CentOS-7-anon.repo + % Total % Received % Xferd Average Speed Time Time Time Current + Dload Upload Total Spent Left Speed +100 1811 0 1811 0 0 2253 0 --:--:-- --:--:-- --:--:-- 2252 +``` + +执行命令，安装所需要的依赖包 + +``` +yum install -y libaio-devel readline-devel expect python3 +``` + +### 修改Python版本 + +1. 由于openGauss安装所需要用到python-3.x命令，但是centos7.6版本默认python版本为python-2.7.x，因此需要切换到python-3.x。 + +2. 备份python文件 + + ``` + [root@ogdb bin]# cd /usr/bin + [root@ogdb bin]# mv python python.bak + ``` + +3. 建立python3的软链接 + + ``` + ln -s python3 /usr/bin/python + ``` + +4. 验证python版本 + + ``` + [root@ogdb bin]# python -V + Python 3.6.8 + ``` + + 官方对python版本为CentOS：支持>=Python 3.6.X且<=Python 3.10.X，可知符合要求。 + +## 安装数据库 + +### 创建XML配置文件 + +安装openGauss前需要创建cluster_config.xml文件。cluster_config.xml文件包含部署openGauss的服务器信息、安装路径、IP地址以及端口号等。用于告知openGauss如何部署。用户需根据不同场景配置对应的XML文件。 + +用root用户切换到安装目录 + +``` +cd /opt/software/openGauss +``` + +创建XML配置文件，用于数据库安装 + +``` +vi cluster_config.xml +``` + +将一下的内容粘贴到上面的文件中。 + +``` + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +``` + +### 执行初始化脚本 + +执行预安装初始化命令 + +``` +cd /opt/software/openGauss/script +./gs_preinstall -U omm -G dbgrp -X /opt/software/openGauss/cluster_config.xml +``` + +创建omm用户，对omm用户建立互信，并设置密码 + +``` +Are you sure you want to create the user[omm] (yes/no)? yes +Please enter password for cluster user. +Password: +Please enter password for cluster user again. +Password: +Generate cluster user password files successfully. +``` + +在结尾我们可以看到如下信息，就表示初始化安装完成。 + +``` +Successfully set finish flag. +Preinstallation succeeded. +``` + +### 执行安装 + +切换到omm用户 + +``` +[root@ogdb script]# su - omm +Last login: Fri Nov 1 15:23:20 CST 2024 +[omm@ogdb ~]$ +``` + +切换到目录/opt/software/openGauss/script，然后使用gs_install安装openGauss + +``` +cd /opt/software/openGauss/script +gs_install -X /opt/software/openGauss/cluster_config.xml + +``` + +在安装的过程中需要输入数据库的密码，密码要求一定的复杂度，请记住输入的密码 + +``` +--数据库密码 +openGauss2024 +``` + +安装日志 + +``` +[omm@ogdb script]$ gs_install -X /opt/software/openGauss/cluster_config.xml +Parsing the configuration file. +Successfully checked gs_uninstall on every node. +Check preinstall on every node. +Successfully checked preinstall on every node. +Creating the backup directory. +Successfully created the backup directory. +begin deploy.. +Installing the cluster. +begin prepare Install Cluster.. +Checking the installation environment on all nodes. +begin install Cluster.. +Installing applications on all nodes. +Successfully installed APP. +begin init Instance.. +encrypt cipher and rand files for database. +Please enter password for database: +Please repeat for database: +[GAUSS-50322] : Failed to encrypt the password for databaseError: + Try "gs_guc --help" for more information. +Invalid password,it must contain at least eight characters + +Please enter password for database: +Please repeat for database: +begin to create CA cert files +The sslcert will be generated in /opt/openGauss/app/share/sslcert/om +NO cm_server instance, no need to create CA for CM. +Non-dss_ssl_enable, no need to create CA for DSS +Cluster installation is completed. +Configuring. +Deleting instances from all nodes. +Successfully deleted instances from all nodes. +Checking node configuration on all nodes. +Initializing instances on all nodes. +Updating instance configuration on all nodes. +Check consistence of memCheck and coresCheck on database nodes. +Configuring pg_hba on all nodes. +Configuration is completed. +The cluster status is Normal. +Successfully started cluster. +Successfully installed application. +end deploy.. +``` + +## 数据库使用 + +在安装完成后，数据库服务器是默认启动的 + +切换到omm用户 + +``` +su - omm +``` + +连接数据库，在这里的端口使用的默认端口15400，因此未指定端口 + +``` +[omm@ogdb script]$ gsql -r +gsql ((openGauss 6.0.0 build aee4abd5) compiled at 2024-09-29 18:38:08 commit 0 last mr ) +Non-SSL connection (SSL connection is recommended when requiring high-security) +Type "help" for help. + +openGauss=# +``` + +到这里我们的openGauss6.0企业版单节点部署已经完成，希望你体验openGauss的旅程一帆风顺。 + +## 参考 + +https://docs.opengauss.org/zh/docs/6.0.0/docs/InstallationGuide/%E4%BC%81%E4%B8%9A%E7%89%88%E5%AE%89%E8%A3%85.html \ No newline at end of file