Config

const Aerospike = require('aerospike')

let config = {
  hosts: '192.168.1.10,192.168.1.11',
  user: process.env.DATABASE_USER,
  password: process.env.DATABASE_PASSWORD,
  policies: {
    read: new Aerospike.ReadPolicy({
      totalTimeout: 0
    })
  },
  log: {
    level: Aerospike.log.INFO,
    file: 2 // log to stderr
  }
}

Aerospike.connect(config)
  .then(client => {
    // client is ready to accept commands
    client.close()
  })
  .catch(error => {
    console.error('Failed to connect to cluster: %s', error.message)
  })


// Initializes a new client configuration from the given config values.

Members

authMode :number

Authentication mode used when user/password is defined.

Description:

• One of the auth modes defined in module:aerospike.auth.

Source:

• config.js, line 91

See:

• module:aerospike.auth

Type:

• number

clusterName :string

Expected Cluster Name.

Description:

• If not null, server nodes must return this cluster name in order to join the client's view of the cluster. Should only be set when connecting to servers that support the "cluster-name" info command.

Source:

• config.js, line 102

Since:

• v2.4

Type:

• string

connTimeoutMs :number

Initial host connection timeout in milliseconds.

Description:

• The client observes this timeout when opening a connection to the cluster for the first time.

Source:

• config.js, line 328

Default Value:

• 1000

Type:

• number

errorRateWindow :number

The number of cluster tend iterations that defines the window for Config#maxErrorRate to be surpassed. One tend iteration is defined as Config#tendInterval plus the time to tend all nodes. At the end of the window, the error count is reset to zero and backoff state is removed on all nodes.

Source:

• config.js, line 425

Default Value:

• 1

Type:

• number

hosts :Array.<Host>|string

List of hosts with which the client should attempt to connect.

Description:

• If not specified, the client attempts to read the host list from the AEROSPIKE_HOSTS environment variable or else falls back to use a default value of "localhost".

Source:

• config.js, line 228

Type:

• Array.<Host> | string

Examples

Setting hosts using a string:

const Aerospike = require('aerospike')

const hosts = '192.168.0.1:3000,192.168.0.2:3000'
const client = await Aerospike.connect({ hosts })

Setting hosts using an array of hostname/port tuples:

const Aerospike = require('aerospike')

const hosts = [
  { addr: '192.168.0.1', port: 3000 },
  { addr: '192.168.0.2', port: 3000 }
]
const client = await Aerospike.connect({ hosts })

Setting hosts with TLS name using a string:

const Aerospike = require('aerospike')

const hosts = '192.168.0.1:example.com:3000,192.168.0.2:example.com:3000'
const client = await Aerospike.connect({ hosts })

Setting hosts using an array of hostname/port/tlsname tuples:

const Aerospike = require('aerospike')

const hosts = [
  { addr: '192.168.0.1', port: 3000, tlsname: 'example.com' },
  { addr: '192.168.0.2', port: 3000, tlsname: 'example.com' }
]
const client = await Aerospike.connect({ hosts })

log :Object

Configuration for logging done by the client.

Source:

• config.js, line 292

Properties:

Type:

• Object

Example

Enabling debug logging to a separate log file

const Aerospike = require('aerospike')

const fs = require('fs')

var debuglog = fs.openSync('./debug.log', 'w')
// INSERT HOSTNAME AND PORT NUMBER OF AEROSPIKE SERVER NODE HERE!
var config = {
  hosts: '192.168.33.10:3000',
  log: {
    level: Aerospike.log.DEBUG,
    file: debuglog
  }
}
Aerospike.connect(config, (err, client) => {
  if (err) throw err
  console.log("Connected. Now closing connection.")
  client.close()
})

loginTimeoutMs :number

Node login timeout in milliseconds.

Source:

• config.js, line 340

Default Value:

• 5000

Type:

• number

maxConnsPerNode :number

Maximum number of asynchronous connections allowed per server node.

Description:

• New transactions will be rejected with an ERR_NO_MORE_CONNECTIONS error if the limit would be exceeded.

Source:

• config.js, line 386

Default Value:

• 100

Type:

• number

maxErrorRate :number

Maximum number of errors allowed per node per error_rate_window before backoff algorithm returns AEROSPIKE_MAX_ERROR_RATE for database commands to that node. If max_error_rate is zero, there is no error limit. The counted error types are any error that causes the connection to close (socket errors and client timeouts), server device overload and server timeouts.

The application should backoff or reduce the transaction load until AEROSPIKE_MAX_ERROR_RATE stops being returned.

Description:

• If the backoff algorithm has been activated, transactions will fail with AEROSPIKE_MAX_ERROR_RATE until the Config#errorRateWindow has passed and the error count has been reset.

Source:

• config.js, line 403

Default Value:

• 100

Type:

• number

maxSocketIdle :number

Maximum socket idle time in seconds.

Description:

• Connection pools will discard sockets that have been idle longer than the maximum. The value is limited to 24 hours (86400).

  It's important to set this value to a few seconds less than the server's proto-fd-idle-ms (default 60000 milliseconds or 1 minute), so the client does not attempt to use a socket that has already been reaped by the server.

  Connection pools are now implemented by a LIFO stack. Connections at the tail of the stack will always be the least used. These connections are checked for maxSocketIdle once every 30 tend iterations (usually 30 seconds).

Source:

• config.js, line 350

Default Value:

• 0 seconds

Type:

• number

minConnsPerNode :number

Minimum number of asynchronous connections allowed per server node.

Description:

• Preallocate min connections on client node creation. The client will periodically allocate new connections if count falls below min connections.

  Server proto-fd-idle-ms may also need to be increased substantially if min connections are defined. The proto-fd-idle-ms default directs the server to close connections that are idle for 60 seconds which can defeat the purpose of keeping connections in reserve for a future burst of activity.

  If server proto-fd-idle-ms is changed, client Config#maxSocketIdle should also be changed to be a few seconds less than proto-fd-idle-ms.

Source:

• config.js, line 439

Default Value:

• 0

Type:

• number

modlua :Object

Configuration values for the mod-lua user path.

Description:

• If you are using user-defined functions (UDF) for processing query results (i.e. aggregations), then you will find it useful to set the modlua settings. Of particular importance is the modelua.userPath, which allows you to define a path to where the client library will look for Lua files for processing.

Source:

• config.js, line 477

Properties:

Type:

• Object

password :string

The password to use when authenticating to the cluster.

Source:

• config.js, line 82

Type:

• string

policies :Policies

Global client policies.

Description:

• The configuration defines default policies for the application. Policies define the behavior of the client, which can be global for all uses of a single type of operation, or local to a single use of an operation.

  Each database operation accepts a policy for that operation as an argument. This is considered a local policy, and is a single use policy. This local policy supersedes any global policy defined.

  If a value of the policy is not defined, then the rule is to fallback to the global policy for that operation. If the global policy for that operation is undefined, then the global default value will be used.

  If you find that you have behavior that you want every use of an operation to utilize, then you can specify the default policy as Config#policies.

  For example, the Client#put operation takes a WritePolicy parameter. If you find yourself setting the WritePolicy#key policy value for every call to Client.put, then you may find it beneficial to set the global WritePolicy in Config#policies, which all operations will use.

Source:

• config.js, line 287

Type:

• Policies

Example

Setting a default key policy for all write operations

const Aerospike = require('aerospike')

// INSERT HOSTNAME AND PORT NUMBER OF AEROSPIKE SERVER NODE HERE!
var config = {
  hosts: '192.168.33.10:3000',
  policies: {
    write: new Aerospike.WritePolicy({
      key: Aerospike.policy.key.SEND,
      socketTimeout : 0,
      totalTimeout : 0
    })
  }
}

let key = new Aerospike.Key('test', 'demo', 123)

Aerospike.connect(config)
  .then(client => {
    return client.put(key, {int: 42})
      .then(() => client.close())
      .catch(error => {
        throw error
        client.close()
      })
  })
  .catch(console.error)

port :number

Default port to use for any host address, that does not explicitly specify a port number. Default is 3000.

Source:

• config.js, line 114

Since:

• v2.4

Type:

• number

rackAware :boolean

Track server rack data.

Description:

• This field is useful when directing read commands to the server node that contains the key and exists on the same rack as the client. This serves to lower cloud provider costs when nodes are distributed across different racks/data centers.

  rackId config, PREFER_RACK replica policy, and server rack configuration must also be set to enable this functionality.

Source:

• config.js, line 557

Since:

• 3.8.0

Default Value:

• false

Type:

• boolean

rackId :number

Rack where this client instance resides.

Description:

• rackAware config, PREFER_RACK replica policy, and server rack configuration must also be set to enable this functionality.

Source:

• config.js, line 575

Since:

• 3.8.0

Default Value:

• 0

Type:

• number

sharedMemory :Object

Shared memory configuration.

Description:

• This allows multiple client instances running in separate processes on the same machine to share cluster status, including nodes and data partition maps. Each shared memory segment contains state for one Aerospike cluster. If there are multiple Aerospike clusters, a different key must be defined for each cluster.

Source:

• config.js, line 480

Tutorials:

• Managing Aerospike connections in a Node cluster

See:

• Operational Notes

Properties:

Type:

• Object

Example

Using shared memory in a clustered setup

const Aerospike = require('aerospike')
const cluster = require('cluster')

const config = {
  sharedMemory: {
    key: 0xa5000000
  }
}
const client = Aerospike.client(config)
const noWorkers = 4

if (cluster.isMaster) {
  // spawn new worker processes
  for (var i = 0; i < noWorkers; i++) {
    cluster.fork()
  }
} else {
  // connect to Aerospike cluster in each worker process
  client.connect((err) => { if (err) throw err })

  // handle incoming HTTP requests, etc.
  // http.createServer((request, response) => { ... })

  // close DB connection on shutdown
  client.close()
}

tenderInterval :number

Polling interval in milliseconds for cluster tender.

Source:

• config.js, line 376

Default Value:

• 1000

Type:

• number

tls :Object

Configure Transport Layer Security (TLS) parameters for secure connections to the database cluster. TLS connections are not supported as of Aerospike Server v3.9 and depend on a future server release.

Source:

• config.js, line 128

Since:

• v2.4

Properties:

Type:

• Object

useAlternateAccessAddress :boolean

Whether the client should use the server's alternate-access-address instead of the access-address.

Source:

• config.js, line 545

Since:

• v3.7.1

Default Value:

• false

Type:

• boolean

user :string

The user name to use when authenticating to the cluster.

Description:

• Leave empty for clusters running without access management. (Security features are available in the Aerospike Database Enterprise Edition.)

Source:

• config.js, line 70

Type:

• string

Methods

setDefaultPolicies(one)

Description:

• Set default policies from the given policy values.

Source:

• config.js, line 598

Parameters:

Throws:

if any of the properties of the policies object is not a valid policy type

Type

TypeError