Real-time data replication to Aerospike from your operational databases

• Platform engineers running low-latency applications on Aerospike who need current records from the systems of record, without a loader written for each table
• Data platform leads who want one Core Hub for every source feeding Aerospike, backed by best-in-class enterprise support, rated 4.9/5 by customers
• Architects placing Aerospike beside existing Oracle or SQL Server applications who need to see which sources feed which namespaces, where agents run, and how the cluster is reached over TLS
• Engineers retiring custom loaders or Kafka sinks into Aerospike who want every source delivered by one product, with snapshots and monitoring built in

The write path: the Aerospike Java SDK, in optimized pages

The Aerospike agent is a target agent built on the vendor-supported Aerospike Java SDK, which Gluesync bundles. It receives changes from any Gluesync source agent and writes them straight to the namespace through the SDK, with no intermediate buffer on the agent.

• Optimized batches, never row by row: Core Hub groups incoming changes into chunks, and the agent writes them in pages. Page size is configurable per agent, so you match each request to your network and cluster.
• Compression: optional client-side compression before data leaves the agent, for links where bandwidth matters more than CPU. Aerospike agent overview ↗

Snapshot first, then changes, into the namespace

• Seed, then stream: a full snapshot loads each source table into Aerospike, then the entity switches to CDC from the source agent's change mechanism, with inserts, updates, and deletes applied as they arrive.
• Namespace: the database name you enter in Core Hub is the target namespace that every entity in the pipeline writes to.
• Parallel and resumable snapshots: snapshot writing concurrency is configurable per entity, logical partitioning reads large source tables in parallel ranges, and an interrupted snapshot resumes from its last saved state.
• Scheduled refreshes: the Chronos Scheduler runs snapshots, or a snapshot followed by CDC, on a schedule when you prefer to reload a set on a cadence. See schedules and events.

Keys, bins, and field names

• Keys and bins: Aerospike identifies each record by a key and stores its values in named bins, and the agent writes each source row into that model.
• Short bin names: Aerospike keeps bin names short, so the entity editor lets you rename each source field to a compact bin name when you create or edit the entity, and Core Hub checks the names before you continue.
• Shaping on the way in: Unlock Schema, Custom Field Functions, and UDFs compose and reshape values before they are written, and Allowed Operations decides per entity which operations reach the namespace. See data transformation.

Connectivity and TLS to the cluster

• Discovery: point the agent at one node or a DNS name, and it discovers the other nodes. An optional list of additional hosts gives the client a cluster map at startup, so the connection works even when the first host is down.
• Port: 3000 by default.
• TLS: enable TLS and set the TLS name. Supply a trust store and a key store in the Java formats. Client certificate chains and PKCS #12 key stores are prepared with keytool and openssl, as shown in the target setup guide ↗.

What your Aerospike admin sets up

Create a user with access to the target namespace, then enter the cluster details in Core Hub. Field-by-field settings and REST examples are in the target setup guide ↗.

1. Create a user with read and write access to the target namespace, and note its username and password.
2. Enter the node address and port 3000 in Core Hub, and the namespace name as the database name.
3. Enable TLS for production, then provide the trust store and key store paths and passwords.
4. Leave authentication on for production. The disable option exists for development instances.

Architecture around Core Hub

Lightweight agents sit close to each source, and Core Hub orchestrates them through its web UI and REST APIs and routes changes to the Aerospike agent. A pipeline groups a source agent, the Aerospike agent, and the entities they replicate, so SQL Server and Oracle pipelines can feed the same namespace side by side.

Core Hub and its agents deploy with Docker, Docker Compose, or Kubernetes, on-premises or in any cloud, which lets the Aerospike agent run in the same Kubernetes cluster as the applications it serves. See CDC streaming.

Explore the general CDC streaming architecture →

Any Gluesync source agent can feed Aerospike, each with its own native capture technique. Open the integrations finder with Aerospike pre-selected to see every source you can pair with it.

One Core Hub can run Oracle to Aerospike, SQL Server to Aerospike, and PostgreSQL to Aerospike side by side, each with its own snapshot and monitoring. Gluesync keeps pace with your change volume at any scale, and the page settings are configurable per agent; MOLO17 Professional Services can tune them with your team.

• Oracle to Aerospike from the redo logs through LogMiner or XStream, for records served beside Oracle-backed applications: see Oracle CDC
• SQL Server to Aerospike through Change Data Capture or Change Tracking: see SQL Server CDC
• PostgreSQL and MySQL to Aerospike from the WAL and the binlog: see PostgreSQL CDC and MySQL CDC
• IBM i (AS/400) to Aerospike through the native journal APIs: see IBM i CDC