最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

KingbaseES數據庫開發(fā)運維:部署、安全、備份與監(jiān)控實戰(zhàn)

 更新時間:2026年06月27日 16:22:47   作者:wei_shuo  
詳細介紹了KingbaseES數據庫的安裝部署、安全配置、性能優(yōu)化和日常監(jiān)控等關鍵步驟,適合數據庫開發(fā)和運維人員參考,重點分享了KingbaseES的安裝配置細節(jié)、三權分立和透明數據加密等安全特性,以及KWR和KSH等性能監(jiān)控工具的使用心得

寫在開頭

干數據庫這行有些年頭了,從最早用商業(yè)庫到后來折騰各種國產庫,踩過的坑說多了都是淚。這兩年信創(chuàng)項目越來越多,KES 數據庫在政企、金融、能源領域鋪得挺廣,身邊不少朋友開始接觸它。說實話,剛上手的時候我也摸不著頭腦——文檔雖然有,但很多細節(jié)得靠自己踩坑才能搞明白。有些配置參數改了之后要重啟才生效,有些不用;有些功能要裝擴展才能用,有些默認就開著。這些東西文檔里都有寫,但散落在各個章節(jié)里,找起來費勁。

這篇文章算是一個階段性的總結,把部署配置、安全管理、備份恢復、日常監(jiān)控這幾個方面的心得記下來。適合有一定數據庫基礎、剛開始接觸 KingbaseES 的開發(fā)和運維人員。內容偏實操,理論部分點到為止,重點還是那些命令和配置。如果你是正在做信創(chuàng)項目選型或者剛接手一個 KES 數據庫的運維工作,這篇文章應該能幫你少走一些彎路。

安裝部署與環(huán)境初始化

裝庫這事本身不難,但有些細節(jié)不注意后面會吃苦頭。KES 支持主流國產操作系統(tǒng),麒麟、統(tǒng)信、中科方德都沒問題,x86 和 ARM 架構也都能跑。我一般在 CentOS 和麒麟 V10 上裝得比較多,流程差不多。有一點要提前確認:操作系統(tǒng)的內核參數和網絡配置要符合數據庫的安裝要求,特別是大頁內存(hugepages)的設置,生產環(huán)境下開啟大頁對性能有幫助。

安裝包獲取與準備

安裝介質從電科金倉官方渠道獲取,一般是 ISO 或者 tar.gz 格式。拿到之后先校驗一下 MD5,別因為下載不完整浪費時間。解壓之后目錄結構大致是這樣的:

tar -xzf KingbaseES_V9_xxx.tar.gz
cd KingbaseES_V9_xxx

# 看一下目錄結構
ls -l
# setup.sh 是安裝腳本
# license.dat 是授權文件,沒這個裝不了

裝之前確認系統(tǒng)用戶和環(huán)境變量。建議用專門的 kingbase 用戶來安裝和運行數據庫服務,別用 root。

# 創(chuàng)建專用用戶
useradd -m kingbase
passwd kingbase

# 設置目錄權限
chown -R kingbase:kingbase /opt/Kingbase

執(zhí)行安裝

KES 提供圖形界面安裝和靜默安裝兩種方式。服務器環(huán)境下我推薦用靜默安裝,快且不容易出錯。圖形界面那個在遠程終端里跑起來卡得很,沒必要。

# 靜默安裝示例
./setup.sh -i console \
  -d /opt/Kingbase/ES/V9 \
  -p server \
  -U system \
  -W "YourPassword123" \
  --license /opt/license.dat

安裝過程中會讓你選擇兼容模式,這個比較關鍵。KingbaseES 支持 Oracle 兼容、MySQL 兼容和標準模式三種。選哪種取決于你的業(yè)務原來用的是什么庫。如果是新開發(fā)的項目,標準模式就挺好,SQL 行為最規(guī)范;如果是從 Oracle 遷過來的,選 Oracle 兼容模式會省很多事,存儲過程、包、自定義類型基本上不用怎么改就能跑。MySQL 兼容模式同理,對 MySQL 的方言和函數做了適配。不過要注意,兼容模式選定之后不能隨便切換,建議在項目初期就確定好。

初始化與啟動

裝完之后初始化數據庫實例,這個過程跟其他關系型數據庫類似:

# 切到 kingbase 用戶
su - kingbase

# 初始化數據目錄
initdb -D /data/kingbase/data \
  -U system \
  -W \
  --encoding=UTF8 \
  --locale=zh_CN.UTF-8

# 啟動服務
sys_ctl -D /data/kingbase/data start

# 確認服務狀態(tài)
sys_ctl -D /data/kingbase/data status

啟動之后第一件事是改默認密碼和配置 ksql 的訪問權限。ksql 是 KES 自帶的命令行交互工具,跟其他數據庫的 CLI 工具用法差不多,SQL 語句直接敲進去就能執(zhí)行。

-- 通過 ksql 連接
-- ksql -U system -d test -p 54321

-- 改掉默認密碼
ALTER USER system WITH PASSWORD 'NewStrongP@ss2026';

-- 看一下當前數據庫列表
SELECT datname, datowner, encoding FROM sys_database;

配置文件調整

初始化完成后的默認配置只能跑跑測試,生產環(huán)境得改幾個關鍵參數。配置文件在數據目錄下的 kingbase.conf:

-- 這幾個參數改完需要重啟
shared_buffers = 4GB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 12GB

-- 連接數根據實際并發(fā)來定
max_connections = 200

-- 日志相關
logging_collector = on
log_directory = 'sys_log'
log_filename = 'kingbase-%Y-%m-%d.log'
log_min_duration_statement = 1000
log_rotation_age = 1d

shared_buffers 一般設成物理內存的 25% 左右,不要貪大。我有次設到 60% 結果系統(tǒng)緩存不夠用,IO 反而變高了。work_mem 注意它是每個排序操作各自分配的,并發(fā)高的話別設太猛,不然內存會被吃光。

網絡訪問配置

默認只允許本機連接,要讓其他機器訪問得改兩個地方。一個是 kingbase.conf 里的 listen_addresses,另一個是 sys_hba.conf 里的訪問控制規(guī)則:

# kingbase.conf
listen_addresses = '*'
port = 54321

# sys_hba.conf
# 允許內網段訪問
host  all  all  192.168.1.0/24  scram-sha-256

改完這兩個文件要 reload 一下配置,不用重啟:

sys_ctl -D /data/kingbase/data reload

sys_hba.conf 這個文件相當于數據庫的防火墻規(guī)則,格式是"連接類型 數據庫 用戶 地址 認證方式"。scram-sha-256 是目前推薦的密碼認證方式,比老的 md5 更安全。如果涉及跨公網的訪問,建議走 SSL 連接,在 sys_hba.conf 里用 hostssl 代替 host,強制走加密通道。KES 默認支持 SSL,只需要把證書和密鑰放到數據目錄下并在 kingbase.conf 里開啟 ssl = on 就行。

SQL 開發(fā)與日常操作

KES 的 SQL 語法對標準 SQL 的支持很完整,日常開發(fā)用到的 DDL、DML、事務控制都沒什么問題。這部分不打算寫教科書式的內容,重點記一些實際項目中容易忽略的點。

建表與數據類型選擇

建表的時候數據類型選擇挺有講究的。我見過不少項目清一色 VARCHAR + INT + TIMESTAMP,把數據庫當 Excel 用了。KES 支持的類型比大多數人用得到的要多不少。

CREATE TABLE device_info (
    id          BIGSERIAL PRIMARY KEY,
    device_code VARCHAR(64) NOT NULL UNIQUE,
    device_name VARCHAR(200) NOT NULL,
    category    SMALLINT DEFAULT 1,
    specs       JSONB,
    tags        TEXT[],
    location    POINT,
    status      SMALLINT DEFAULT 1,
    created_at  TIMESTAMP DEFAULT now(),
    updated_at  TIMESTAMP DEFAULT now()
);

-- JSONB 類型特別適合存半結構化的配置信息
INSERT INTO device_info (device_code, device_name, specs)
VALUES (
    'DEV-20260101-001',
    '溫濕度傳感器-A3',
    '{"protocol": "MQTT", "interval": 30, "unit": "celsius"}'::jsonb
);

-- 查詢 JSONB 里的字段
SELECT device_code,
       specs->>'protocol' AS protocol,
       (specs->>'interval')::int AS report_interval
FROM device_info
WHERE specs ? 'protocol';

數組類型存標簽、角色列表這類東西很方便,省得建額外的關聯表。JSONB 用來存配置項、擴展屬性這種半結構化數據,比搞一堆 VARCHAR 列強多了。

事務與并發(fā)控制

KES 的事務管理跟標準 SQL 一致,BEGIN / COMMIT / ROLLBACK 這套東西沒什么好說的。說一個實際遇到的問題。

有個項目上線后發(fā)現頻繁出現死鎖。排查下來是因為兩個業(yè)務模塊同時更新同一批數據,但更新順序不一樣——模塊 A 先更新訂單表再更新庫存表,模塊 B 反過來先更新庫存表再更新訂單表,并發(fā)一高就死鎖了。解決方法是保證所有涉及多行更新的業(yè)務邏輯按固定順序操作,開發(fā)團隊約定了一個統(tǒng)一的表操作優(yōu)先級規(guī)范。

另外,KES 支持 NOWAIT 和 SKIP LOCKED 語法,在高并發(fā)搶鎖的場景下很有用:

-- 搶不到鎖就立即返回錯誤,不傻等
SELECT * FROM task_queue
WHERE status = 0
FOR UPDATE NOWAIT;

-- 跳過已被其他事務鎖定的行,處理下一批
SELECT * FROM task_queue
WHERE status = 0
FOR UPDATE SKIP LOCKED
LIMIT 10;

SKIP LOCKED 特別適合做任務隊列這種場景,多個消費者同時取任務,各自拿到不重復的任務去處理,不會互相阻塞。之前有個項目用一張表做消息隊列,沒有 SKIP LOCKED 之前經常因為鎖等待導致任務分發(fā)延遲,加上之后吞吐量直接翻了兩倍多。所以如果你的業(yè)務有類似的并發(fā)模型,這兩個語法一定要用起來。

批量操作性能

批量插入數據的時候別一條一條 INSERT,用 COPY 命令會快幾個數量級。這個經驗適用于大多數關系型數據庫。COPY 走的是二進制協(xié)議,跳過了 SQL 解析和優(yōu)化的開銷,百萬級數據的導入通常在十幾秒內就能完成:

-- 從 CSV 文件批量導入,速度比 INSERT 快得多
COPY device_info (device_code, device_name, category)
FROM '/data/import/devices.csv'
WITH (FORMAT csv, HEADER true, DELIMITER ',');

-- 如果是程序里拼接批量 INSERT,至少用多值語法
INSERT INTO device_info (device_code, device_name, category)
VALUES
    ('DEV-001', '溫度傳感器', 1),
    ('DEV-002', '壓力傳感器', 2),
    ('DEV-003', '流量計', 3);

更新和刪除大量數據的時候也有講究。一次性 DELETE 幾千萬行會長時間持有大量鎖,影響線上業(yè)務。建議分批操作,每次處理一小批,中間讓出鎖:

-- 分批刪除過期數據
DO $$
DECLARE
    batch_size INT := 5000;
    deleted INT;
BEGIN
    LOOP
        DELETE FROM sensor_data
        WHERE ctid IN (
            SELECT ctid FROM sensor_data
            WHERE record_time < '2024-01-01'
            LIMIT batch_size
        );
        GET DIAGNOSTICS deleted = ROW_COUNT;
        COMMIT;
        EXIT WHEN deleted < batch_size;
        -- 暫停一下,給其他事務讓路
        PERFORM pg_sleep(0.5);
    END LOOP;
END $$;

安全管理:三權分立與數據加密

安全這塊是 KES 比較強的地方,畢竟過了等保四級認證的產品。很多政企項目對數據庫安全有硬性要求,不達標驗收都過不了。KingbaseES 在安全方面做了很多工作,從訪問控制到數據加密到審計追蹤,形成了一套比較完整的安全防護體系。

三權分立

KES 支持三權分立的安全管理模式,把數據庫管理權限拆分成三個角色:系統(tǒng)管理員(SYSSO)負責日常運維和對象管理,安全管理員(SECO)負責安全策略和審計配置,審計管理員(AUDSO)負責審計日志的查看和管理。三個角色互相制約,任何一個人拿不到全部權限。

-- 啟用三權分立需要修改配置
-- kingbase.conf 中設置
-- enable_sec_admin = on
-- 改完重啟生效

-- 查看當前角色和權限分配
SELECT rolname, rolsuper, rolcreatedb, rolcreaterole, rolcanlogin
FROM sys_roles
ORDER BY rolname;

三權分離這個設計思路其實跟企業(yè)管理里的"不相容職務分離"是一個道理。系統(tǒng)管理員能建表建用戶但看不到審計日志,審計管理員能看到所有人的操作記錄但改不了數據和配置,安全管理員管策略但碰不到業(yè)務數據。

用戶和權限管理

權限分配遵循最小化原則,別圖省事給普通應用賬號 SUPERUSER 權限。我見過好幾個項目為了調試方便直接給 dba 權限上線的,后面審計的時候全被打了回來。

-- 創(chuàng)建只讀用戶
CREATE ROLE readonly_user WITH LOGIN PASSWORD 'Read@2026';
GRANT CONNECT ON DATABASE production TO readonly_user;
GRANT USAGE ON SCHEMA public TO readonly_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_user;

-- 設置默認權限,以后新建的表也自動有 SELECT 權限
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO readonly_user;

-- 創(chuàng)建應用用戶,只給增刪改查權限
CREATE ROLE app_user WITH LOGIN PASSWORD 'App@2026';
GRANT CONNECT ON DATABASE production TO app_user;
GRANT USAGE, CREATE ON SCHEMA public TO app_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

透明數據加密 TDE

KES 支持透明數據加密,也就是 TDE。開啟之后數據在磁盤上是加密存儲的,讀寫的時候由數據庫引擎自動加解密,應用層完全無感知。對于存儲敏感信息的場景,這個功能是剛需。

-- 創(chuàng)建加密表空間
CREATE TABLESPACE encrypted_ts
LOCATION '/data/kingbase/encrypted'
WITH (encrypt_type = 'SM4');

-- 在加密表空間上建表
CREATE TABLE user_identity (
    id          BIGSERIAL PRIMARY KEY,
    user_name   VARCHAR(100) NOT NULL,
    id_card     VARCHAR(18) NOT NULL,
    phone       VARCHAR(20),
    created_at  TIMESTAMP DEFAULT now()
) TABLESPACE encrypted_ts;

加密算法支持國密 SM4,也支持 AES。選型的時候根據合規(guī)要求來定,政務類項目一般要求國密算法。需要注意的是,加密表空間對性能有一定影響,大概在 5% 到 10% 左右,具體看數據量和讀寫比例。

審計配置

審計功能可以記錄指定用戶或指定操作的訪問日志,事后追溯誰在什么時間做了什么操作。開啟方式不復雜:

-- 通過安全管理員配置審計策略
-- 記錄所有 DDL 操作
SELECT audit_set_rule('audit_ddl', 'on');

-- 記錄對敏感表的訪問
SELECT audit_set_object('public.user_identity', 'select,insert,update,delete');

-- 查看審計日志
SELECT event_time, username, event_type, object_name, statement
FROM sys_audit_log
WHERE event_time > now() - INTERVAL '1 day'
ORDER BY event_time DESC
LIMIT 50;

審計日志量大的話記得定期歸檔和清理,別讓審計表把磁盤撐滿了。我就遇到過這種事,審計開了半年沒人管,某天磁盤報警才發(fā)現審計日志占了 200 多 G。

備份恢復與高可用

數據備份這事不用多說了,沒備份的數據庫就是在裸奔。KES 自帶的備份工具叫 sys_rman,功能跟 Oracle 的 RMAN 差不多,支持全量備份、增量備份和時間點恢復。

物理備份

# 全量備份
sys_rman -F /data/kingbase/backup backup full

# 增量備份(基于上次全量或增量)
sys_rman -F /data/kingbase/backup backup incremental

# 查看備份集信息
sys_rman -F /data/kingbase/backup show

# 清理過期備份(保留最近 7 天)
sys_rman -F /data/kingbase/backup delete --older-than 7d

建議的備份策略是每周一次全量,每天一次增量,備份保留周期根據業(yè)務需要和磁盤空間來定。備份完了別忘了驗證,sys_rman 支持 validate 命令:

# 驗證備份完整性
sys_rman -F /data/kingbase/backup validate

不驗證的備份跟沒有備份區(qū)別不大。之前有個客戶的數據庫硬盤壞了,拿備份出來恢復的時候才發(fā)現三個月前的某次備份文件就壞了,中間一直沒驗證過。最后只能恢復到更早的時間點,丟了不少數據。

時間點恢復 PITR

誤刪數據是 DBA 的噩夢。KES 支持 PITR(Point-In-Time Recovery),可以把數據庫恢復到過去任意一個時間點,前提是歸檔日志要完整。

# 恢復步驟概要
# 1. 停庫
sys_ctl -D /data/kingbase/data stop

# 2. 恢復基礎備份
sys_rman -F /data/kingbase/backup restore --target-time "2026-06-04 15:30:00"

# 3. 配置恢復目標
# 在 kingbase.auto.conf 中設置
# recovery_target_time = '2026-06-04 15:30:00'
# recovery_target_action = 'promote'

# 4. 啟動恢復
sys_ctl -D /data/kingbase/data start

PITR 的前提是持續(xù)歸檔要正常。歸檔配置在 kingbase.conf 里:

archive_mode = on
archive_command = 'cp %p /data/kingbase/archive/%f'

歸檔目錄別跟數據目錄放在同一塊盤上,盤壞了就全沒了。有條件的話用 NFS 或者對象存儲做歸檔目的地。

高可用集群

生產環(huán)境的 KES 一般部署成主備集群。主庫處理讀寫請求,備庫通過流復制實時同步數據。主庫掛了可以手動切換也可以自動切換。KES 自帶的高可用組件能實現自動故障檢測和切換,RTO 通常控制在 30 秒以內。

# 備庫搭建:基于主庫做基礎備份
sys_basebackup -h primary_host -p 54321 -U replication_user \
  -D /data/kingbase/standby \
  -Fp -Xs -P

# 備庫配置 recovery 參數
# kingbase.auto.conf
primary_conninfo = 'host=primary_host port=54321 user=replication_user password=xxx'
hot_standby = on

流復制有兩種模式:同步復制保證 RPO 為零,每條事務至少在備庫寫了一份 WAL 才算提交成功;異步復制性能更好但可能丟少量數據。關鍵業(yè)務用同步,非關鍵業(yè)務用異步,看具體取舍。

-- 查看復制狀態(tài)
SELECT pid, usename, application_name, client_addr,
       state, sync_state, sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM sys_stat_replication;

這里有個要注意的地方:同步復制對網絡延遲很敏感。如果主備之間網絡延遲超過 5 毫秒,寫入性能就會明顯下降。跨機房部署的時候測一下延遲再決定用同步還是異步。

日常監(jiān)控與性能診斷

數據庫監(jiān)控做得好不好直接決定你能不能提前發(fā)現問題。等用戶打電話說"系統(tǒng)怎么這么慢"再去查,往往已經晚了。我習慣把監(jiān)控分成三層:第一層是操作系統(tǒng)級別的,CPU、內存、磁盤 IO、網絡帶寬;第二層是數據庫實例級別的,連接數、事務量、鎖等待、緩存命中率;第三層是 SQL 級別的,慢查詢、執(zhí)行計劃、索引使用情況。這篇文章重點說后兩層。

KWR 性能報告

KES 內置了一個叫 KWR(Kingbase Workload Repository)的性能采集工具,功能跟 Oracle 的 AWR 報告很像。它會周期性地給數據庫拍快照,記錄各種性能指標的累積值。對比兩個快照之間的差異就能看出這段時間數據庫的負載情況。

-- 確認 KWR 擴展已安裝
CREATE EXTENSION IF NOT EXISTS sys_kwr;

-- 手動創(chuàng)建一個快照
SELECT sys_kwr_snapshot();

-- 生成兩個快照之間的性能報告
-- 先查看快照 ID
SELECT snap_id, snap_time FROM sys_kwr_snapshots ORDER BY snap_id DESC LIMIT 10;

-- 生成報告(輸出到文件)
\o /tmp/kwr_report.html
SELECT sys_kwr_report(101, 105, 'html');
\o

KWR 報告里的信息量很大,我一般重點看幾個部分:等待事件排名、TOP SQL(按總耗時和調用次數排序)、緩存命中率、檢查點統(tǒng)計。如果某個等待事件突然飆升,基本就能定位到瓶頸在哪。

活躍會話分析

KSH(Kingbase Session History)記錄每個活躍會話在采樣時刻的等待事件和執(zhí)行信息,粒度比 KWR 更細。適合排查某個時間點的性能抖動。

-- 啟用 KSH
CREATE EXTENSION IF NOT EXISTS sys_ksh;

-- 查看最近 5 分鐘最耗時的等待事件
SELECT wait_event_type, wait_event, count(*)
FROM sys_ksh
WHERE sample_time > now() - INTERVAL '5 minutes'
GROUP BY 1, 2
ORDER BY 3 DESC
LIMIT 10;

-- 查看某段時間內執(zhí)行最慢的 SQL
SELECT query_id, query, calls, total_time, mean_time
FROM sys_ksh_statements
WHERE sample_time > now() - INTERVAL '1 hour'
ORDER BY mean_time DESC
LIMIT 10;

實時會話與鎖監(jiān)控

日常巡檢的時候經常要看當前有沒有長時間運行的事務、有沒有鎖等待。幾條常用查詢:

-- 當前活躍會話
SELECT pid, usename, application_name, client_addr,
       state, wait_event_type, wait_event,
       now() - query_start AS duration, query
FROM sys_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

-- 鎖等待分析
SELECT blocked.pid AS blocked_pid,
       blocked.query AS blocked_query,
       blocking.pid AS blocking_pid,
       blocking.query AS blocking_query,
       now() - blocked.query_start AS wait_duration
FROM sys_stat_activity blocked
JOIN sys_locks l ON blocked.pid = l.pid AND NOT l.granted
JOIN sys_locks granted ON l.locktype = granted.locktype
    AND l.database IS NOT DISTINCT FROM granted.database
    AND l.relation IS NOT DISTINCT FROM granted.relation
    AND granted.granted = true
JOIN sys_stat_activity blocking ON granted.pid = blocking.pid
WHERE blocked.pid != blocking.pid;

-- 長時間未提交的事務(超過 5 分鐘)
SELECT pid, usename, now() - xact_start AS xact_duration, query
FROM sys_stat_activity
WHERE state = 'idle in transaction'
  AND now() - xact_start > INTERVAL '5 minutes'
ORDER BY xact_duration DESC;

idle in transaction 這種狀態(tài)特別值得警惕。事務打開了但沒有提交,一直掛著,持有的鎖不釋放。如果掛太久,VACUUM 都沒法回收死元組,表會越來越大。建議在 kingbase.conf 里設個超時:

idle_in_transaction_session_timeout = 300000  -- 5 分鐘,單位毫秒

磁盤和表空間監(jiān)控

寫個簡單的巡檢腳本定期跑一下,把表空間使用情況、大表列表、索引膨脹率這些都采集出來。不用搞得太復雜,shell 腳本加上 ksql 就夠用:

#!/bin/bash
# db_check.sh - 簡單巡檢腳本
DATA_DIR="/data/kingbase/data"
KSQL="ksql -U system -d production -t -A -c"

echo "===== 磁盤使用 ====="
df -h $DATA_DIR

echo ""
echo "===== 數據庫大小 ====="
$KSQL "SELECT datname, sys_size_pretty(sys_database_size(datname))
       FROM sys_database ORDER BY sys_database_size(datname) DESC;"

echo ""
echo "===== TOP 10 大表 ====="
$KSQL "SELECT schemaname||'.'||relname AS table_name,
       sys_size_pretty(sys_total_relation_size(relid)) AS total_size,
       n_live_tup AS row_count
       FROM sys_stat_user_tables
       ORDER BY sys_total_relation_size(relid) DESC LIMIT 10;"

echo ""
echo "===== 未使用的索引 ====="
$KSQL "SELECT schemaname||'.'||indexrelname AS index_name,
       sys_size_pretty(sys_relation_size(indexrelid)) AS size,
       idx_scan AS scan_count
       FROM sys_stat_user_indexes
       WHERE idx_scan = 0
       ORDER BY sys_relation_size(indexrelid) DESC LIMIT 10;"

echo ""
echo "===== 表膨脹估算 ====="
$KSQL "SELECT schemaname||'.'||relname AS table_name,
       n_dead_tup AS dead_tuples,
       round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_ratio
       FROM sys_stat_user_tables
       WHERE n_dead_tup > 10000
       ORDER BY n_dead_tup DESC LIMIT 10;"

這種腳本配合 crontab 每天跑一次,結果發(fā)個郵件或者寫到共享目錄里,巡檢效率會高很多。

常見問題與排查思路

最后記幾個實際遇到過的典型問題。

連接數打滿

應用突然連不上數據庫,報錯 “sorry, too many clients already”。第一反應是查 max_connections,但光加大這個參數治標不治本。

-- 看看到底是哪些連接占著
SELECT state, count(*) FROM sys_stat_activity GROUP BY state;
-- 看各個來源 IP 的連接數
SELECT client_addr, count(*) FROM sys_stat_activity
WHERE client_addr IS NOT NULL
GROUP BY client_addr ORDER BY 2 DESC;

常見原因有這么幾種:應用端連接池沒配好,連接泄漏了沒歸還;idle in transaction 的連接太多占著坑不干活;max_connections 本身設太小了。如果并發(fā)確實高,在前面擋一層連接池中間件比直接加 max_connections 靠譜得多。

慢查詢定位

用戶反饋某個功能特別慢。先在日志里找慢 SQL——前面配置了 log_min_duration_statement = 1000,超過 1 秒的查詢都會記到日志里。日志文件在數據目錄下的 sys_log 子目錄里,用 grep 搜 “duration” 關鍵字就能快速定位。當然,如果你的慢查詢閾值設得比較低(比如 500 毫秒),日志量會比較大,建議只在排查問題的時候臨時調低,排查完了改回來。

-- 也可以直接從視圖里查
SELECT query, calls, total_time, mean_time, rows
FROM sys_stat_statements
WHERE mean_time > 500
ORDER BY mean_time DESC
LIMIT 20;

拿到慢 SQL 之后用 EXPLAIN ANALYZE 看執(zhí)行計劃,重點關注是不是走了全表掃描、Nested Loop 嵌套層數是不是太多、有沒有臨時文件排序。大多數性能問題都是缺索引或者索引選錯了導致的。

-- 看執(zhí)行計劃
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT d.device_name, avg(s.temperature) AS avg_temp
FROM sensor_data s
JOIN device_info d ON s.device_id = d.id
WHERE s.record_time > now() - INTERVAL '7 days'
GROUP BY d.device_name
ORDER BY avg_temp DESC;

VACUUM 相關問題

KES 用 MVCC 機制管理數據版本,刪除和更新操作不會真正移除舊數據行,而是標記為死元組。VACUUM 負責回收這些死元組占用的空間。如果 VACUUM 跟不上寫入速度,表就會持續(xù)膨脹,查詢性能也會下降——因為掃描的時候要跳過大量的死元組,白白浪費 IO。

這個問題平時不容易發(fā)現,等到表膨脹得很厲害了才會暴露出來。我碰到過一個表,業(yè)務上每天大量更新,autovacuum 一直追不上寫入速度,半年下來表的物理大小漲了將近三倍,但實際有效數據行只多了 30%。

-- 查看哪些表需要 VACUUM
SELECT schemaname||'.'||relname AS table_name,
       n_dead_tup AS dead_tuples,
       n_live_tup AS live_tuples,
       last_vacuum, last_autovacuum
FROM sys_stat_user_tables
WHERE n_dead_tup > 10000
  AND n_dead_tup > n_live_tup * 0.1
ORDER BY n_dead_tup DESC;

-- 手動 VACUUM 某個表(帶分析)
VACUUM ANALYZE sensor_data;

-- 看 autovacuum 是否正常工作
SELECT pid, query, now() - query_start AS duration
FROM sys_stat_activity
WHERE query LIKE 'autovacuum%'
ORDER BY duration DESC;

autovacuum 一般不用手動干預,但對于寫入量特別大的表,默認的 autovacuum 參數可能不夠激進,可以適當調大 autovacuum_vacuum_scale_factor 和 autovacuum_analyze_scale_factor。

總結

這篇文章覆蓋了 KES 數據庫從安裝到日常運維的主要操作環(huán)節(jié)。部署環(huán)節(jié)的關鍵是環(huán)境初始化和參數調優(yōu),特別是內存參數和兼容模式的選擇,這兩項一旦定下來后面改動成本很高;安全方面三權分立和 TDE 是 KingbaseES 比較有特色的功能,政務和金融項目基本都要用上,審計日志的存儲規(guī)劃也要提前做好;備份恢復要形成制度,全量加增量的組合策略加上定期驗證,確保關鍵時刻真的能恢復出來;監(jiān)控診斷靠 KWR 和 KSH 這兩個內置工具就能搞定大部分場景,配合一個簡單的巡檢腳本基本夠用了。

KES 這幾年迭代速度挺快,從 V8 到 V9 在性能和易用性上都有明顯進步。用的過程中遇到問題多看官方文檔,文檔中心 help.kingbase.com.cn 上的內容還是比較全的。另外社區(qū)里也有不少實踐經驗可以參考,碰到坑的時候搜一搜往往能找到類似的解決思路。

數據庫運維這個活兒說到底就是"預防為主、治療為輔"。備份做好、監(jiān)控到位、定期巡檢,大部分問題都能在釀成事故之前處理掉。與其花三天時間恢復一個本可以避免的故障,不如每天花十分鐘看看監(jiān)控數據。這話雖然老生常談,但真正做到的人確實不多。共勉。

到此這篇關于KingbaseES數據庫開發(fā)運維:部署、安全、備份與監(jiān)控實戰(zhàn)的文章就介紹到這了,更多相關KingbaseES開發(fā)運維筆記內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

相關文章

  • 數據庫刪除完全重復和部分關鍵字段重復的記錄

    數據庫刪除完全重復和部分關鍵字段重復的記錄

    重復記錄分為兩種,第一種是完全重復的記錄,也就是所有字段均重復的記錄,第二種是部分關鍵字段重復的記錄,例如Name字段重復,而其它字段不一定重復或都重復。
    2008-05-05
  • 如何使用dbeaver遷移數據庫(含完整圖文教程)

    如何使用dbeaver遷移數據庫(含完整圖文教程)

    DBeaver提供了一系列豐富的數據庫操作功能,用戶可以通過圖形用戶界面執(zhí)行SQL查詢,這些查詢可以手動編寫或利用內置的編輯器自動完成,這篇文章主要介紹了如何使用dbeaver遷移數據庫的相關資料,需要的朋友可以參考下
    2026-04-04
  • 數據庫命名規(guī)范小結

    數據庫命名規(guī)范小結

    數據庫命名規(guī)范,在實際的數據庫開發(fā)中,需要注意。
    2009-03-03
  • 銀河麒麟V10安裝達夢8數據庫詳細操作過程及避坑

    銀河麒麟V10安裝達夢8數據庫詳細操作過程及避坑

    在數字化轉型的浪潮下,數據庫作為企業(yè)核心數據存儲與管理的基石,其安全性、穩(wěn)定性和自主可控性顯得尤為重要,這篇文章主要介紹了銀河麒麟V10安裝達夢8數據庫詳細操作過程及避坑的相關資料,需要的朋友可以參考下
    2026-04-04
  • Dbeaver如何從一個數據庫復制表到另外一個數據庫

    Dbeaver如何從一個數據庫復制表到另外一個數據庫

    在數據庫管理中,導出表是一項常見操作,可以通過特定的工具或數據庫自帶的功能實現,步驟包括:1.在數據庫管理軟件中找到需導出的表,右鍵選擇導出數據,2.選擇目標數據庫,并進行表映射設置,3.根據需求調整導出參數,4.執(zhí)行操作完成數據導出
    2024-10-10
  • 2024 Navicat Premium最新版簡體中文版激活永久圖文詳細教程(親測可用)

    2024 Navicat Premium最新版簡體中文版激活永久圖文詳細教程(親測可用)

    這篇文章主要介紹了2024 Navicat Premium最新版簡體中文版激活永久圖文詳細教程,文章通過圖文結合的方式給大家講解的非常詳細,具有一定的參考價值,需要的朋友可以參考下
    2024-09-09
  • Linux下mysql數據庫的創(chuàng)建導入導出 及一些基本指令

    Linux下mysql數據庫的創(chuàng)建導入導出 及一些基本指令

    這篇文章主要介紹了Linux數據庫的創(chuàng)建 導入導出 以及一些基本指令,需要的朋友可以參考下
    2019-08-08
  • 淺談數據庫事務四大特性

    淺談數據庫事務四大特性

    這篇文章主要介紹了淺談數據庫事務四大特性,小編覺得挺不錯的,這里分享給大家,供需要的朋友參考。
    2017-10-10
  • DBeaver連接GBase數據庫的簡單步驟記錄

    DBeaver連接GBase數據庫的簡單步驟記錄

    DBeaver數據庫連接工具,是我用了這么久最好用的一個數據庫連接工具,擁有的優(yōu)點,支持的數據庫多、快捷鍵很贊、導入導出數據非常方便,下面這篇文章主要給大家介紹了關于DBeaver連接GBase數據庫的簡單步驟,需要的朋友可以參考下
    2024-03-03
  • 從零開始用DataGrip的安裝及使用教程

    從零開始用DataGrip的安裝及使用教程

    這篇文章主要介紹了從零開始用DataGrip的安裝以及使用,本文通過圖文并茂的形式給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下
    2020-09-09

最新評論

丹东市| 温州市| 来凤县| 中阳县| 会泽县| 安阳县| 昭平县| 余庆县| 溧阳市| 马山县| 建德市| 交城县| 镇巴县| 皮山县| 凤庆县| 澄江县| 巴东县| 大连市| 定西市| 焦作市| 博湖县| 沂南县| 广东省| 环江| 普宁市| 辽阳县| 从江县| 湘潭市| 竹北市| 于都县| 延长县| 搜索| 丽水市| 鄂托克旗| 东方市| 阳山县| 浪卡子县| 宁安市| 巢湖市| 烟台市| 巴塘县|