Database configuration files

This page is a reference for where things live inside a Stack Harbor PaaS database container — the engine config, the cron config, the default backup script, the application-keys directory, and the admin-panel sub-configs.

The layout is the same across MySQL, MariaDB, Percona, and PostgreSQL containers, with a small set of engine-specific paths.

Directory layout

The rest of this page covers what each folder contains and how the platform interacts with it.

/etc — engine configuration

MySQL, MariaDB, and Percona use the /etc/my.cnf file as the main engine configuration. The platform manages a small set of settings in this file:

• key_buffer_size
• table_open_cache
• myisam_sort_buffer_size
• innodb_buffer_pool_size

These are sized against the container’s resource limit. If you want to override any of them by hand, see Database auto-configuration — set the JELASTIC_AUTOCONFIG environment variable to false, or, on legacy containers, remove the #Jelastic autoconfiguration mark. line at the start of /etc/my.cnf. Otherwise your edits get overwritten on the next platform-managed update.

A cleaner alternative is to drop overrides into /etc/mysql/conf.d/my_custom.cnf. Settings there take precedence and the platform does not touch them.

/var/lib/pgsql/data — PostgreSQL configuration

For PostgreSQL containers, the main configuration files live in /var/lib/pgsql/data:

• postgresql.conf
• pg_hba.conf
• pg_ident.conf

The platform manages two parameters in postgresql.conf:

• shared_buffers — a fraction of total RAM (a quarter when the container has eight or more cloudlets, a seventh otherwise; floor of 128 KB).
• max_stack_depth — ulimit -s minus 1024, in MB.

To override by hand, remove the #Jelastic autoconfiguration mark. line at the start of postgresql.conf. Without that, the platform overwrites manual edits on the next managed update.

/var/spool/cron — cron jobs

Each database container ships with a cron config in /var/spool/cron/ (file name matches the engine — mysql, postgres, etc.). The default backup-job line is included, commented out. Uncomment it, adjust the frequency and the script parameters, and save — cron picks up the change without a restart.

See Database backups for the full backup-scheduling procedure.

/var/lib/jelastic/bin — scripts

This folder holds the default backup_script.sh and is the recommended drop-in for custom scripts. Anything you put here survives container redeploy.

The default backup script accepts a small set of parameters:

• -m {mode} — dumpall for a full database backup, dump for a partial one.
• -c {count} — number of old backups to retain alongside the most recent one.
• -u {user} and -p {password} — credentials for the engine.
• -d {databases} and -t {tables} — optional list of databases (or tables) to back up.

For the cron line that drives the script, see Database backups.

/var/lib/jelastic/backup — backup archives

The default backup script writes its output here. Archives are bz2 files. To keep backups off the database node, mount this path to remote storage; the storage layer becomes the backup destination.

/var/lib/jelastic/keys — application keys

Drop private keys (SSH, SSL, API) here as plain files. Reference them by absolute path from your application — for example /var/lib/jelastic/keys/{keyName}. The directory persists across redeploy.

/etc/httpd/conf.d — admin-panel sub-configs

For MySQL-family and PostgreSQL containers, the admin-panel config (phpMyAdmin or pgAdmin) lives here as a sub-config file — for example phpMyAdmin-jel.conf for MySQL. Use these files to set IP-based or domain-based allow/deny rules for the panel.

See also

• Database auto-configuration — the autoconfig mark and the override paths.
• Database backups — how the default script is invoked from cron.
• Database hosting — operational overview for the database tier.