Create a primary tenant

A tenant is both a container for various database objects and a container for resources such as CPU, memory, and I/O. You can create a primary tenant in a cluster based on your business requirements.

You can create a primary tenant in the following two ways:

• Create a primary tenant on the tenant overview page.

• Create a primary tenant on the tenant management page of the specified cluster.

This topic describes how to create a primary tenant on the tenant overview page.

Prerequisites

• Make sure that the current user who logs in to the OCP console has the following permissions:

  • Cluster Maintenance resource permissions.
  • Overview menu permissions.

• The cluster of the tenant must be the primary cluster and in the Running state.

• Tenants in the same cluster must have different names.

• If the OceanBase cluster to which the tenant belongs is of the following versions, and if you are using RHEL 8 or later, make sure that the host where the OBServer is located has created a soft link for Python when you create the tenant. The command for creating a soft link is ln -s /usr/bin/python3 /usr/bin/python.

  • (-∞, V4.2.1.7)
  • [V4.2.2, V4.2.4)
  • [V4.3.0, V4.3.2)

• A standalone node supports only one tenant by default. If you want to create multiple primary tenants on a standalone node, you must purchase the corresponding feature module and then import the license again.

• Before you enable the arbitration service for the tenant, make sure that the following conditions are met:

  • The cluster to which the tenant belongs has added the arbitration service, and the arbitration service is in the RUNNING state.

  • The locality of the tenant to which the arbitration service is to be enabled is 2F (F: full-featured replicas) or 4F.

  • The remaining resources on the host where the arbitration service is located meet the resource requirements.

    You can modify the resource requirements based on the actual situation. For more information about the parameters to be modified, see Modify a system parameter.

    • ocp.arbitration.min.remain.disk.size: the minimum remaining disk space for the CLOG disk on the host where the arbitration service is located when the tenant arbitration service is enabled, in MB. The value (a,b) indicates the values for tenants with 2F and 4F replicas respectively. Default value: [12,24].
    • ocp.arbitration.max.cpu.used.percentage: the maximum CPU usage on the host where the arbitration service is located when the tenant arbitration service is enabled, in %. Default value: 90.
    • ocp.arbitration.max.memory.used.percentage: the maximum memory usage on the host where the arbitration service is located when the tenant arbitration service is enabled, in %. Default value: 90.

Procedure

1. Log in to the OCP console.

2. In the left-side navigation pane, select Tenant. The Tenants page automatically appears.

3. On the Tenants page, click Create Tenant.

4. Specify information on the Basic Settings tab. The following table describes the basic settings.

   Parameter	Description
   Tenant Type	Select Primary Tenant. Description If the cluster version is earlier than V4.2, you cannot specify a tenant type. By default, the primary tenant is selected.
   Cluster	Select the cluster to which the tenant belongs. Description If you are using the tenant management page of the specified cluster to create the primary tenant, the current cluster is selected by default.
   Tenant Name	The tenant name must start with an English letter and end with an English letter or a digit. The name can contain letters, digits, and underscores. It must be 2 to 32 characters in length.
   Administrator Password	The password for the tenant administrator account. Randomly generated passwords are supported. For MySQL mode, the administrator account is root. For Oracle mode, the administrator account is SYS. The password must meet the following requirements: It must be 8 to 32 characters in length. It must contain at least three of the following four types: digits (0 to 9), uppercase letters (A to Z), lowercase letters (a to z), and special characters. The supported special characters are ~!@#%^&*_-+=|(){}[]:;,.?/.
   Character Set and Encoding	For MySQL mode, you can select binary, utf8mb4, gbk, gb18030, latin1, gb18030_2022, ascii, or tis620. utf8mb4 is selected by default. For Oracle mode, you can select utf8mb4, gbk, or gb18030. utf8mb4 is selected by default.
   Collation	The detailed collation corresponding to the character set.
   Service Name	The service name is an alternative name for the cluster name and tenant name that OceanBase Database offers to facilitate database access through service names. For more information, see Manage service names. The service name must start with an English letter and can contain letters, numbers, and underscores. It must be 2 to 64 characters in length. Before you can specify the service name for a tenant, the tenant must meet the following requirements: OceanBase: V4.2.1.9, [V4.2.4.0, V4.3.0.0), and [V4.3.3.0, +∞) OBProxy: [V4.3.1.0, +∞) Note If the primary tenant has a service name specified, the service name is automatically filled in.
   Remarks	Optional remarks.
   Load Type	Select the load type for the tenant. To avoid greatly affecting the database performance, we recommend that you select the load type that best matches your actual workload. The following table describes the available load types. Express OLTP: This load type is suitable for workloads in trading, financial, and Internet applications that require high throughput. It does not impose limitations on foreign keys, stored procedures, or long and large transactions, or complex joins and subqueries. Version limitations: This load type is supported for OceanBase V4.2.5 and later. HTAP: This load type is suitable for mixed online analytical processing (OLAP) and online transaction processing (OLTP) workloads. It is typically used for real-time insights from active operations, fraud detection, and personalized recommendation. Version limitations: This load type is supported for OceanBase V4.2.5 and later. OLAP: This load type is used for real-time data warehouse analysis. Version limitations: This load type is supported for OceanBase V4.3.0 and later. Complex OLTP: This load type is suitable for workloads in banking and insurance systems. They typically have complex joins, complex correlated subqueries, batch jobs written in PL, and long and large transactions. Short-term queries are sometimes executed in parallel. Version limitations: This load type is supported for OceanBase V4.2.5 and later. OBKV: This load type is used for key-value and wide-column workloads such as HBase. These workloads have a very high throughput and are sensitive to latency. Version limitations: This load type is supported for OceanBase V4.2.5 and later. Note We recommend that the load type of the tenant be consistent with that of its cluster.

5. Specify information on the Replica Settings tab.

   The system displays the list of configurable zones based on the zone information of the cluster you selected. If the zone does not support replica distribution, click the delete icon to delete the zone. The following table describes the information that you need to specify.

   Parameter	Description
   Replica Type	Select multiple all-purpose replicas to ensure that they account for most of the replicas. An all-purpose replica: a regular replica that has a full set of data and features, including transaction logs, memtables, and SSTables. It can be quickly promoted to a leader to provide services to external users. A read-only replica: a replica that contains complete logs, memtables, and SSTables. It does not participate in log voting as a member of the Paxos protocol but instead acts as an observer to real-time track the logs of the Paxos member and locally replay them. A log replica: a replica that contains only logs. It does not have memtables or SSTables. It participates in log voting and provides log services to external users. It can participate in the restore of other replicas, but it cannot become a leader to provide database services to external users. A read-only columnar replica: a replica that does not participate in log voting. The baseline data of all user tables is stored in columnar format and can be read only. It is suitable for TP-enhanced mixed workloads (real-time decision analysis). When you select a read-only columnar replica, the OceanBase cluster must be associated with at least two OceanBase Proxy clusters to ensure that one of them serves as the dedicated OBProxy cluster to forward client requests related to the read-only columnar replica, and that the OBProxy cluster meets the following conditions and parameter configurations: alter proxyconfig set route_target_replica_type='ColumnStore'; alter proxyconfig set proxy_route_policy='TARGET_REPLICA_TYPE_FOLLOWER_ONLY'; alter proxyconfig set init_sql='set @@ob_route_policy = COLUMN_STORE_ONLY'; alter proxyconfig set obproxy_read_only=0; alter proxyconfig set obproxy_read_consistency=1; Note If the cluster is a distributed one of V4.3.3 and later, all-purpose replica, read-only replica, and read-only columnar replica are supported. If the cluster is a distributed one of V4.2.0 or later but earlier than V4.3.3, all-purpose replica and read-only replica are supported. If the cluster is a distributed one of V4.0.0 or later but earlier than V4.2.0, only an all-purpose replica is supported. If the cluster is a distributed one of V3.x, all-purpose replica, read-only replica, and log replica are supported. Single-node systems support only all-purpose replica.
   Unit Specifications	OCP offers predefined unit specifications. You can select a unit specification based on the OCP resource unit specifications. You can also click Add Specification at the bottom of the list to add a custom unit specification. Notice We recommend that you set the same unit specification and number of units for all-purpose replicas. Different unit specifications and numbers of units may cause performance or stability issues. If the cluster to which the tenant belongs is V4.0.0 or later: You cannot set unit specifications with less than one CPU core. The cluster specifies the minimum value of the memory specifications by default. You can change this value with the __min_full_resource_pool_memory parameter. Take a cluster of V4.1.0 as an example. For more information about how to change the cluster-level parameters, see Change cluster-level parameters.
   Units	The number of units in the zone. This value cannot exceed the number of servers in the zone. If the cluster you selected is of V4.0 or later, you cannot set the number of units separately for each zone. The number of units must be the same for all zones. The default value is 1. If the cluster you selected is earlier than V4.0, you can set different numbers of units for multiple zones. Note The default number of units for a single-node system is 1 and cannot be modified.
   Zone Priority Rankings	Specifies whether to set the priority of zones for the tenant. The priority setting affects the primary zone of the sys tenant. If you do not specify a priority setting, the sys tenant's zone priorities are used by default. If the "Zone Priority Sorting" feature is enabled but no priority setting is configured, random priority is used. To configure zone priorities, you can move one or multiple zones from the left-side list box to the right-side list box. The left-side list box displays all the zones in the current cluster. The zone added earlier has a higher priority than the one added later, and multiple zones added at the same time have the same priority. After you move a zone to the right-side list box, you can drag the zones in the right-side list box to change their order. Zones at the top of the list box have a higher priority than those at the bottom of the list. Note Single-node systems do not support zone priority sorting. The default priority of Zone1 is the highest.
   Enable Arbitration Service	Specifies whether to enable the arbitration service for the tenant. The arbitration service is disabled by default.

6. Configure the Security Settings tab.

   • All IPs are allowed to access. All IP addresses are allowed to access this tenant.

     Notice

     Allowing all IP addresses to access a tenant poses a security risk. Proceed with caution.

   • Custom IP address. Specify a list of client IP addresses that are allowed to log in to the tenant. Supported formats include IP address, subnet/mask, fuzzy matching, hybrid format, and special notes. Example:

     Format	Example
     IP Address	xxx.xxx.xxx.1,xxx.xxx.xxx.2
     Subnet/Mask	xxx.xxx.xxx.1/24
     Fuzzy Matching	xxx.xxx.xxx.% or xxx.xxx.xxx._
     Hybrid Format	xxx.xxx.xxx.1,xxx.xxx.xxx.2,xxx.xxx.xxx.%,xxx.xxx.xxx._,xxx.xxx.xxx.1/24
     Special Note	% indicates that all clients can connect.

     Notice

     OCP and the underlying OBProxy must be in this IP address list. Otherwise, OCP cannot manage the tenant.

7. Click Parameters and configure the tenant parameters.

   • If you configured the load type on the Basic Settings tab, the system selects the corresponding parameter template by default.

   • You can add startup parameters one by one and set values for the parameters.

   • You can select a parameter template from the drop-down list in the upper part of the page, and the parameters in the template, as well as the corresponding configurations, are automatically filled in. If no tenant parameter template is created, you can click Create Tenant Template to create a template. For more information, see Manage tenant parameter templates.

     The system provides the following four built-in templates, each of which includes commonly used parameter settings. You can use these templates for initial cluster settings. The following table describes the built-in parameter templates.

     Template	Description
     Default parameters for the COMPLEX_OLTP load type	The template is suitable for the Complex OLTP workload and only applies to OceanBase V4.2.5 and later.
     Default parameters for the HTAP load type	The template is suitable for the HTAP workload and only applies to OceanBase V4.2.5 and later.
     Default parameters for the OLAP load type	The template is suitable for the OLAP workload and only applies to OceanBase V4.3.0 and later.
     Default parameters for the EXPRESS_OLTP load type	The template is suitable for the Express OLTP workload and only applies to OceanBase V4.2.5 and later.

   Note

   If your tenant is in MySQL mode and the parameter template you selected contains only Oracle-defined parameters, you must delete these parameters after the template is applied.

8. Click Submit. A prompt appears: Tenant creation task submitted.. On this page, you can view the task information.

   • Click View Task Details to view the progress of the tenant creation task.
   • You can also click Return to Tenants List to go back to the tenant list page. On the tenant list page, you can view the creation status and task details of the tenant. You can also delete a tenant that failed to be created.

   Note

   If the task is in the Completed state, and the tenant is in the Running state in the Tenants list of the Tenant Management page, the tenant creation is successful.