5.2 Database Servers

Role of Database Servers in Linux Environments

On Linux, database servers are long‑running background services that store, organize, and provide access to structured data for applications. At the server‑administration level, you are concerned less with SQL syntax and more with:

• Choosing the right engine (MySQL/MariaDB vs PostgreSQL vs others).
• Installing and integrating it with the OS (packages, users, services).
• Managing resources (memory, CPU, disk, I/O).
• Ensuring availability, consistency, backup, and security.

Database servers are often core infrastructure components alongside web servers, message brokers, and cache systems. Misconfigurations here can lead to data loss, downtime, or security breaches, so they deserve special attention in any Linux server stack.

Key characteristics of database servers:

• Stateful: They maintain persistent data and must be treated carefully in backups, migrations, and scaling.
• Networked: Clients usually connect over TCP/IP, even when on the same host.
• Resource‑intensive: DB servers are heavy users of RAM, disk I/O, and sometimes CPU.
• Sensitive to latency: Performance is often limited by disk and network delays.

Your tasks as a Linux admin revolve around deploying, running, and safeguarding these services in production.

Common Database Architectures

Different database architectures affect how you deploy and manage servers:

• Single‑instance, single‑node
  One DB server process on one machine. Simple to set up and manage; a single point of failure.
• Primary–replica (master–slave) replication
• One primary node accepts writes.
• One or more replicas receive changes (typically asynchronously).
• Admin perspective:
• Configure replication channels (user, permissions, binlogs/WAL shipping).
• Monitor replication lag.
• Plan failover procedures.
• Multi‑primary (multi‑master) or clustered
  Multiple nodes can accept writes. Examples: Galera Cluster (for MariaDB/MySQL), native logical replication with promotion in PostgreSQL (or external clustering tools).
  Admin implications:
• Conflict resolution.
• Network partition handling.
• More complex health checks and load balancing.
• Sharding / partitioning
  Horizontal distribution of data across multiple servers or logical partitions.
• Improves capacity and throughput.
• Makes operations like backups and schema changes more complex.

Knowing which architecture is in use determines your approach to backup, failover, monitoring, and capacity planning.

Database Server Types You’ll Encounter on Linux

While this course has dedicated subchapters for MySQL/MariaDB and PostgreSQL, at the “Database Servers” level it is useful to distinguish the main categories you might administer:

• Relational DBMS (RDBMS)
• Examples: MySQL, MariaDB, PostgreSQL, Oracle, SQL Server on Linux.
• Store data in tables with rows and columns.
• Use SQL, transactions, constraints, and ACID guarantees.
• Document and NoSQL databases
• Examples: MongoDB (documents), Redis (in‑memory key/value), Cassandra (wide‑column), Elasticsearch/OpenSearch (search/analytics).
• Often relax some ACID guarantees for performance or horizontal scalability.
• Typically each has its own daemon, config format, and tooling.
• Embedded / lightweight databases
• Examples: SQLite embedded in applications (no separate daemon), or small servers like H2.
• On Linux servers you mostly interact with them through application deployment, not as stand‑alone services.

As an expert Linux admin, you should be comfortable with at least one mainstream RDBMS and aware of the operational patterns common to other types: service management, security, backups, and scaling.

Database Servers and Linux Integration

Although each DBMS has its quirks, they share a lot in how they integrate with Linux:

Processes and Service Management

Database servers run as system services (daemons). Typical characteristics:

• Dedicated system user
• Example: mysql, postgres, mongodb.
• Never run the server as root in production.
• Data directories and config files are owned by this user.
• Service units
• On systemd systems: mysqld.service, postgresql.service, mariadb.service, etc.
• You manage them with systemctl (covered in the systemd chapter):
• systemctl start|stop|restart db_service
• systemctl enable db_service for boot start.
• PID files and sockets
• Many servers create PID files (e.g., /run/mysqld/mysqld.pid) and Unix domain sockets (e.g., /var/run/postgresql/.s.PGSQL.5432) which you may need for troubleshooting and access control.

Your job is to ensure these services start cleanly at boot, recover after crashes, and fit into your overall service monitoring framework.

Filesystem Layout

On most distributions, database software and data are separated clearly:

• Binaries and client tools: Under /usr/bin, /usr/sbin, etc.
• Configuration: Under /etc/<db_name>/ or /etc/<db_name>.conf.
• Data directory: Typically under /var/lib/<db_name>/.
• Logs: Under /var/log/<db_name>/.

As an admin, you must know:

• Where the data directory resides (for backups and capacity planning).
• Where logs go (for troubleshooting and auditing).
• What permissions the DB user needs on these paths.

The /var hierarchy is particularly important: it holds both logs and database data, which must be accounted for in disk planning and backup schemes.

Network Integration

Most database servers:

• Listen on a TCP port (e.g., 3306 for MySQL/MariaDB, 5432 for PostgreSQL).
• May optionally expose a Unix socket for local connections.

On Linux servers you must:

• Configure bind addresses (127.0.0.1, 0.0.0.0, or specific interfaces).
• Coordinate with the firewall (UFW, firewalld, iptables) to restrict who can connect.
• Optionally integrate with:
• Stunnel / HAProxy / Nginx stream for TLS termination or load balancing.
• VPNs or private cloud networks to isolate database traffic.

Core Administration Responsibilities

Regardless of which specific DBMS you use, the core responsibilities are similar.

Installation and Initial Hardening

From a Linux perspective:

• Install server packages (usually via your distro’s package manager).
• Verify service account:
• Check the database user and group.
• Lock down filesystem permissions for data and configuration files.
• Change default credentials:
• Remove or secure anonymous users.
• Set strong passwords for administrative accounts.
• Configure basic settings:
• Data directory location.
• Listen addresses and ports.
• auth method (password, certificate, local socket, etc.).
• Enable secure access:
• TLS/SSL for remote connections (certs, key permissions).
• Firewall rules for trusted subnets or jump hosts only.

These tasks are part of broader system‑hardening practices, applied specifically to database daemons.

Backup and Recovery Mindset

Database data is not safely backed up with simple file copies alone; you need DB‑aware methods (covered in detail later in “Database backup strategies”).

From the server‑admin perspective, ensure:

• You know which backup mechanism is in place:
• Logical dumps (e.g., mysqldump, pg_dump).
• Physical backups (filesystem, LVM snapshots, pg_basebackup, vendor tools).
• Backups run with correct permissions, schedules, and disk targets.
• Backup data is stored on reliable storage and preferably off‑host.
• Restoration procedures are tested: a backup is only useful if you can successfully restore it.

Coordinating backups with the rest of the system (snapshots, archival, encryption) is a core responsibility.

Performance and Capacity Planning

Database servers amplify underlying Linux resource issues, so you must:

• Monitor CPU and memory usage:
• Identify if the DB is swapping (a major performance killer).
• Track disk space and I/O:
• Growth of data and logs.
• IOPS and latency under load.
• Monitor connection counts and query throughput (usually via DB‑specific tools).

Capacity planning ties database metrics to host capacity:

• Estimate data growth (per day / per month).
• Plan when to:
• Add more storage or faster disks.
• Increase RAM.
• Move to a bigger instance or a cluster.
• Ensure log rotation and archival are configured to prevent /var from filling.

High Availability and Failover Coordination

Even when clustering or replication is implemented with DB‑specific tools, Linux administration concerns include:

• Making sure replica services start in the correct order.
• Integrating with cluster managers or load balancers:
• Health checks on DB ports or custom status endpoints.
• Dynamic routing to the current primary node.
• Using virtual IPs or DNS updates to direct clients to the active node.
• Ensuring node‑level configurations (firewall, SELinux/AppArmor, kernel parameters) are consistent across cluster members.

Your role is to provide a stable, predictable platform for the replication or clustering logic to operate on.

Security Considerations Specific to Database Servers

Database servers are prime targets, because they centralize valuable data. On Linux, the security layers around them include:

Network and Access Controls

• Network isolation:
• Place DB servers on private networks, not directly exposed to the public Internet.
• Use VPNs, bastion hosts, or application servers as intermediaries.
• Firewall rules:
• Permit only known application servers or admin IPs.
• Block direct access from user networks or the Internet.
• Authentication and authorization:
• Enforce strong auth for DB users.
• Limit privileges with roles and grants.
• Use dedicated DB accounts per application, not shared admin accounts.

OS-Level Protections

• Least privilege for DB service user:
• No shell logins for the DB user.
• Restrict file ownership strictly to what’s required.
• Mandatory access control:
• SELinux or AppArmor profiles for DB daemons (enforcing instead of permissive, where possible).
• File encryption:
• At the disk or filesystem level (e.g., LUKS volumes) for data directories.
• Proper key management and boot procedures.

Logging and Auditing

• Ensure DB logs are:
• Written to /var/log/... or a dedicated path with correct permissions.
• Rotated and archived properly (e.g., via logrotate).
• Integrate DB logs with system‑wide logging and monitoring:
• Forward to central log servers.
• Include in alerting pipelines.
• Consider auditing plugins or features of the DB itself for sensitive systems (e.g., logging who changed what and when).

These protections tie into overall system hardening and incident‑response practices.

Operational Lifecycle of a Database Server

Thinking in terms of lifecycle helps structure your administration tasks.

Provisioning

• Choose a Linux distribution and version supported by your DB vendor.
• Allocate appropriate CPU, RAM, and disk (fast SSDs are often critical).
• Decide on storage layout:
• Separate volumes for data, logs, and backups, where possible.
• Automate installation via configuration‑management tools:
• Standardize package versions and base configurations.

Configuration and Tuning

Initial configuration typically includes:

• Port and bind address.
• Data directory path and ownership.
• Memory settings (shared buffers, caches, pool sizes).
• Connection limits and pool behavior.
• Logging verbosity and rotation.

Fine‑tuning requires monitoring and load testing; your goal is to avoid both resource exhaustion and under‑utilization.

Routine Operations

On a running Linux DB server you will regularly:

• Apply security updates to the OS and DB packages.
• Rotate and purge logs.
• Monitor metrics and respond to alerts.
• Test restores at scheduled intervals.
• Periodically review:
• User and role lists.
• Firewall rules.
• Access patterns (identify unused or over‑privileged accounts).

Upgrades and Migrations

Major DB upgrades and server migrations can be disruptive. From the Linux side:

• Plan maintenance windows and rollback strategies.
• Ensure there is enough disk space for upgrade artifacts (temporary files, new binaries).
• Use OS tools for:
• Cloning VMs or containers.
• Taking filesystem snapshots before upgrades.
• Carefully coordinate:
• Application downtime or read‑only mode.
• Switchover in load balancers or DNS.

Clear documentation and automation reduce risk for these changes.

Database Servers in Modern Deployment Models

As Linux servers move into more dynamic environments, database servers adapt as well.

Virtual Machines and Cloud Instances

In cloud environments:

• DBs often run on dedicated VMs with:
• Optimized storage (provisioned IOPS volumes).
• Separate network security groups or firewalls.
• You must coordinate with:
• Cloud snapshots.
• Auto‑scaling groups (for stateless tiers; DBs typically scale differently).

Containers and Orchestration

Running DB servers in containers (e.g., Docker, Kubernetes) is possible but has trade‑offs:

• Pros:
• Easier packaging and deployment.
• Consistent configuration across environments.
• Cons:
• Stateful storage complexity (persistent volumes, backups).
• Orchestrator restarts/rescheduling can be risky if not carefully controlled.
• You must design:
• Reliable storage backends.
• Pod/replica layouts that respect data integrity.
• Proper health checks and readiness probes.

For production, many organizations still prefer managed database services or traditional VMs, and reserve containers for development or less critical workloads.

Managed Database Services

Even when you use cloud‑managed databases (RDS, Cloud SQL, etc.), Linux database expertise remains valuable:

• Application servers still run on Linux and connect to DB endpoints.
• Concepts like:
• Connection pools,
• Network security,
• OS‑level logging and monitoring
  still apply.
• Knowledge of self‑hosted DBs helps you understand limitations or behavior of managed offerings.

How This Chapter Fits with the Following Ones

This chapter set the stage for working with database servers on Linux from an OS and operational perspective:

• MySQL/MariaDB and PostgreSQL chapters will dive into:
• DB‑specific installation and configuration.
• Client tools and admin commands.
• DB‑native backup, tuning, and replication.
• The Database backup strategies and Database hardening chapters will expand on:
• Detailed backup/restore workflows.
• Schema‑level security and role management.
• DB‑specific audit and encryption features.

Keep the high‑level responsibilities and lifecycle in mind; they form the context for everything you’ll configure inside individual database platforms.