データーベース管理

HOMELinuxtips > データーベース管理

データーベース管理:記事リスト

データーベース管理のカテゴリーには以下の記事がリストされています。

postgresql.confのメモリ設定を決める方法|shared_buffersとwork_memの見積もりと反映手順

「PostgreSQLをLinuxにインストールしたのに、クエリが遅い。設定を確認すると shared_buffers が 128MB のまま。適切な値はどう決めればいいのか?」

インストール直後の postgresql.conf は、古い低スペック環境でも起動できるよう極めて保守的なデフォルト値になっています。実務のLinuxサーバーでそのまま使うと、DBが必要なページをディスクから毎回読み込む状態が続き、クエリのたびにI/Oが走ってパフォーマンスが頭打ちになります。

この記事では、postgresql.conf で調整すべき主要なメモリパラメータ(shared_buffers・work_mem・effective_cache_size・maintenance_work_mem)の見積もり計算式と、設定を反映する手順を実機の出力例とあわせて解説します。
動作確認環境:RHEL 9.4 / Ubuntu 24.04 LTS(PostgreSQL 16)

この記事のポイント

・shared_buffers は「搭載RAM ÷ 4」が実務の出発点(デフォルト128MBは小さすぎる)
・work_mem は接続数とクエリの複雑さで倍増するため、計算式で保守的に見積もる
・shared_buffers の変更には再起動が必要、work_mem はリロードだけで反映できる
・設定後は SHOW 文または pg_settings ビューで反映を必ず確認する

続きを読む "postgresql.confのメモリ設定を決める方法|shared_buffersとwork_memの見積もりと反映手順"

PostgreSQLのストリーミングレプリケーションを構築する手順|pg_basebackupからスタンバイ昇格まで

「pg_basebackupは正常終了したのに、プライマリ側のpg_stat_replicationに何も表示されない」「PostgreSQL 12以降でrecovery.confが廃止されたと聞いたが、代わりに何を設定すればよいのか分からない」——こうした疑問をそのままにしていると、本番環境のレプリケーション構築で同じ場所で詰まることになります。

PostgreSQLのストリーミングレプリケーションは、WAL(Write-Ahead Log)をプライマリからスタンバイへリアルタイムで転送し続け、データの複製を維持する仕組みです。RDS・Aurora・Cloud SQLのようなマネージドサービスがボタン1つでリードレプリカを作れるのに対し、Linuxサーバーを自前で運用する環境では、設定の意味を理解していないと障害時に即座に対処できません。

この記事では、Rocky Linux 9 / PostgreSQL 16 の2台構成(プライマリ1台・スタンバイ1台)を例に、ストリーミングレプリケーションの全手順を実際のコマンド出力とともに解説します。pg_basebackupでのベースバックアップ取得、standby.signalによる自動レプリケーション開始、pg_stat_replicationでの同期確認、そして障害時のスタンバイ昇格(フェイルオーバー)まで一気通貫でカバーします。

この記事のポイント

・pg_basebackup -R でstandby.signalとprimary_conninfoが自動生成される
・プライマリ側はwal_level・max_wal_senders・pg_hba.confの3か所を設定する
・pg_stat_replicationのstateが「streaming」になれば同期成立の合図
・スタンバイ昇格はpg_ctl promoteまたはSELECT pg_promote()で実行できる

続きを読む "PostgreSQLのストリーミングレプリケーションを構築する手順|pg_basebackupからスタンバイ昇格まで"

PostgreSQLのVACUUMとautovacuum運用設計|テーブル肥大化とXID周回を防ぐ設定の考え方

「autovacuumを有効にしているのに、テーブルがどんどん肥大化していく」「VACUUM FULLをかけたら本番テーブルがロックされてサービスが止まった」「XID周回という言葉を聞いたが、自分のサーバーは大丈夫なのか不安だ」

PostgreSQLを本番環境で運用し始めると、こうした問題に直面します。原因のほとんどは、PostgreSQLのMVCC(マルチバージョン並行性制御)の仕組みとVACUUMの役割を体系的に理解していないことです。

この記事では、VACUUMとautovacuumの動作原理を基礎から解説し、テーブル肥大化とXID周回(Wraparound)障害を防ぐ実践的な設定方法を紹介します。Rocky Linux 9 / Ubuntu 24.04上のPostgreSQL 16で動作確認しています。

この記事のポイント

・VACUUMはデッドタプルを再利用可能にし、VACUUM FULLは物理圧縮するが排他ロックが必要
・autovacuumの起動条件はthreshold + scale_factor × 行数で決まる
・XID周回障害を防ぐにはage(relfrozenxid)を定期監視してFreeze VACUUMを計画的に実行
・大量更新テーブルはALTER TABLEでautovacuumパラメータをテーブル単位で上書きする

続きを読む "PostgreSQLのVACUUMとautovacuum運用設計|テーブル肥大化とXID周回を防ぐ設定の考え方"

PostgreSQLをpg_dumpとpg_restoreでバックアップする手順|論理バックアップの取得と復元の実務

「pg_dumpでバックアップを取っているはずなのに、復元できなかった」「カスタム形式とプレーンSQL、どちらを使えばいいのか迷う」——PostgreSQLのバックアップ・リストア手順で悩む現場エンジニアは少なくないはずです。

PostgreSQLには標準で pg_dumppg_restore というツールが付属しています。MySQLの mysqldump に相当する論理バックアップツールですが、カスタム形式(-Fc)や並列リストア(-j)など、より柔軟な運用オプションを備えています。

この記事では、pg_dump / pg_restore の実践的な使い方をRHEL 9.4 / Ubuntu 24.04 LTS(PostgreSQL 16)の実環境出力例を交えて解説します。単一DBのダンプから全DB一括バックアップ(pg_dumpall)・cronによる自動化・別サーバーへの移行・リストア失敗時の対処まで網羅します。

この記事のポイント

・pg_dump -Fc(カスタム形式)が本番運用での推奨フォーマット
・pg_restore -j N で並列リストアするとリストア時間を大幅短縮できる
・全DBを一括バックアップするにはpg_dumpallを使う
・cronで自動化する際は.pgpassファイルでパスワードを安全に管理する

続きを読む "PostgreSQLをpg_dumpとpg_restoreでバックアップする手順|論理バックアップの取得と復元の実務"

pg_hba.confで接続認証を設計する方法|PostgreSQLに接続できない原因の切り分けとscram-sha-256設定

FATAL: no pg_hba.conf entry for host "192.168.1.100", user "appuser", database "mydb"」というエラーが出てPostgreSQLへの接続が通らない。そんなトラブルに直面したことがあるエンジニアは少なくないはずです。

PostgreSQLはすべての接続を pg_hba.conf(Host-Based Authentication)というファイルで管理しています。このファイルに一致するルールが存在しない限り、どれだけ正しいパスワードを入力しても接続は拒否されます。

この記事では、pg_hba.confの構造・認証方式の種類・scram-sha-256の設定手順を、RHEL 9.4 / Ubuntu 24.04 LTSの実環境出力例を交えて解説します。接続できない原因をFATALエラーメッセージ別に切り分けるフローも紹介します。

この記事のポイント

・pg_hba.confのエントリが一致しない限り接続は即拒否される
・PostgreSQL 10以降の推奨認証はscram-sha-256(md5は非推奨)
・接続FATALエラーはメッセージ文言で原因をすぐ特定できる
・設定変更後は再起動不要。pg_ctl reloadで即時反映できる

続きを読む "pg_hba.confで接続認証を設計する方法|PostgreSQLに接続できない原因の切り分けとscram-sha-256設定"

psqlでロールとデータベースを管理する方法|postgresユーザーへの切り替えと権限付与の基本

「PostgreSQLにアプリ用のユーザーを作ったのに、テーブルを操作しようとするとpermission deniedになる」
「psqlで\duコマンドを打っても、どのロールに何の権限があるのかよく分からない」

PostgreSQLのロール管理は、MySQLのユーザー管理とは設計思想が違うため、初めて触ると戸惑いやすいポイントが多いです。

この記事では、Linux上のPostgreSQLサーバーでpostgresユーザーへの切り替え・psqlへの接続・ロール作成・権限付与・権限確認・よくあるエラー対処を一通り解説します。RHEL 9系 / Rocky Linux 9 / Ubuntu 24.04 LTSで動作確認した手順です。

この記事のポイント

・psql接続は「su - postgres → psql」の2ステップが基本
・CREATE ROLE 名前 WITH LOGIN PASSWORD でアプリ用ロールを作る
・権限付与はCONNECT→USAGE→テーブル権限の3段階で行う
・PostgreSQL 15以降はpublicスキーマのデフォルトCREATE権限が変わった

続きを読む "psqlでロールとデータベースを管理する方法|postgresユーザーへの切り替えと権限付与の基本"

MySQLのデータディレクトリを別ディスクへ移設する手順|datadir変更とSELinuxラベルの再設定

「MySQLのデータディレクトリを別ディスクへ移設したら、起動しなくなった」

このトラブルの原因として最も多いのが、SELinuxのファイルコンテキスト(ラベル)の設定漏れです。RHEL 9・Rocky Linux 9 など SELinux が Enforcing モードで動作している環境では、新しいパスに正しいラベルがなければ mysqld はアクセスを拒否されて起動できません。単純にファイルをコピーするだけでは不十分なのです。

この記事では、Linux サーバー上の MySQL 8.0 を対象に、datadir を別ディスクへ移設する全手順を解説します。動作確認環境は Rocky Linux 9.4(MySQL 8.0.36)です。

この記事のポイント

・datadir 変更後に SELinux ラベルを付け直さないと mysqld は起動しない
・semanage fcontext -a -t mysqld_db_t でラベル登録、restorecon -Rv で実際に適用する
・データコピーは rsync -av /var/lib/mysql/ /data/mysql/ で実施(末尾スラッシュ必須)
・作業前に mysqldump で全データのバックアップを取ってから進めること

続きを読む "MySQLのデータディレクトリを別ディスクへ移設する手順|datadir変更とSELinuxラベルの再設定"

mysqlbinlogでMySQLをポイントインタイムリカバリする方法|誤操作直前まで戻す復旧手順

「昨夜のバッチがWHERE句なしでDELETE文を実行してしまった」「開発者がうっかりDROP TABLEを本番で実行した」——こんな連絡が深夜に来たとき、手元にバイナリログとフルバックアップがあれば、誤操作の直前まで巻き戻すことができます。

この記事では、mysqlbinlogコマンドを使ったMySQLのポイントインタイムリカバリ(PITR)の手順を、実際のコマンド出力とともに解説します。フルバックアップのリストアを基点に、バイナリログから誤操作直前のポジションを特定し、差分を再適用するまでの一連の流れを網羅します。

実行環境:MySQL 8.0.36 / Rocky Linux 9.4 で動作確認済み。MySQL 5.7でも基本手順は同じです。

この記事のポイント

・mysqlbinlog + フルバックアップで誤操作直前まで復旧できる
・--stop-position でDROP/DELETE文だけをスキップして再適用できる
・バイナリログが期限切れで削除されると復旧不可能になる
・ROW形式のバイナリログ確認には --base64-output=DECODE-ROWS が必要

続きを読む "mysqlbinlogでMySQLをポイントインタイムリカバリする方法|誤操作直前まで戻す復旧手順"

MySQLのレプリケーションをLinuxサーバー2台で構築する手順|binlogとGTIDによるソース・レプリカ設定

「MySQLのレプリケーションを設定しようとしたら、binlogポジションとGTIDのどちらを使えばよいか迷っている」「CHANGE MASTER TOとCHANGE REPLICATION SOURCE TOのどちらが正しいのかわからない」——こういった質問をセミナー受講生からよく受けます。

MySQLのレプリケーションは、ソースサーバーのデータをリアルタイムでレプリカサーバーへ自動同期する機能です。読み取り負荷の分散や、障害発生時のフェイルオーバー準備として、Linuxで自前運用する現場では定番の構成です。

この記事では、Rocky Linux 9(RHEL 9互換)上のMySQL 8.4を対象に、binlogポジション方式とGTID方式、2パターンのレプリケーション構築手順を実機コマンドの出力例とともに解説します。my.cnfの設定・レプリケーション専用ユーザーの作成・CHANGE REPLICATION SOURCEの実行・SHOW REPLICA STATUSによる確認まで、一通りカバーします。

この記事のポイント

・MySQLレプリケーションはbinlogを介してソースからレプリカへ更新を自動同期する仕組み
・binlogポジション方式はFile名+位置で同期、GTID方式は一意IDで自動追跡する
・MySQL 8.4ではCHANGE MASTER TO等の旧構文が廃止。新コマンドへの対応が必須
・SHOW REPLICA STATUSでIO/SQLスレッド両方がYesなら正常動作している

続きを読む "MySQLのレプリケーションをLinuxサーバー2台で構築する手順|binlogとGTIDによるソース・レプリカ設定"

「Too many connections」でMySQLに接続できないときの対処|接続上限の見直しとコネクション滞留の調査

「MySQLに接続しようとしたら、突然つながらなくなった」
「アプリのエラーログに Too many connections と出て、サービスが止まった」

本番稼働中に ERROR 1040 (HY000): Too many connections が発生すると、原因の特定と対処を素早くやらなければなりません。MySQLサーバーが受け入れられる同時接続数の上限に達すると、新しい接続はすべて拒否されます。アプリケーションのユーザーには「503エラー」や「接続タイムアウト」として見えているはずです。

この記事では、too many connections mysql エラーの原因と対処法を順を追って解説します。接続数の確認コマンド(SHOW VARIABLES / SHOW STATUS)、即時の上限引き上げ(SET GLOBAL)、my.cnfへの恒久設定、ゾンビ接続の調査と強制切断(SHOW PROCESSLIST / KILL)、アプリ側のコネクション管理改善まで、RHEL 9.4 / Ubuntu 24.04 LTS で動作確認した内容をもとに説明します。

この記事のポイント

・「Too many connections」は max_connections 上限到達で発生する
・SET GLOBAL max_connections = 値; で再起動なしに即時変更できる
・ゾンビ接続は SHOW PROCESSLIST で特定し KILL コマンドで切断する
・恒久対処は my.cnf の max_connections と wait_timeout のセット設定が基本

続きを読む "「Too many connections」でMySQLに接続できないときの対処|接続上限の見直しとコネクション滞留の調査"

my.cnfのチューニング設計|innodb_buffer_pool_sizeとmax_connectionsを実メモリから決める

「MySQLが重い。でもmy.cnfをどこから触ればいいかわからない」
そう感じていませんか。MySQLのパフォーマンス問題の多くは、インストール直後のデフォルト設定のままmy.cnfが放置されていることが原因です。デフォルト値は非常に保守的な設定になっており、現代のサーバーのメモリを全く活かしきれていません。

この記事では、my.cnfチューニングの核心であるinnodb_buffer_pool_sizemax_connectionsの正しい設定方法を、RAM 4GB・8GB・16GBの3パターンで具体的な数値を交えて解説します。チューニング後の効果検証方法(SHOW STATUS)、よくある設定ミスと対処法も合わせて解説しますので、MySQL/MariaDB両方の実務に対応できます。

この記事のポイント

・innodb_buffer_pool_sizeは「空きRAMの70~80%」が実務のセオリー
・max_connectionsはper-threadバッファと掛け算で上限メモリを算出して決める
・MySQL 8.0ではquery_cache_sizeは廃止。MariaDBとの違いに注意
・SHOW STATUSのヒット率でバッファプールの効果を定量的に確認できる

続きを読む "my.cnfのチューニング設計|innodb_buffer_pool_sizeとmax_connectionsを実メモリから決める"

PostgreSQLをPGDGリポジトリからLinuxへ導入する手順|initdbとサービス起動・初期ロール設定まで

「LinuxサーバーにPostgreSQLを導入しようとしたら、OSのデフォルトリポジトリにある版が古くて困っている」
RHEL9のAppStreamに収録されているのはPostgreSQL 13系、Ubuntu 22.04には14系と、現時点では2世代~3世代古いバージョンがデフォルトです。かといって、ソースからビルドするのは運用コストが高すぎる。

この記事では、postgresql インストール linux pgdg の正攻法として、PostgreSQL公式のPGDGリポジトリを使ってRHEL9/Rocky Linux 9とUbuntu 24.04 LTSに最新版を導入する手順を解説します。initdbによるデータベースクラスタの初期化、systemctlでのサービス起動・自動起動設定、そして初回接続に欠かせない初期ロール設定(pg_hba.conf)まで、「繋がる状態」まで一気に持っていきます。

この記事のポイント

・PGDGリポジトリを使えばLinuxに最新版PostgreSQLを導入できる
・RHEL9系はdnf module disable postgresqlの実行が必須
・Ubuntu 24.04 LTSはインストール後に自動でクラスタ初期化される
・pg_hba.confを編集してパスワード認証を有効化する

続きを読む "PostgreSQLをPGDGリポジトリからLinuxへ導入する手順|initdbとサービス起動・初期ロール設定まで"

MySQLで指定したカラム名を持つテーブルを検索する|information_schemaを使ったDB横断検索

「特定のカラム名を持つテーブルが、どのDBのどこに存在するかわからない」
「テーブル定義を直接見ても、目的のカラムが見つからない」
DBA経験のあるエンジニアなら一度は遭遇する場面です。

この記事では、MySQLで指定したカラム名を持つテーブルを検索する方法を、information_schemaを使った実コマンド付きで解説します。MySQL 5.7 / MySQL 8.0 / MariaDB 10.x で動作確認済みのSQLです。

この記事のポイント

・information_schema.columnsをSELECTすればMySQL内のカラム検索が一発でできる
・table_schemaを条件に加えると、特定データベースに絞った検索が可能
・LIKE演算子で部分一致検索(user_%・%_idなど)にも対応
・MariaDB / MySQL 8.0 でも同じSQLがそのまま動く(標準化済みのスキーマ)

続きを読む "MySQLで指定したカラム名を持つテーブルを検索する|information_schemaを使ったDB横断検索"

MySQLのrootパスワードを忘れた場合の対処について

MySQLはオープンソースのデータベースソフトになります。 無料で利用できるデータベースソフトとしてPostgreSQLがありますが、 それと人気を二分するデータベースソフトです。 人気の理由は高性能且つ高速で、しかも操作が比較的簡単な上、 Movable TypeやXoopsなど多くのウェブサイト構築ソフトウェアが サポートしているためです。またMySQLを利用する事でLAMP環境が 構築出来ます。 ※LAMPとはLinux、Apache、 MySQL、 PHPの略称 今回はそのMySQL専用のrootパスワードを忘れてしまった場合の 対処方法をご紹介します。
【この記事でわかること】
・MySQL を --skip-grant-tables オプションで起動することで認証をバイパスできる
・ALTER USER または UPDATE mysql.user でパスワードを変更し、flush privileges を実行する
・5.7 以降は authentication_plugin が caching_sha2_password に変わった点に注意が必要
・パスワード変更後は必ず通常モードで再起動して接続確認を行う

続きを読む "MySQLのrootパスワードを忘れた場合の対処について"

Linux無料マニュアル(図解60P) 名前とメールで30秒登録