Why is OAT inaccessible after the server is initialized?
Cause: By default, the OceanBase Admin Toolkit (OAT) container is started in docker bridge mode. In this mode, the value of the system kernel parameter net.ipv4.ip_forward must be 1. If you set the server usage to observer when you initialize the server on which OAT is installed, OAT sets the net.ipv4.ip_forward parameter to 0. This makes OAT become inaccessible. Solution: Run the sysctl -w net.ipv4.ip_forward=1 command to enable forwarding. We recommend that you start OAT in docker host mode to avoid this issue. The default listening ports of OAT are ports 7000 and 3306. Before you start OAT in docker host mode, make sure that no conflicting services are running on the server.
Why does OAT respond to network requests slowly?
Symptom: OAT is deployed in good network conditions such as an intranet. However, web pages are refreshed slowly and the network connection is unstable. Cause: The operating system parameter net.ipv4.tcp_tw_recycle is improperly specified. When network address translation (NAT) is used in the connection, some TCP SYN packets are discarded. Solution: Run the sysctl -w net.ipv4.tcp_tw_recycle=0 to disable the tcp_tw_recycle parameter.
Why does OAT fail to be upgraded?
Symptom: During an OAT upgrade, the OAT container of the new version exits unexpectedly. The output of the docker logs <Name of the new OAT container> command shows that the built-in MariaDB does not start as expected. Cause: When you run the docker stop <Name of the original OAT container> command to stop the OAT container of the earlier version, MariaDB in the container may be forcibly killed, which causes an instance failure. In this case, if MariaDB in the new OAT container is of a later version, OAT fails to be started. You can view details in the mariadb.log file stored in the db/ directory of OAT. Solution: Use the image of the earlier version to pull up OAT. Go to the container and run the pkill mysqld command to shut down MariaDB. Then, perform the upgrade again.
Where can I find log files of OAT?
When you start OAT, you must mount the data directory to store all persistent data of OAT. You can run the docker inspect <Name of the OAT container> -f '{{.Mounts}}' command to view the path of the data directory. OAT log files are stored in the logs folder under this directory. The server.std file records logs of web services and the scheduler.std file records logs of the internal task scheduler.
How do I set a VIP address when I create NLB or OBLB?
Keelpalived is used to implement high-availability virtual IP (VIP) addresses for Network Load Balancer (NLB) and OBLB. To set a VIP address for NLB or OBLB, make sure that the VIP address to be used is idle. This prevents conflicts with host IP addresses on the network. In addition, make sure that the VIP address is in the same CIDR block as the IP address of the server on which the service is deployed. For example, if you deploy OAT on three servers whose IP addresses are xxx.xxx.x.101/xx, xxx.xxx.x.102/xx, and xxx.xxx.x.103/xx, you can set the VIP address to an idle IP address between xxx.xxx.x.1/xx and xxx.xxx.x.7/xx.
How do I configure load balancing when I deploy a service such as OCP?
When you deploy a service such as OceanBase Cloud Platform (OCP) in high-availability mode, two IP addresses are usually used to configure load balancing:
- Layer 7 HTTP proxy: The backend port is the web service port of the service on multiple servers, and session retention must be enabled for load balancing. This way, you can directly use the browser to access the service or some processes can use the service interface provided by the service.
- Layer 4 TCP proxy: The backend port is the service port of MetaDB on multiple servers. By default, the service port is
2883. If you use NLB or OBDNS as the load balancer, you do not need to specify the Layer 4 proxy. The configuration is automatically completed during the deployment of the service. When you deploy OceanBase Migration Service (OMS), you must set an additional Layer 7 HTTP proxy in each region as the URL for accessing the CM service in OMS. The backend port is port 8088 for the CM service on multiple servers in the region in which OMS is deployed.
When I take over a component or service, an error message appears, indicating that the information about the specified container cannot be obtained. Why does this error occur?
OAT can take over component or service containers only with standard container names. If the specified container name is invalid, you must modify the container name. Log in to the server on which the component or service to be taken over is installed by using CLI, run the docker rename <Original container name> <New container name> command to modify the container name, and then initiate a takeover request again.
Why does the following error message appear when I take over a component or service: container cpu or memory has no limit value?
This error occurs because you did not limit the CPU or memory resources of the component or service container when you started the container. You can log in to the server on which the component or service is installed by using CLI, set limits on the CPU and memory resources for the container, and then initiate a takeover request again. For example, to take over InfluxDB, you can run the following command to limit the CPU and memory resources:
docker update --cpu-quota 400000 --memory 8G --memory-swap 8G influxdb
Why does the following error message appear when I take over MetaDB: KeyError: 'OBPROXY_OPTSTR'?
OAT can take over only MetaDB with a built-in OceanBase database proxy (ODP). If the MetaDB container is not built in with an ODP, you must upgrade MetaDB to a version with a built-in ODP before you can take over MetaDB.