Prepare and verify SQLink deployment

Implementation and operations teams should use the project's delivery manifest for packages, topology, sizing, and scripts. After service acceptance, proceed to metadata and lineage setup.

Prepare a deployment manifest

Area	Prepare	Verify
Topology	Standalone or DAM-integrated services and nodes	Match the delivered architecture
Hosts and storage	Hosts, addresses, deployment user, installation, data and log directories	Required access and planned capacity
Database	Instance, character and case settings, account, backups	Application connectivity and initialization privileges
Configuration	Nacos address, namespace, application settings, registration addresses	Reachability from actual clients
Network	Browser entry, interservice links, source connections	Every configured segment
License	Required file and machine information	Match license to deployment
Materials	Components, services, frontend, templates, scripts	Compatible packages in an archived manifest

Use the agreed deployment user and directories. Reference script paths do not authorize overwriting existing directories.

Components and responsibilities

Component	Responsibility	Verify
Relational database	Business persistence	Instance, account, database, case behavior
Nacos	Registration and configuration	Namespace, settings, registration
Redis	Cache	Address, authentication, runtime user
Elasticsearch	Full-text search	Service, permissions, resource limits
Nebula	Graph storage	Graph and registered storage nodes
Kafka	Messaging	Connections and configuration
User and base services	Identity and shared functions	Database and configuration connectivity
Metadata, scheduler, SQLink	Harvesting, execution, lineage	Logs, registration, interservice calls
Application gateway, Nginx	Backend routing and frontend	Targets, static directory, entry paths

The application gateway routes platform requests; DDS's security gateway performs dynamic masking. Deploy shared services such as standards according to the integration plan.

Install and configure

1. Prepare database and accounts with initialization permissions.
2. Install base components from the manifest and verify each, including registered Nebula storage nodes.
3. Extract matching service packages and scripts into agreed directories.
4. Configure registration address, ports, Nacos, and JVM memory for actual resources.
5. Publish configuration in the correct Nacos namespace; check database, component, and service links.
6. Start identity, base, and business services as the agreed user. Check process, port, logs, and registration after each.
7. Deploy frontend resources and Nginx routes. Verify SQLink entry and API paths.
8. Initialize licenses, roles, and sources, then perform acceptance checks.

Common configuration names include datablau_usermgmt.yaml, datablau_base.yaml, datablau_metadata.yaml, datablau_sqlink.yaml, and datablau_gateway.yaml. Use names and namespaces delivered with the actual packages.

Layered acceptance

Layer	Test	Pass criterion
Processes	Check components and services	Stable execution without exit or restart loops
Registration	Inspect Nacos	Correct reachable addresses and ports
Entry	Log in and open SQLink	Pages, resources, and business requests work
Metadata	Harvest a controlled source sample	Expected schemas, tables, and fields
Lineage	Parse a known script	Report and correct dependencies
Scheduling	Run a controlled schedule	Triggered on time with retained results
Permissions	Test business roles	Authorized visibility and operations

An accessible homepage does not validate harvesting, parsing, or scheduling. Retain environment summary, task IDs, times, samples, and conclusions.

Backups and recovery

Back up the database regularly and inventory graph data, uploads, service configurations, and frontend resources. Define scope, frequency, retention, and recovery order. One database backup does not prove whole-system recoverability.

Rehearse recovery in isolation. Verify login, counts, key paths, and task configuration. Check schedule state before allowing restored tasks to access sources.

Startup troubleshooting

Symptom	Check
Elasticsearch rejects root	Use the agreed non-root user and directory ownership
AccessDeniedException	Runtime access to configuration and data directories
File descriptor or memory map limit	Operations should adjust limits according to component errors
Missing registration or failed calls	Nacos, namespace, addresses, ports, network
Frontend works but APIs fail	Nginx, gateway, target service logs
Harvesting works but no lineage	SQLink and graph service, parsed results, namespace

Related: resource synchronization, parsing tasks, scheduling.