Database Preparation

HoyoShip uses a database to store relational data, however not every relational database can be used by HoyoShip. Only the following databases are supported:

MariaDB (>=10.6), using the InnoDB storage engine
MySQL (>=8.4), using the InnoDB storage engine
PostgreSQL (>=14)
SQLite

For a recommendation on which database to use and fits your needs, read the recommendation page.

The remainder of this page will be a guide how to prepare each database type. Also take a look at the database section of the config cheat sheet for a detailed list of options in HoyoShip.

SQLite

The HoyoShip container image includes SQLite support, meaning you don’t have to install additional dependencies on your system.

Choosing SQLite only requires setting the database type and optionally the path to a database file:

[database]
DB_TYPE = sqlite3
# optional if you want to specify another location
# by default, the database file will be stored relative to other data
PATH = data/hoyoship.db

No maintenance is expected by using SQLite; it might be needed to run the VACUUM command if the database size grows too big. This reclaims space that was freed after content was deleted.

MySQL/MariaDB

Install MariaDB or install MySQL on the machine where you want to host the database, this can be on the same machine. It is also perfectly fine to use an existing database installation.

We need to perform several administrative actions on the database. In order to accomplish that you need to get into the database instance as root. If you just installed the database, then that would be done as followed:

mysql -u root -p

Enter the password as prompted.

We will create a new database user that HoyoShip will use to connect to the instance. Please, generate a secure password; for this example we use passw0rd as password and hoyoship as username.

In the case the instance is on the same machine (if relevant, in the same container):

CREATE USER 'hoyoship'@'localhost' IDENTIFIED BY 'passw0rd';

In all other cases you have to figure out from which IP address the HoyoShip instance will be communicating from to the database instance. In this example we assume that to be 192.0.2.10.

CREATE USER 'hoyoship'@'192.0.2.10' IDENTIFIED BY 'passw0rd';

Now we will create the database that HoyoShip will use. HoyoShip expects a case-sensitive collation, so we must account for this. utf8mb4_bin is a common collation for MariaDB and MySQL. When HoyoShip starts, it will try to find a better collation (utf8mb4_0900_as_cs or uca1400_as_cs) and alter the database if it is possible. If you would like to use another collation, you can set [database].CHARSET_COLLATION in the app.ini file.

In this example we utf8mb4_bin as collation and hoyoship as the name to create the database:

CREATE DATABASE hoyoship CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin';

Last step is to grant privileges to the hoyoship user for the hoyoship database.

In the case the instance is on the same machine (if relevant, in the same container):

GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, REFERENCES, SELECT, UPDATE ON hoyoship.* TO 'hoyoship'@'localhost';
FLUSH PRIVILEGES;

In all other cases you have to figure out from which IP address the HoyoShip instance will be communicating from to the database instance. In this example we assume that to be 192.0.2.10.

GRANT ALTER, CREATE, DELETE, DROP, INDEX, INSERT, REFERENCES, SELECT, UPDATE ON hoyoship.* TO 'hoyoship'@'192.0.2.10';
FLUSH PRIVILEGES;

You can now quit the CLI, by executing the exit command.

PostgreSQL

Install the PostgreSQL server component on the system you would like to store the database on.
Protect the root user with a secure password or disable the login.
On the database server, login to the database console as superuser:
Terminal window
```
su -c "psql" - postgres
```
Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of 'passw0rd' below:
```
CREATE ROLE hoyoship WITH LOGIN PASSWORD 'passw0rd';
```
Replace username and password as appropriate.
Create database with UTF-8 charset and owned by the database user created earlier. Any libc collations can be specified with LC_COLLATE and LC_CTYPE parameter, depending on expected content:
```
CREATE DATABASE hoyoshipdb WITH OWNER hoyoship TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
```
Replace database name as appropriate.
Allow the database user to access the database created above by adding the following authentication rules to pg_hba.conf.

For local database:
```
local    hoyoshipdb    hoyoship                   scram-sha-256
host     hoyoshipdb    hoyoship    127.0.0.1/32   scram-sha-256  # IPv4 local connections
host     hoyoshipdb    hoyoship    ::1/128        scram-sha-256  # IPv6 local connections
```
For remote database:
```
host    hoyoshipdb    hoyoship    192.0.2.10/32    scram-sha-256
```
Replace database name, user, and IP address of HoyoShip instance with your own.

Note: rules on pg_hba.conf are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.

Restart PostgreSQL to apply new authentication rules.
Optional: Test connection to the database from the HoyoShip container.

For local database:
Terminal window
```
psql -U hoyoship -d hoyoshipdb -h localhost
```
For remote database:
Terminal window
```
psql "postgres://hoyoship@203.0.113.3/hoyoshipdb"
```
where hoyoship is database user, hoyoshipdb is database name, and 203.0.113.3 is IP address of your database instance.

You should be prompted to enter password for the database user, and connected to the database.

Database Connection over TLS

If the communication between HoyoShip and your database instance is performed through a private network, or if HoyoShip and the database are running on the same server, this section can be omitted since the security between HoyoShip and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.

Prerequisites

You need two valid TLS certificates, one for the database instance (database server) and one for the HoyoShip instance (database client). Both certificates must be signed by a trusted CA.
The database certificate must contain TLS Web Server Authentication in the X509v3 Extended Key Usage extension attribute, while the client certificate needs TLS Web Client Authentication in the corresponding attribute.
On the database server certificate, one of Subject Alternative Name or Common Name entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. db.example.com). On the database client certificate, one of the entries mentioned above must contain the database username that HoyoShip will be using to connect.
You need domain name mappings of both HoyoShip and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to /etc/hosts (%WINDIR%\System32\drivers\etc\hosts in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.

PostgreSQL

The PostgreSQL driver used by HoyoShip supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.

On the server with the database instance, place the following credentials:
- /path/to/postgresql.crt: Database instance certificate
- /path/to/postgresql.key: Database instance private key
- /path/to/root.crt: CA certificate chain to validate client certificates

Add following options to postgresql.conf:

ssl = on
ssl_ca_file = '/path/to/root.crt'
ssl_cert_file = '/path/to/postgresql.crt'
ssl_key_file = '/path/to/postgresql.key'
ssl_min_protocol_version = 'TLSv1.2'

Adjust credentials ownership and permission, as required by PostgreSQL:

chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key

Edit pg_hba.conf rule to only allow HoyoShip database user to connect over SSL, and to require client certificate verification.
```
hostssl    hoyoshipdb    hoyoship    192.0.2.10/32    scram-sha-256    clientcert=verify-full
```
Replace database name, user, and IP address of HoyoShip instance as appropriate.
Restart PostgreSQL to apply configurations above.
On the server running the HoyoShip instance, place the following credentials under the home directory of the user who runs HoyoShip (e.g. git):
- ~/.postgresql/postgresql.crt: Database client certificate
- ~/.postgresql/postgresql.key: Database client private key
- ~/.postgresql/root.crt: CA certificate chain to validate server certificate
Note: Those file names above are hardcoded in PostgreSQL and it is not possible to change them.

Adjust credentials, ownership and permission as required:

chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt

Test the connection to the database:
Terminal window
```
psql "postgres://hoyoship@example.db/hoyoshipdb?sslmode=verify-full"
```
You should be prompted to enter password for the database user, and then be connected to the database.

MySQL/MariaDB

While the MySQL/MariaDB driver used by HoyoShip also supports two-way TLS, HoyoShip currently supports only one-way TLS.

In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn’t take place.

On the database instance, place the following credentials:
- /path/to/mysql.crt: Database instance certificate
- /path/to/mysql.key: Database instance key
- /path/to/ca.crt: CA certificate chain. This file isn’t used on one-way TLS, but is used to validate client certificates on two-way TLS.

Add following options to my.cnf:

[mysqld]
ssl-ca = /path/to/ca.crt
ssl-cert = /path/to/mysql.crt
ssl-key = /path/to/mysql.key
tls-version = TLSv1.2,TLSv1.3

Adjust credentials ownership and permission:

chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key

Restart MySQL/MariaDB to apply the setting.
The database user for HoyoShip may have been created earlier, but it would authenticate only against the IP addresses of the server running HoyoShip. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
```
DROP USER 'hoyoship'@'192.0.2.10';
CREATE USER 'hoyoship'@'hoyoship.example.com' IDENTIFIED BY 'passw0rd' REQUIRE SSL;
GRANT ALL PRIVILEGES ON hoyoshipdb.* TO 'hoyoship'@'hoyoship.example.com';
FLUSH PRIVILEGES;
```
Replace database user name, password, and HoyoShip instance domain as appropriate.
Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and HoyoShip servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
On the server running HoyoShip, test connection to the database:
Terminal window
```
mysql -u hoyoship -h example.db -p --ssl
```
You should be connected to the database.

Dedicated Primary/Replica Connection Pools

HoyoShip supports connecting to a dedicated primary/replica database setup. This allows scaling the database horizontally by adding more replicas which process all read-only queries, effectively offloading read operations from the primary database. This setup is particularly useful for high-traffic instances where read operations can significantly impact performance. It might not be needed for low-traffic/small instances.

The implementation uses the xorm.EngineGroup logic to manage the connection pool and load balancing between the primary and replica databases. Furthermore it allows defining a load balancing strategy for the replica databases.

The default, Random, distributes read-only queries across the replica databases in a random manner. Other policies can be used to distribute read-only queries in a round-robin (RoundRobin) manner, based on the load on each replica (LeastConn), or by using custom weights (WeightRandom and WeightRoundRobin).

Using a load balancing strategy is only in effect when the number of replica databases in the EngineGroup is greater than 1. An alternative to the xorm load balancing strategy is to use a dedicated load balancer in front of the replica database instances, such as HAProxy, or more advanced, DB-specific solutions like pgcat or pgdog.