Managed Document Databases API

Introduction

Managed Database for FerretDB provides fully-managed document Database Instances. The resource allows you to focus on development rather than administration or configuration. It comes with a high-availability mode, data replication, and automatic snapshots.

Compared to traditional database management, which requires users to provide the infrastructure and resources to manage their databases, Managed Database for FerretDB offers users access to Database Instances without setting up the hardware or configuring the software. Scaleway handles the provisioning, manages the configuration, and provides useful features such as High Availability, automated snapshots, user management, and more.

Concepts

Refer to our dedicated concepts page to find definitions of the different terms referring to Managed Database for FerretDB.

Quickstart

  1. Configure your environment variables.

    Note:

    This is an optional step that seeks to simplify your usage of the APIs.

    export SCW_ACCESS_KEY="<API access key>"
    export SCW_SECRET_KEY="<API secret key>"
    export SCW_REGION="<Scaleway region>"
  2. Edit the POST request payload you will use to create your Database Instance. Replace the parameters in the following example:

    '{
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "name": "myDB",
    "engine": "FerretDB-1.0.0",
    "tags": ["donnerstag"],
    "is_ha_cluster": true,
    "node_type": "db-play-beta",
    "disable_backup": false,
    "user_name": "my_initial_user",
    "password": "thiZ_is_v0ry_s3cret",
    "volume_type": "bssd",
    "volume_size": "30000000000"
    }'
    ParameterDescription
    project_idThe ID of the Project you want to create your Database Instance in. To find your Project ID you can list the projects or consult the Scaleway console.
    engineREQUIRED Version ID of the database engine. To check the list of available engines you can use the folowing endpoint: https://api.scaleway.com/document-db/v1beta1/regions/$SCW_REGION/database-engines
    nameName of the Database Instance
    node_typeREQUIRED The node type. To check the list of available node types you can use the folowing endpoint: https://api.scaleway.com/document-db/v1beta1/regions/$SCW_REGION/node-types
    is_ha_clusterBOOLEAN Defines whether High Availability is enabled for the Database Instance
    disable_backupBOOLEAN Defines whether automated backups are disabled for the Database Instance
    tagsThe list of tags ["tag1", "tag2", ...] that will be associated with the Database Instance. Tags can be appended to the query of the List Database Instances call to show results for only the Database Instances using a specific tag. You can also combine tags to list Database Instances that posess all the appended tags.
    user_nameREQUIRED Identifier of the default user, which is created concurrently with the Database Instance
    passwordREQUIRED Password for the default user
    volume_typeType of volume where data is stored. You can specify either local volume (lssd) or block volume (bssd). The default value is lssd
    volume_sizeVolume size when volume_type is bssd. The value should be expressed in bytes. For example 30GB is expressed as 30000000000
  3. Create a Database Instance by running the following command. Make sure you include the payload you edited in the previous step.

    curl -X POST \
    -H "X-Auth-Token: $SCW_SECRET_KEY" \
    "Content-Type: application/json" \
    https://api.scaleway.com/document-db/v1beta1/regions/$SCW_REGION/instances \
    -d '{
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "name": "myDB",
    "engine": "FerretDB-1.0.0",
    "tags": ["donnerstag"],
    "is_ha_cluster": true,
    "node_type": "db-play-beta",
    "disable_backup": false,
    "user_name": "my_initial_user",
    "password": "thiZ_is_v0ry_s3cret",
    "volume_type": "bssd",
    "volume_size": "30000000000"
    }'
  4. List your Database Instances.

    curl -X GET \
    -H "Content-Type: application/json" \
    -H "X-Auth-Token: $SCW_SECRET_KEY" https://api.scaleway.com/document-db/v1beta1/regions/$SCW_REGION/instances

    You should get a response like the following:

    Note:

    This is a response example, the UUIDs and IP address displayed are not real.

    {
    "id": "f5122f66-fb50-4cef-aa02-487ef4fc1af0",
    "name": "myDB",
    "organization_id": "895693aa-3915-4896-8761-c2923b008be7",
    "project_id": "d8e65f2b-cce9-40b7-80fc-6a2902db6826",
    "status": "ready",
    "engine": "FerretDB-1.0.0",
    "endpoint": {
    "ip": "198.51.100.0",
    "port": 22245,
    "name": null
    },
    "tags": [
    "donnerstag"
    ],
    "settings": [],
    "backup_schedule": {
    "frequency": 24,
    "retention": 7,
    "disabled": true
    },
    "is_ha_cluster": true,
    "read_replicas": [],
    "node_type": "db-play-beta",
    "volume": {
    "type": "bssd",
    "size": 30000000000
    }
    "created_at": "2019-04-19T16:24:52.591417Z",
    "region": "fr-par"
    }
  5. Retrieve your Database Instance IP and port from the response.

    Note:

    In the example above, the IP and port are 198.51.100.0 and 22245, respectively.

  6. Get your TLS certificate in the console.

  7. Connect to your Database Instance with the mongosh client.

    mongosh --tls --tlsCAFile rdb-myDB.pem 'mongodb://<username>@<ip-address>:<port>/rdb?authMechanism=PLAIN'
  8. Enter the database password that you defined upon creation.

You are now connected to your Managed Database.

Requirements:

To perform the following steps, you must first ensure that:

Technical Information

Regions

Scaleway's infrastructure is spread across different regions and Availability Zones.

Managed Database for FerretDB is available in the Paris, Amsterdam and Warsaw regions, which are represented by the following path parameters:

  • fr-par
  • nl-ams
  • pl-waw

FerretDB specifications

Versions

Scaleway Database supports FerretDB in version 1.X

User Management

  • users with an admin role have access to all logical databases and can create new ones.
  • users created via the API are authenticated using the default authentication plugin, which can be changed in the settings.

Going Further

For more information about Managed Database for FerretDB, you can check out the following pages:

Engines

A database engine is the software component that stores and retrieves your data from a database. Currently FerretDB 1.X is available.

GET
/document-db/v1beta1/regions/{region}/database-engines

Database Instances

A Database Instance is made up of one or multiple dedicated compute nodes running a single database engine. Two node settings are available: High-Availability (HA), with a main node and one replica, and standalone with a main node. The HA standby node is linked to the main node, using synchronous replication. Synchronous replication offers the ability to confirm that all changes intended by a transaction have been transferred and applied to the synchronous replica node, providing durability to the data.

Note: HA standby nodes are not accessible to users unless the main node becomes unavailable and the standby takes over. If you wish to run queries on a read-only node, you can use Read Replicas

Read Replicas can be used for certain read-only workflows such as Business Intelligence, or for a read-only scaling of your application. Read Replicas use asynchronous replication to replicate data from the main node.

GET
/document-db/v1beta1/regions/{region}/instances
POST
/document-db/v1beta1/regions/{region}/instances
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}
PATCH
/document-db/v1beta1/regions/{region}/instances/{instance_id}
DELETE
/document-db/v1beta1/regions/{region}/instances/{instance_id}
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/certificate
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/clone
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/logs
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/logs-details
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/metrics
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/purge-logs
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/renew-certificate
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/restart
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/upgrade
GET
/document-db/v1beta1/regions/{region}/logs/{instance_log_id}

Read Replicas

A Read Replica is a live copy of a Database Instance that behaves like an Instance, but that only allows read-only connections. The replica mirrors the data of the primary Database node and any changes made are replicated to the replica asynchronously. Read Replicas allow you to scale your Database Instance for read-heavy database workloads. They can also be used for business intelligence workloads.

A Read Replica can have at most one direct access and one Private Network endpoint. Loadbalancer endpoints are not available on Read Replicas even if this resource is displayed in the Read Replica response example.

If you want to remove a Read Replica endpoint, you can use delete a Database Instance endpoint API call.

Instance Access Control Lists (ACL) also apply to Read Replica direct access endpoints.

Limitations: There might be replication lags between the primary node and its Read Replica nodes. You can try to reduce this lag with some good practices:

  • All your tables should have a primary key
  • Don't run large transactions that modify, delete or insert lots of rows. Try to split it into several small transactions.
POST
/document-db/v1beta1/regions/{region}/read-replicas
GET
/document-db/v1beta1/regions/{region}/read-replicas/{read_replica_id}
DELETE
/document-db/v1beta1/regions/{region}/read-replicas/{read_replica_id}
POST
/document-db/v1beta1/regions/{region}/read-replicas/{read_replica_id}/endpoints
POST
/document-db/v1beta1/regions/{region}/read-replicas/{read_replica_id}/promote
POST
/document-db/v1beta1/regions/{region}/read-replicas/{read_replica_id}/reset

ACLs

Network Access Control Lists allow you to control incoming network traffic by setting up ACL rules.

GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/acls
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/acls
PUT
/document-db/v1beta1/regions/{region}/instances/{instance_id}/acls
DELETE
/document-db/v1beta1/regions/{region}/instances/{instance_id}/acls

Instance Settings

Advanced Database Instance settings allow you to tune the behavior of your database engines to better fit your needs.

Available settings depend on the database engine and its version. Note that some settings can only be defined upon database engine initialization. These are called init settings. You can find a full list of the settings available in the response body of the list available database engines endpoint.

Each advanced setting entry has a default value that users can override. The deletion of a setting entry will restore the setting to default value. Some of the defaults values can be different from the engine's defaults, as we optimize them to the Scaleway platform.

POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/settings
PUT
/document-db/v1beta1/regions/{region}/instances/{instance_id}/settings
DELETE
/document-db/v1beta1/regions/{region}/instances/{instance_id}/settings

Privileges

Privileges are permissions that can be granted to database users. You can manage user permissions either via the console, the Scaleway APIs. Managed Database for FerretDB provides a simplified and unified permission model through the API and the console to make things easier to manage and understand.

Each user has associated permissions that give them access to zero or more logical databases. These include:

  • None: No access to the database
  • Read: Allow users to read tables and fields in a database
  • Write: Allow users to write content in databases.
  • Admin: Read and write access to the data, and extended privileges depending on the database engine.
GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/privileges
PUT
/document-db/v1beta1/regions/{region}/instances/{instance_id}/privileges

Users

Users are profiles to which you can attribute database-level permissions. They allow you to define permissions specific to each type of database usage. For example, users with an admin role can create new databases and users.

GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/users
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/users
PATCH
/document-db/v1beta1/regions/{region}/instances/{instance_id}/users/{name}
DELETE
/document-db/v1beta1/regions/{region}/instances/{instance_id}/users/{name}

Databases

Databases can be used to store and manage sets of structured information, or data. The interaction between the user and a database is done using a Database Engine, which provides a structured query language to add, modify or delete information from the database.

GET
/document-db/v1beta1/regions/{region}/instances/{instance_id}/databases
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/databases
DELETE
/document-db/v1beta1/regions/{region}/instances/{instance_id}/databases/{name}

NodeTypes

Two node type ranges are available:

  • General Purpose: production-grade nodes designed for scalable database infrastructures.
  • Development: sandbox environments and reliable performance for development and testing purposes.
GET
/document-db/v1beta1/regions/{region}/node-types

Snapshots

A snapshot is a consistent, instantaneous copy of the Block Storage volume of your Database Instance at a certain point in time. They are designed to recover your data in case of failure or accidental alterations of the data by a user. They allow you to quickly create a new Instance from a previous state of your database, regardless of the size of the volume. Their limitation is that, unlike backups, snapshots can only be stored in the same location as the original data.

POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/snapshots
GET
/document-db/v1beta1/regions/{region}/snapshots
GET
/document-db/v1beta1/regions/{region}/snapshots/{snapshot_id}
PATCH
/document-db/v1beta1/regions/{region}/snapshots/{snapshot_id}
DELETE
/document-db/v1beta1/regions/{region}/snapshots/{snapshot_id}
POST
/document-db/v1beta1/regions/{region}/snapshots/{snapshot_id}/create-instance

Endpoints

A point of connection to a Database Instance. The endpoint is associated with an IPv4 address and a port. It contains the information about whether the endpoint is read-write or not. The endpoints always point to the main node of a Database Instance.

All endpoints have TLS enabled. You can use TLS to make your data and your passwords unreadable in transit to anyone but you.

For added security, you can set up ACL rules to restrict access to your endpoint to a set of trusted hosts or networks of your choice.

Load Balancers are used to forward traffic to the right node based on the node state (active/hot standby). The Load Balancers' configuration is set to cut off inactive connections if no TCP traffic is sent within a 6-hour timeframe. We recommend using connection pooling on the application side to renew database connections regularly.

GET
/document-db/v1beta1/regions/{region}/endpoints/{endpoint_id}
DELETE
/document-db/v1beta1/regions/{region}/endpoints/{endpoint_id}
POST
/document-db/v1beta1/regions/{region}/endpoints/{endpoint_id}/migrate
POST
/document-db/v1beta1/regions/{region}/instances/{instance_id}/endpoints