データーベース管理
データーベース管理:記事リスト
データーベース管理のカテゴリーには以下の記事がリストされています。
postgresql.confのメモリ設定を決める方法|shared_buffersとwork_memの見積もりと反映手順
インストール直後の 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からスタンバイ昇格まで
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周回を防ぐ設定の考え方
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でバックアップする手順|論理バックアップの取得と復元の実務
PostgreSQLには標準で pg_dump と pg_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ユーザーへの切り替えと権限付与の基本
「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権限が変わった
MySQLのデータディレクトリを別ディスクへ移設する手順|datadir変更とSELinuxラベルの再設定
このトラブルの原因として最も多いのが、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をポイントインタイムリカバリする方法|誤操作直前まで戻す復旧手順
この記事では、mysqlbinlogコマンドを使ったMySQLのポイントインタイムリカバリ(PITR)の手順を、実際のコマンド出力とともに解説します。フルバックアップのリストアを基点に、バイナリログから誤操作直前のポジションを特定し、差分を再適用するまでの一連の流れを網羅します。
実行環境:MySQL 8.0.36 / Rocky Linux 9.4 で動作確認済み。MySQL 5.7でも基本手順は同じです。
この記事のポイント
・mysqlbinlog + フルバックアップで誤操作直前まで復旧できる
・--stop-position でDROP/DELETE文だけをスキップして再適用できる
・バイナリログが期限切れで削除されると復旧不可能になる
・ROW形式のバイナリログ確認には --base64-output=DECODE-ROWS が必要
MySQLのレプリケーションをLinuxサーバー2台で構築する手順|binlogとGTIDによるソース・レプリカ設定
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に接続できないときの対処|接続上限の見直しとコネクション滞留の調査
「アプリのエラーログに
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が放置されていることが原因です。デフォルト値は非常に保守的な設定になっており、現代のサーバーのメモリを全く活かしきれていません。
この記事では、my.cnfチューニングの核心であるinnodb_buffer_pool_sizeとmax_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とサービス起動・初期ロール設定まで
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横断検索
「テーブル定義を直接見ても、目的のカラムが見つからない」
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 を --skip-grant-tables オプションで起動することで認証をバイパスできる
・ALTER USER または UPDATE mysql.user でパスワードを変更し、flush privileges を実行する
・5.7 以降は authentication_plugin が caching_sha2_password に変わった点に注意が必要
・パスワード変更後は必ず通常モードで再起動して接続確認を行う
