Summary: If GBase Database(GBase 8a) finishes installing but gcadmin still reports close, check the License status before reinstalling the cluster. This guide explains how to verify License validity, identify version-related differences, and avoid common post-installation failures.
Yesterday, a cluster installation completed successfully. The services appeared to be running, but gcadmin reported close, and the business application could not connect.
The first suggestion was to reinstall everything. But the actual problem was simpler: the License for GBase Database(GBase 8a) had not been loaded correctly during installation.
The binaries were in place. The authorization state was not ready.
This is an important distinction in GBase Database troubleshooting: a completed installation does not necessarily mean the cluster is ready for business traffic.
1. Why Does GBase Database Show close After Installation?
When a GBase Database cluster remains in close after installation, do not immediately assume that the network, firewall, or database binaries are responsible.
License configuration is one of the checks worth performing early.
For the relevant GBase Database(GBase 8a) deployments, License authorization is associated with the ESN and SSH private key of the GCware node. Changes to the node, key material, or operating system can affect the existing authorization, depending on the release and licensing mechanism.
This explains a frustrating situation: the License file still exists, but the authorization is no longer valid for the current environment.
A safer workflow is:
- Confirm the exact GBase Database release.
- Verify the required License and target environment information.
- Load the License using the procedure supported by that release.
- Check the License status after installation.
- Confirm the cluster state before handing the environment over to the application team.
2. Load the License During Installation
For releases that support the following installation syntax, the License file can be specified with --license_file:
./gcinstall.py --license_file=/opt/gbase.lic --silent=demo.options
Confirm the exact parameter syntax and response-file requirements in the installation manual for your target GBase Database release before running the command.
If the cluster has already been installed, first determine which licensing mechanism the release uses and whether the License can be loaded or replaced without reinstalling the cluster.
Reinstallation should not be the default response to a License problem.
3. Verify the License with chkLicense
Where supported by the installed release, chkLicense can be used to inspect License status across multiple nodes.
For example:
chkLicense -n 10.10.10.1,10.10.10.2 -u gbase -p '******'
Replace the example IP addresses and credentials with the values appropriate for your environment. Avoid exposing real passwords in shell history, shared terminal recordings, or troubleshooting logs.
Focus on three fields in the output:
-
is_exist— Indicates whether the License file exists. -
version— Identifies the reported License category, such asbusinessortrial. -
is_valid— Indicates whether the License is currently valid.
These fields answer different questions. A License file can exist without being valid, and a trial License may expire even when the file remains in place.
Do not treat is_exist alone as proof that authorization is working.
For a commercial deployment, confirm that the reported category matches the intended License type and that the validity check succeeds. Also verify the cluster status using the tools and status definitions documented for your release.
4. Check Every Relevant Node
In a multi-node GBase Database cluster, do not assume that checking a single machine provides sufficient evidence for the whole environment.
The -n option in the example accepts a comma-separated list of node IP addresses. Some versions also support options such as --hosts for reading a node list from a file and -f for writing results to a file.
Check the supported options with the documentation or help output for the installed version.
For larger clusters, a node list file and a saved verification report make the process easier to repeat and audit.
The handover record should include the relevant License status, target release, authorized node information, and expiry date when applicable.
5. License Replacement Requires a Controlled Procedure
If the License needs to be replaced, avoid uploading a new file and restarting services without first confirming the release-specific procedure.
A controlled replacement workflow generally includes:
- Back up the existing License file and relevant configuration.
- Confirm the new License matches the target environment and release.
- Upload the new file to the documented location.
- Apply the required ownership and permissions.
- Follow the documented loading or service-restart procedure, if required.
- Run the License verification again and confirm the resulting cluster state.
The exact sequence matters because License loading and activation behavior can differ between releases. Do not assume that every version requires the same restart procedure.
A backup also provides a recovery reference if the replacement does not work as expected.
6. Watch the GBase Database 9.5.3.27 Version Boundary
One important compatibility point is the change in the License system around GBase Database 9.5.3.27.
License formats, installation parameters, validation commands, and activation procedures may differ across the relevant releases. A command that works in one environment should not automatically be copied into another.
Before troubleshooting, record the exact software version and consult the corresponding installation and License manuals. This is also why package selection and version confirmation belong in the pre-installation checklist.
7. Include License Details in the Handover Checklist
A successful installation is not the end of the deployment process.
For GBase Database(GBase 8a), include the following information in the handover record:
- Installed software version and package details
- License type and validation results
- Relevant GCware node ESN information
- Required key-backup and recovery arrangements
- Trial License expiry date, where applicable
- Results of the final cluster-status check
- The approved procedure for node replacement and License revalidation
Before changing a node, regenerating relevant keys, or reinstalling an operating system, assess the potential impact on License authorization.
This helps avoid discovering an authorization problem during a planned maintenance window.
Conclusion
When GBase Database shows close after installation, reinstalling the cluster is not necessarily the right first move. Check the License, confirm the exact release, and verify authorization across the relevant nodes before moving on to more disruptive troubleshooting.
For GBase Database(GBase 8a), the key lesson is simple: installation completion, License validity, and cluster readiness are separate checks.
A reliable deployment process requests the correct License before installation, loads it using the supported procedure, verifies the result afterward, and documents the evidence for handover.
Have you encountered a GBase Database cluster that installed successfully but remained in close? What was the root cause in your environment?
Top comments (0)