Caution
The contents of the docs
folder have been moved to the docs-internal-orchestration repository. Please update this documentation in that repository instead.
To view the Scalar Kubernetes documentation, visit the documentation site for the product you are using:
This guide explains how to set up a database for ScalarDB/ScalarDL deployment on Azure.
When you use Cosmos DB for NoSQL, you must set COSMOS_DB_URI
and COSMOS_DB_KEY
in the ScalarDB/ScalarDL properties file as follows.
scalar.db.contact_points=<COSMOS_DB_URI>
scalar.db.password=<COSMOS_DB_KEY>
scalar.db.storage=cosmos
Please refer to the following document for more details on the properties for Cosmos DB for NoSQL.
You must create an Azure Cosmos DB account with the NoSQL (core) API. You must set the Capacity mode as Provisioned throughput when you create it. Please refer to the official document for more details.
You must set the Default consistency level as Strong. Please refer to the official document for more details.
You can configure Backup modes as Continuous backup mode for PITR. Please refer to the official document for more details.
It is recommended since the continuous backup mode automatically and continuously gets backups so that we can reduce downtime (pause duration) for backup operations. Please refer to the following document for more details on how to backup/restore the Scalar product data.
You can configure the monitoring of Cosmos DB using its native feature. Please refer to the official document for more details.
It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.
You can configure the Azure Cosmos DB account to allow access only from a specific subnet of a virtual network (VNet). Please refer to the official document for more details.
It is recommended since the private internal connections not via WAN can make a system more secure.
You can configure the Request Units of Cosmos DB based on your requirements. Please refer to the official document for more details on the request units.
You can configure Request Units using ScalarDB/DL Schema Loader when you create a table. Please refer to the following document for more details on how to configure Request Units (RU) using ScalarDB/DL Schema Loader.
When you use Azure Database for MySQL, you must set JDBC_URL
, USERNAME
, and PASSWORD
in the ScalarDB/ScalarDL properties file as follows.
scalar.db.contact_points=<JDBC_URL>
scalar.db.username=<USERNAME>
scalar.db.password=<PASSWORD>
scalar.db.storage=jdbc
Please refer to the following document for more details on the properties for Azure Database for MySQL (JDBC databases).
You must create a database server. Please refer to the official document for more details.
You can choose Single Server or Flexible Server for your deployment. However, Flexible Server is recommended in Azure. This document assumes that you use Flexible Server. Please refer to the official documents for more details on the deployment models.
Azure Database for MySQL gets a backup by default. You do not need to enable the backup feature manually.
If you want to change some backup configurations like the backup retention period, you can configure it. Please refer to the official document for more details.
Please refer to the following document for more details on how to backup/restore the Scalar product data.
You can configure the monitoring of Azure Database for MySQL using its native feature. Please refer to the official document for more details.
It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.
You can configure Private access (VNet Integration) as a Connectivity method. Please refer to the official document for more details.
You can access the database server from the Scalar product pods on your AKS cluster as follows.
- Create the database server on the same VNet as your AKS cluster.
- Connect the VNet for the database server and the VNet for the AKS cluster for the Scalar product deployment using Virtual network peering. (// TODO: We need to test this feature with Scalar products.)
It is recommended since the private internal connections not via WAN can make a system more secure.
When you use Azure Database for PostgreSQL, you must set JDBC_URL
, USERNAME
, and PASSWORD
in the ScalarDB/ScalarDL properties file as follows.
scalar.db.contact_points=<JDBC_URL>
scalar.db.username=<USERNAME>
scalar.db.password=<PASSWORD>
scalar.db.storage=jdbc
Please refer to the following document for more details on the properties for Azure Database for PostgreSQL (JDBC databases).
You must create a database server. Please refer to the official document for more details.
You can choose Single Server or Flexible Server for your deployment. However, Flexible Server is recommended in Azure. This document assumes that you use Flexible Server. Please refer to the official documents for more details on the deployment models.
Azure Database for PostgreSQL gets a backup by default. You do not need to enable the backup feature manually.
If you want to change some backup configurations like the backup retention period, you can configure it. Please refer to the official document for more details.
Please refer to the following document for more details on how to backup/restore the Scalar product data.
You can configure the monitoring of Azure Database for PostgreSQL using its native feature. Please refer to the official document for more details.
It is recommended since the metrics and logs help you to investigate some issues in the production environment when they happen.
You can configure Private access (VNet Integration) as a Connectivity method. Please refer to the official document for more details.
You can access the database server from the Scalar product pods on your AKS cluster as follows.
- Create the database server on the same VNet as your AKS cluster.
- Connect the VNet for the database server and the VNet for the AKS cluster for the Scalar product deployment using Virtual network peering. (// TODO: We need to test this feature with Scalar products.)
It is recommended since the private internal connections not via WAN can make a system more secure.