KESの運用自動化とスクリプト体系の実践


KESの運用自動化とスクリプト体系の実践

前回は国産化に向けたフルスタックの移行・改修について解説しましたが、この章では日常の運用実務に焦点を当てます。多くの企業のDBAは、手動でのバックアップ、遅延SQLの1件ごとの確認、ディスクの手動チェック、パーティションの手動作成、障害発生後のセッションの手動調査など、毎日膨大な時間を反復作業に費やしています。手作業は効率が悪いだけでなく、チェック漏れ、バックアップの忘れ、操作ミスなどの本番環境におけるリスクも生じやすくなります。

私が行政、エネルギー、金融プロジェクトで蓄積した一連の自動化スクリプトを基に、本章では、巡回点検、バックアップ、パーティション分割、ログのクリーンアップ、障害アラート、セッションのクリーンアップという6つの高頻度運用シナリオについて、すぐに実行可能なスクリプトをすべてまとめました。併せて、定時タスクの展開方案、ログ保存規定、異常通知の設定も併せて提供します。全文は7,000字以上、 平易な言葉で解説した実践的な内容となっており、すべてのShellおよびPL/SQLスクリプトはKES V9R1C10に対応しており、麒麟、CentOS、統信システムで直接再利用可能です。導入後は、反復的な運用保守業務の80％をプログラムによる自動実行に任せることができます。

一、? 本章の学習ガイド

1.1 学習目標

  1. 運用自動化の全体像を構築し、巡回点検、バックアップ、アーカイブ、アラートの4大自動化モジュールの役割分担を明確にする
  2. Linux Shellによるバッチ運用スクリプトの作成を習得し、電科金倉環境の変数や接続ロジックに適応させる
  3. フルバックアップ／増分バックアップの自動化、期限切れバックアップの削除、バックアップ有効性検証といった一連の自動化プロセスを構築する
  4. パーティションの自動作成、過去のパーティションの分離アーカイブを実現し、毎月手動でDDLを実行する必要をなくす
  5. 定期点検スクリプトを構築し、ディスク、接続、ロック、遅延SQL、メイン遅延に関する点検レポートを自動出力する
  6. 異常時のメール／SMSアラートを設定し、データベース障害発生時に即座に運用担当者に通知

1.2 本章の要点

  • 電科金倉汎用環境変数スクリプト（全ツールで統一して呼び出し）
  • 自動バックアップ＋検証＋クリーンアップを統合したShellスクリプト
  • 月ごとのパーティションごとにPL/SQLによる自動事前作成を行う定時スクリプト
  • 毎日の全次元点検スクリプトとレポート出力
  • デッドロック、長時間セッション、ディスク満杯時の自動クリーンアップスクリプト
  • crontab定時タスクの標準化設定案

二、? なぜ運用自動化を行うのか？

まず、私が長年にわたり運用に携わってきた実体験から申し上げます。完全な手動運用には、避けられない3つの大きな欠点があります。第一に人件費の高さです。毎朝夕の定例点検、毎月のパーティション作成、深夜の手動バックアップなど、大量の反復作業が業務時間を大幅に消費します。第二に人為的ミスのリスクです。忙しさのあまりバックアップを忘れたり、ディスクのアラートを見落としたり、パーティションを手動で削除する際に業務用テーブルを誤って削除したりするなど、本番環境での事故は後を絶ちません。第三に、対応の遅れです。深夜にデータベースのディスク容量が満杯になったり、マスター・スレーブ間の同期が中断したりしても、常駐者がいない状況では翌日の出勤まで発見されず、障害の継続時間が数時間にも及んでしまいます。

運用自動化の中核となるロジックは、「標準化されたスクリプト＋定時ジョブ＋異常アラート」です。固定的で反復的、かつ技術的難易度の低い操作をすべてサーバーに自動実行させ、DBAはスクリプトから通知される異常アラートの処理に専念し、パフォーマンスの最適化やアーキテクチャの改良といった中核業務に注力できます。

本章のすべてのスクリプトは本番環境で長期にわたり検証済みであり、構文エラーや権限異常の問題は存在しません。IP、パスワード、ディレクトリなどの少数のパラメータを変更するだけで、本番環境での使用が可能です。

三、? 基本共通環境設定スクリプト

すべての自動化スクリプトは、データベース接続、バックアップパス、ログパスなどの共通パラメータを再利用します。まず共通設定ファイルを作成し、後続のスクリプトで統一して参照することで、IPアドレスやパスワードを複数箇所で修正する手間を省きます。

新規ファイルkes_env.shを作成し、グローバル変数を一元的に格納します：

#!/bin/bash
# 電科金倉のグローバル環境設定スクリプト
# データベース接続情報
DB_HOST=127.0.0.1
DB_PORT=54321
DB_USER=sys
DB_PWD=「Kingbase@2026#」
DB_NAME=student_manager
# バックアップ保存のルートディレクトリ
BACK_ROOT=/data/kes_backup
# スクリプト実行ログディレクトリ
SCRIPT_LOG=/data/script_log
# アーカイブパーティションの保存ディレクトリ
COLD_TABLESPACE=/opt/KingbaseCold
# アラート受信メールアドレス
ALERT_MAIL=admin@gov.cn

# ディレクトリを初期化。存在しない場合は自動的に作成
mkdir -p ${BACK_ROOT}
mkdir -p ${SCRIPT_LOG}
# パスワードを環境変数にエクスポートし、毎回パスワードを入力する手間を省く
export KINGBASE_PASSWORD=${DB_PWD}
# ログの日時形式
CUR_DATE=$(date +%Y%m%d)
CUR_DATETIME=$(date +%Y%m%d_%H%M%S)

使用方法：任意のスクリプトの先頭行で設定ファイルをインポート

source /opt/script/kes_env.sh

⚠️ セキュリティ上の注意：本番環境のスクリプトファイルの権限を600に設定し、root/kingbaseユーザーのみが読み取り可能にすることで、パスワードの漏洩を防止します

chmod 600 /opt/script/kes_env.sh
chown kingbase:kingbase /opt/script/kes_env.sh

4. 完全自動バックアップ統合スクリプト

手動バックアップの最大のリスクは、バックアップファイルの破損や、期限切れファイルが蓄積してディスク容量を圧迫することです。このスクリプトは、「バックアップの自動エクスポート→圧縮保存→バックアップの有効性チェック→7日以上経過した期限切れファイルの自動削除→バックアップ異常時のメールアラート」という完全なループを実現します。

スクリプトファイル名kes_auto_backup.sh

#!/bin/bash
source /opt/script/kes_env.sh
# 今回のバックアップファイル名
BACK_FILE=${BACK_ROOT}/full_${DB_NAME}_${CUR_DATETIME}.sql.gz
LOG_FILE=${SCRIPT_LOG}/backup_${CUR_DATE}.log

# データベース全体の論理バックアップを開始
echo 「==========${CUR_DATETIME} データベース全体のバックアップを開始==========」 >> ${LOG_FILE}
sys_dump -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} | gzip > ${BACK_FILE}

# バックアップファイルが生成されたか確認
if [ -f ${BACK_FILE} ]; then
    echo 「バックアップファイルの生成に成功しました：${BACK_FILE}」 >> ${LOG_FILE}
    # バックアップの有効性チェック：一時的に解凍し、空のデータベースへのインポートを試行
    
gunzip -c ${BACK_FILE} | ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -c 「\\q」
    if [ $? -eq 0 ]; then
        echo 「バックアップファイルの検証に成功しました」 >> ${LOG_FILE}
    
else
        echo 「バックアップファイルが破損しています。直ちにアラートを送信します」 >> ${LOG_FILE}
        echo 「データベース${DB_NAME}のバックアップ検証に失敗しました。至急確認してください」 | mail -s 「【金倉バックアップ障害】」 ${ALERT_MAIL}
    fi
else
    echo 「バックアップの実行に失敗しました。バックアップファイルがありません」 >> $ {LOG_FILE}
    echo 「データベース${DB_NAME}のバックアップ実行に失敗しました。至急確認してください」 | mail -s 「【金倉バックアップ障害】」 ${ALERT_MAIL}
fi

# 7日前のバックアップファイルを自動削除
find ${BACK_ROOT} -name 「full_*.sql.gz」 -mtime +7 -delete
echo 『7日前の期限切れバックアップを削除しました』 >> ${LOG_FILE}
echo 「==========バックアップ処理終了==========」 >> ${LOG_FILE}

定期デプロイ

毎日午前2時にバックアップを自動実行、crontabを修正：

crontab -e
0 2 * * * /opt/script/kes_auto_backup.sh

スクリプトの拡張

特定のテーブルのみを定期的にバックアップしたり、物理バックアップを行ったりする場合は、sys_dumpをsys_basebackupに置き換えるだけで、その他のクリーンアップやアラート処理のロジックはそのまま再利用できます。

5. パーティションの自動作成スケジュールスクリプト

前回の第10回では、RANGEによる月単位のパーティション分割について解説しました。手動で毎月パーティションを新規作成するのは作業負荷が大きく、忘れがちで、翌月のデータ挿入時にエラーが発生する原因にもなります。ここでは、2つのソリューションを紹介します：ShellからPL/SQLを呼び出す方法と、純粋なストアドプロシージャによる定期実行です。

ソリューション1：今後3ヶ月分のパーティションを自動的に事前作成する（ストアドプロシージャ）

CREATE OR REPLACE PROCEDURE proc_auto_create_partition()
AS
    v_start DATE;
    v_end DATE;
    v_part_name VARCHAR(100);
    v_sql VARCHAR(1000);
BEGIN
    -- 今後3ヶ月分のパーティションをループ処理で生成
    
FOR i IN 1..3 LOOP
        v_start := TRUNC(SYSDATE,『MONTH』) + INTERVAL 『1 MONTH』 * i;
        v_end := v_start + INTERVAL 『1 MONTH』;
        v_part_name := 『t_order_log_』||TO_CHAR(v_start,『YYYYMM』);
        
v_sql := 『CREATE TABLE IF NOT EXISTS 』||v_part_name||『 PARTITION OF t_order_log
        FOR VALUES FROM (』『』||v_start||『』『) TO (』『』||v_end||『』『);』;
        EXECUTE IMMEDIATE v_sql;
    END LOOP;
END;
/

案2：シェルによるストアドプロシージャの定期呼び出し、実行完了時のログ記録

スクリプトcreate_part.sh

#!/bin/bash
source /opt/script/kes_env.sh
LOG_FILE=${SCRIPT_LOG}/partition_${CUR_DATE}.log
echo 「====${CUR_DATETIME} 自動パーティション作成の実行====」 >> ${LOG_FILE}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「CALL proc_auto_create_partition();」
if [ $? -eq 0 ]; then
    echo 「パーティションの事前作成が完了しました」 >> ${LOG_FILE}
else
    echo 「パーティションの作成に失敗しました。アラートを送信します」 | mail -s 「【パーティション作成エラー】」 ${ALERT_MAIL}
fi

スケジュール設定：毎月1日午前3時に実行

0 3 1 * * /opt/script/create_part.sh

過去のパーティションを自動的に分離・アーカイブする拡張スクリプト

パーティションの作成から6ヶ月以上経過しているかどうかを判定し、自動的にDETACHしてコールドテーブルスペースへ移行する機能を追加。ホットデータとコールドデータの自動分離を実現し、手動操作は不要です。

六、? 毎日の全次元自動巡回点検スクリプト

これは運用の中核となるスクリプトであり、ディスク使用率、接続数、長時間実行されるSQL、ロック待機、プライマリ・スタンバイ間の遅延、大規模テーブルスペースの使用状況を自動的にチェックし、実行完了後に点検レポートを生成するとともに、異常項目については自動的にメールでアラートを送信します。

スクリプトkes_daily_check.sh

#!/bin/bash
source /opt/script/kes_env.sh
REPORT=${SCRIPT_LOG}/daily_check_${CUR_DATE}.txt
echo 「====電科金倉 毎日点検レポート ${CUR_DATETIME}====」 > ${REPORT}

# 1. ディスク使用率のチェック
echo -e 「\\n1. サーバーのディスク情報：」 >> ${REPORT}
df -h >> ${REPORT}
DISK_USED=$(df / | grep -v Filesystem | awk 『{print $5}』 | sed 『s/%//』)
if [ ${DISK_USED} -ge 80 ]; then
    
echo 「【アラート】システムディスク使用率が80%を超えました！」 >> ${REPORT}
    echo 「データベースサーバーのディスク使用率は${DISK_USED}%です。速やかにクリーンアップまたは容量拡張を行ってください」 | mail -s 「【ディスクアラート】」 ${ALERT_MAIL}
fi

# 2. 現在のデータベースの総接続数
echo -e 「\\n2. 現在のオンラインセッション数：」 >> ${REPORT}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「SELECT count(*) AS 総接続数 FROM sys_stat_activity;」 >> ${REPORT}

# 3. 30秒以上かかっているSQL
echo -e 「\\n3. 30秒以上かかっているSQL：」 >> ${REPORT}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「
SELECT pid, usename, now() - query_start AS run_time, query
FROM sys_stat_activity
WHERE now() - query_start > 『30 seconds』::interval AND state = 『active』;」 >> ${REPORT}

# 4. ロック待機によるセッションのブロック
echo -e 「\\n4. ロック待機によるセッションのブロック：」 >> ${REPORT}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「
SELECT blocking_pid,pid,usename,query FROM sys_stat_activity WHERE blocking_pid<>0;」 >> ${REPORT}

# 5. マスター・スレーブ同期の遅延（単一インスタンスで予備データベースがない場合は自動的に無視）
echo -e 「\\n5. マスター・スレーブ同期の状態：」 >> ${REPORT}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「SELECT pid,state,write_lag FROM sys_stat_replication;」 >> ${REPORT}

# 6. ディスク使用量トップ10のテーブル
echo -e 「\\n6. ディスク使用量上位10のデータテーブル：」 >> ${REPORT}
ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c "
SELECT relname,pg_relation_size(relname)/1024/1024 AS size_mb
FROM sys_class WHERE relkind=『r』 ORDER BY size_mb DESC LIMIT 10;" >> ${REPORT}

echo -e 「\\n====点検レポートの生成が完了しました====」 >> ${REPORT}
# 毎日8時に完全なレポートをメールに自動送信
cat ${REPORT} | mail -s 「【金倉 毎日の点検レポート】${CUR_DATE}」 ${ALERT_MAIL}

スケジュール設定：毎日午前8時に実行され、出勤すると前日の完全な点検結果を受け取れます

0 8 * * * /opt/script/kes_daily_check.sh

七、 ⚡ 障害自動処理スクリプト：長時間セッション、デッドロックの自動クリーンアップ

業務のピーク時には、大量のフリーズしたセッションやデッドロックが蓄積され、手動での処理を待つ間に業務が継続的に阻害されます。このスクリプトは、10分以上実行されているセッションやデッドロックが発生しているセッションを自動的に識別して終了させ、障害の影響時間を短縮します。

スクリプトkill_long_session.sh

#!/bin/bash
source /opt/script/kes_env.sh
LOG=${SCRIPT_LOG}/kill_session_${CUR_DATE}.log
echo 「====${CUR_DATETIME} 長時間セッションクリーンアップタスク====」 >> $ {LOG}

# 10分以上実行中のセッションのPIDを照会し、一括で終了させる
SQL=「SELECT pid FROM sys_stat_activity
WHERE state=『active』 AND now()-query_start > 『10 minutes』::interval;」
# PIDリストを読み込む
PID_LIST=$(ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -t -c 「${SQL}」)
for pid in ${PID_LIST}
do
    if [ -n 「${pid}」 ]; then
        ksql -h ${DB_HOST} -p ${DB_PORT} -U ${DB_USER} -d ${DB_NAME} -c 「SELECT pg_terminate_backend(${pid});」
        
echo 「ハングしたセッションのPID：${pid}を終了しました」 >> ${LOG}
    fi
done

スケジュール：30分ごとに1回自動実行し、ブロックされたセッションを能動的にクリーンアップ

*/30 * * * /opt/script/kill_long_session.sh

8. ログの自動削除ソリューション

データベースの稼働ログ、監査ログ、スクリプトログが無限に増加することは、ディスク容量が満杯になる主な原因の一つです。自動ローテーションと定時削除スクリプトを組み合わせることで、二重の保護を実現します。

  1. データベース設定ファイルでログの自動分割を有効化
log_rotation_size=1024MB
log_rotation_age=1d
  1. クリーンアップスクリプトclean_log.sh。30日以上経過したログファイルを削除
#!/bin/bash
source /opt/script/kes_env.sh
# データベース実行ログのクリーンアップ
find /opt/KingbaseData/sys_log -name 「*.log」 -mtime +30 -delete
# スクリプト自身のログのクリーンアップ
find ${SCRIPT_LOG} -name 「*.log」 -mtime +30 -delete
echo 「30日以上経過したログを削除しました」 >> ${SCRIPT_LOG}/clean_log_${CUR_DATE}.log

毎日午前4時にクリーンアップを実行：

0 4 * * * /opt/script/clean_log.sh

九、? 実際の自動化運用事例

9.1 プロジェクトの背景

ある地級市の行政クラウドプラットフォームでは、2セットのプライマリ・スタンバイ金倉クラスタがあり、3名の運用担当者が20セット以上の業務システムを同時に担当していました。手動による巡回点検やバックアップの作業負荷が非常に大きく、バックアップの漏れやディスクアラートの発見遅延が頻繁に発生していました。

9.2 導入・改善案

  1. /opt/scriptスクリプトディレクトリを統一して構築し、環境変数、バックアップ、巡回点検、パーティション分割、ログ削除の全スクリプトを展開；
  2. バックアップ、巡回点検、パーティション分割、セッション削除、ログ削除を網羅するcrontab定時タスク一式を設定；
  3. メールアラートを設定し、ディスク容量満杯、バックアップ失敗、パーティション作成異常、長時間セッションをすべてリアルタイムで通知；
  4. 毎月の新規履歴パーティション作成およびアーカイブ処理を完全に自動化し、手動介入を不要に。

9.3 導入効果

✅ 手動による反復的な運用作業量が80％削減；

✅ バックアップの漏れや、ディスク満杯の未発見といった問題は一度も発生していない；

✅ 業務の遅延やロックによるセッションのブロックを自動で解消し、平均復旧時間を大幅に短縮；

✅ 毎日自動的に点検レポートを生成し、運用レビューや情報セキュリティ基準の監査にそのまま活用可能；

✅ 導入から2年間、スクリプトは安定して稼働しており、スクリプトの構文や権限に関する障害は発生していません。

10. ⚠️ 自動化スクリプトの落とし穴を避けるための要点

  1. スクリプト内のデータベースの平文パスワードについては、ファイル権限を厳格に600に設定し、一般ユーザーによる読み取りを禁止する必要があります；
  2. 定時タスクはKingbaseの一般ユーザーで実行し、rootによるデータベースへの直接接続を禁止；
  3. バックアップの検証は省略不可。バックアップのみ行って検証を行わないことは、バックアップをしていないのと同じ；
  4. ディスククリーンアップスクリプトに閾値判定を追加し、使用中のログやバックアップの誤削除を防止；
  5. セッション終了スクリプトの時間を短く設定しすぎないようにし、正常な低速クエリレポートが誤って終了されるのを防ぐ；
  6. 定時タスクは業務のピーク時間を避け、バックアップやDDLスクリプトは可能な限り未明の閑散時間帯に実行する；
  7. サーバーのIP変更やデータベースパスワードの変更後は、kes_env.shのグローバル設定を同期して更新し、すべてのスクリプトに統一して反映させる。