Captive Core is a specialised, narrowed-down Hcnet-Core instance with the sole aim of emitting transaction metadata to Aurora. It means:
Captive Hcnet Core completely eliminates all Aurora issues caused by connecting to Aurora Core’s database, but it requires extra time to initialize and manage its Aurora Core subprocess. Captive Core can be used in both reingestion (aurora db reingest range) and normal Aurora operation (aurora serve). In fact, using Captive Core to reingest historical data is considerably faster than without it.
When using Captive Core, Aurora runs the hcnet-core binary as a subprocess. Then, both processes communicate over filesystem pipe: Core sends xdr. LedgerCloseMeta structs with information about each ledger and Aurora reads it.
The behaviour is slightly different when reingesting old ledgers and when reading recently closed ledgers:
When reingesting, Hcnet Core is started in a special catchup mode that simply replays the requested range of ledgers. This mode requires an additional 3GiB of RAM because all ledger entries are stored in memory, making it extremely fast. This mode only depends on the history archives, so a Captive Core configuration is not required.
When reading recently closed ledgers, Core is started with a normal run command. This mode also requires an additional 3GiB of RAM for in-memory ledger entries. In this case, a configuration file is required in order to configure a quorum set so that it can connect to the Hcnet network.
Now you configure captive core configuration…………….
–file end
Once your Aurora database and Captive Core configuration is set up properly, you're ready to run Aurora. Run hcnet-aurora with the appropriate parameters set (or hcnet-aurora-cmd serve if you installed via the package manager, which will automatically import your configuration from /etc/default/hcnet-aurora), which starts the HTTP server and starts logging to standard out. When run, you should see output similar to:
-> Example
INFO[...] Starting aurora on :8000 pid=29013
Run this command in folder path -home/go/bin
This command is used
If you want to run Captive Core instances for transaction ingestion separately from other Aurora instances, we support that. This architecture allows flexibility in scaling and redundancy. For example, you may want each of your ingesting Aurora instances to have a dedicated Captive Core while your request-serving instances share a single Remote Captive Core for transaction submission. Or perhaps you want a dedicated Remote Captive Core living on more powerful hardware catered towards ingestion.
Support Agent
*Powered by HashCash