MariaDB
This provisions a new MariaDB database in an existing MariaDB instance. The instance must be reachable from Humanitec IPs.
Property | Description |
---|---|
Resource type | mariadb |
Account type | None |
Inputs
Values
Name | Type | Description |
---|---|---|
host |
string | The IP Address or hostname that the instance is available on. |
port |
integer | The port the instance is listening on. |
append_host_to_user |
boolean | [Optional] Azure Databases for Postgres and MySQL require usernames to have @servername appended to them. Set this to true for the Driver to append this automatically. (See: Azure Database connection strings) |
copy_from_name |
string | [Optional] If provided, specifies the database in the same instance to copy data from. |
Secrets
Name | Type | Description |
---|---|---|
dbcredentials |
object | An object holding username and password properties for the PostgreSQL superuser. |
Notes
Automatic population of database
MariaDB does not provide any standard way of duplicating databases. Instead, the suggested approach is to “dump and restore” a database using tools such as mariadb-dump/mysqldump.
This Driver emulates a dump and restore of the database: for example, it serially copies data from the source database to the target database. It therefore suffers from limitations of dumping and restoring a database. The main issue is that if the source database is being written to, there are no guarantees about the data integrity in the resulting database. Consider a source database with 2 tables A and B:
- Table A is copied to the target database.
- New data is then written to Table A and Table B in the source database.
- Table B is copied from the source database to the target database.
The target database will now have the updated to table B but not table A.
This functionality should not be used for production databases or where data integrity must be guaranteed.
Example
To create a fresh MariaDB database in an instance available at dev-mariadb.example.com
:
curl https://api.humanitec.io/orgs/${HUMANITEC_ORG}/resources/defs \
-X POST \
-H "Authorization: Bearer ${HUMANITEC_TOKEN}" \
-H "Content-Type: application/json" \
--data-binary '
{
"id": "dev-mariadb",
"name": "Dev MariaDB",
"type": "mariadb",
"criteria": [
{
"env_type": "development"
}
],
"driver_type": "humanitec/mariadb",
"driver_inputs": {
"values": {
"host": "dev-mariadb.example.com",
"port": 3306
},
"secrets": {
"dbcredentials": {
"username": "root",
"password": "53cr3t-P455w0rd"
}
}
}
}'
Unlike Google CloudSQL, most MariaDB implementations use a single shared Driver.
Prerequisites
- You must have a database instance/server running
- If you are using a hosted MariaDB it is recommended provide a management service account with Database CRUD permissions. You will need to add this account via the Cloud Accounts screen
- You must have a user defined on the instance for Workloads to use when connecting to the database
Add a Resource Definition
- From the Resource Management screen, click Add resource definition.
- In the modal dialog click MariaDB.
- Next, select the mariadb-cloudsql Driver.
- Finally, provide the following information, then click Add Postgress.
- In the ID field provide a unique ID for the resource.
- (If you are using a management account) in the Credentials field select the Cloud Account you created earlier.
- In the Fully qualified CloudSQL instance name provide the instance name in the format
<project-id>:<region>:<id>
. - In the User / Role and Password fields provide the credentials that Workloads should use when connecting to the database.
- In the Hostname or IP field provide the Hostname or IP address that the Workloads can access the database on.
- In the Port field provide the port number that the database is running on.
Resource Matching
Now that the resource is defined you will need to add matching criteria.
- Click on the relevant row in the Resource Definition table.
- Then switch to the Matching Criteria tab.
- Click + Add new Criteria.
- Configure the matching rules as needed.
- Click Save.