Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
MongoDB::MongoClient(3User Contributed Perl DocumentatiMongoDB::MongoClient(3)

NAME
       MongoDB::MongoClient - A	connection to a	MongoDB	server or multi-server
       deployment

VERSION
       version v2.2.2

SYNOPSIS
	   use MongoDB;	# also loads MongoDB::MongoClient

	   # connect to	localhost:27017
	   my $client =	MongoDB::MongoClient->new;

	   # connect to	specific host and port
	   my $client =	MongoDB::MongoClient->new(
	       host => "mongodb://mongo.example.com:27017"
	   );

	   # connect to	a replica set (set name	*required*)
	   my $client =	MongoDB::MongoClient->new(
	       host => "mongodb://mongo1.example.com,mongo2.example.com",
	       replica_set_name	=> 'myset',
	   );

	   # connect to	a replica set with URI (set name *required*)
	   my $client =	MongoDB::MongoClient->new(
	       host => "mongodb://mongo1.example.com,mongo2.example.com/?replicaSet=myset",
	   );

	   my $db = $client->get_database("test");
	   my $coll = $db->get_collection("people");

	   $coll->insert({ name	=> "John Doe", age => 42 });
	   my @people =	$coll->find()->all();

DESCRIPTION
       The "MongoDB::MongoClient" class	represents a client connection to one
       or more MongoDB servers.

       By default, it connects to a single server running on the local machine
       listening on the	default	port 27017:

	   # connects to localhost:27017
	   my $client =	MongoDB::MongoClient->new;

       It can connect to a database server running anywhere, though:

	   my $client =	MongoDB::MongoClient->new(host => 'example.com:12345');

       See the "host" attribute	for more options for connecting	to MongoDB.

       MongoDB can be started in authentication	mode
       <http://docs.mongodb.org/manual/core/authentication/>, which requires
       clients to log in before	manipulating data.  By default,	MongoDB	does
       not start in this mode, so no username or password is required to make
       a fully functional connection.  To configure the	client for
       authentication, see the "AUTHENTICATION"	section.

       The actual socket connections are lazy and created on demand.  When the
       client object goes out of scope,	all socket will	be closed.  Note that
       MongoDB::Database, MongoDB::Collection and related classes could	hold a
       reference to the	client as well.	 Only when all references are out of
       scope will the sockets be closed.

ATTRIBUTES
   host
       The "host" attribute specifies either a single server to	connect	to (as
       "hostname" or "hostname:port"), or else a connection string URI with a
       seed list of one	or more	servers	plus connection	options.

       NOTE: Options specified in the connection string	take precedence	over
       options provided	as constructor arguments.

       Defaults	to the connection string URI "mongodb://localhost:27017".

       For IPv6	support, you must have a recent	version	of IO::Socket::IP
       installed.  This	module ships with the Perl core	since v5.20.0 and is
       available on CPAN for older Perls.

   app_name
       This attribute specifies	an application name that should	be associated
       with this client.  The application name will be communicated to the
       server as part of the initial connection	handshake, and will appear in
       connection-level	and operation-level diagnostics	on the server
       generated on behalf of this client.  This may be	set in a connection
       string with the "appName" option.

       The default is the empty	string,	which indicates	a lack of an
       application name.

       The application name must not exceed 128	bytes.

   auth_mechanism
       This attribute determines how the client	authenticates with the server.
       Valid values are:

       o   NONE

       o   DEFAULT

       o   MONGODB-CR

       o   MONGODB-X509

       o   GSSAPI

       o   PLAIN

       o   SCRAM-SHA-1

       If not specified, then if no username or	"authSource" URI option	is
       provided, it defaults to	NONE.  Otherwise, it is	set to DEFAULT,	which
       chooses SCRAM-SHA-1 if available	or MONGODB-CR otherwise.

       This may	be set in a connection string with the "authMechanism" option.

   auth_mechanism_properties
       This is an optional hash	reference of authentication mechanism specific
       properties.  See	"AUTHENTICATION" for details.

       This may	be set in a connection string with the
       "authMechanismProperties" option.  If given, the	value must be
       key/value pairs joined with a ":".  Multiple pairs must be separated by
       a comma.	 If ": or "," appear in	a key or value,	they must be URL
       encoded.

   bson_codec
       An object that provides the "encode_one"	and "decode_one" methods, such
       as from BSON.  It may be	initialized with a hash	reference that will be
       coerced into a new BSON object.

       If not provided,	a BSON object with default values will be generated.

   compressors
       An array	reference of compression type names. Currently,	"zlib",	"zstd"
       and "snappy" are	supported.

   zlib_compression_level
       An integer from "-1" to 9 specifying the	compression level to use when
       "compression" is	set to "zlib".

       Note: When the special value "-1" is given, the default compression
       level will be used.

   connect_timeout_ms
       This attribute specifies	the amount of time in milliseconds to wait for
       a new connection	to a server.

       The default is 10,000 ms.

       If set to a negative value, connection operations will block
       indefinitely until the server replies or	until the operating system
       TCP/IP stack gives up (e.g. if the name can't resolve or	there is no
       process listening on the	target host/port).

       A zero value polls the socket during connection and is thus likely to
       fail except when	talking	to a local process (and	perhaps	even then).

       This may	be set in a connection string with the "connectTimeoutMS"
       option.

   db_name
       Optional.  If an	"auth_mechanism" requires a database for
       authentication, this attribute will be used.  Otherwise,	it will	be
       ignored.	Defaults to "admin".

       This may	be provided in the connection string URI as a path between the
       authority and option parameter sections.	 For example, to authenticate
       against the "admin" database (showing a configuration option only for
       illustration):

	   mongodb://localhost/admin?readPreference=primary

   heartbeat_frequency_ms
       The time	in milliseconds	(non-negative) between scans of	all servers to
       check if	they are up and	update their latency.  Defaults	to 60,000 ms.

       This may	be set in a connection string with the "heartbeatFrequencyMS"
       option.

   j
       If true,	the client will	block until write operations have been
       committed to the	server's journal. Prior	to MongoDB 2.6,	this option
       was ignored if the server was running without journaling. Starting with
       MongoDB 2.6, write operations will fail if this option is used when the
       server is running without journaling.

       This may	be set in a connection string with the "journal" option	as the
       strings 'true' or 'false'.

   local_threshold_ms
       The width of the	'latency window': when choosing	between	multiple
       suitable	servers	for an operation, the acceptable delta in milliseconds
       (non-negative) between shortest and longest average round-trip times.
       Servers within the latency window are selected randomly.

       Set this	to "0" to always select	the server with	the shortest average
       round trip time.	 Set this to a very high value to always randomly
       choose any known	server.

       Defaults	to 15 ms.

       See "SERVER SELECTION" for more details.

       This may	be set in a connection string with the "localThresholdMS"
       option.

   max_staleness_seconds
       The "max_staleness_seconds" parameter represents	the maximum
       replication lag in seconds (wall	clock time) that a secondary can
       suffer and still	be eligible for	reads. The default is -1, which
       disables	staleness checks.  Otherwise, it must be a positive integer.

       Note: this will only be used for	server versions	3.4 or greater,	as
       that was	when support for staleness tracking was	added.

       If the read preference mode is 'primary', then "max_staleness_seconds"
       must not	be supplied.

       The "max_staleness_seconds" must	be at least the
       "heartbeat_frequency_ms"	plus 10	seconds	(which is how often the	server
       makes idle writes to the	oplog).

       This may	be set in a connection string with the "maxStalenessSeconds"
       option.

   max_time_ms
       Specifies the maximum amount of time in (non-negative) milliseconds
       that the	server should use for working on a database command.  Defaults
       to 0, which disables this feature.  Make	sure this value	is shorter
       than "socket_timeout_ms".

       Note: this will only be used for	server versions	2.6 or greater,	as
       that was	when the $maxTimeMS meta-operator was introduced.

       You are strongly	encouraged to set this variable	if you know your
       environment has MongoDB 2.6 or later, as	getting	a definitive error
       response	from the server	is vastly preferred over a getting a network
       socket timeout.

       This may	be set in a connection string with the "maxTimeMS" option.

   monitoring_callback
       Specifies a code	reference used to receive monitoring events.  See
       MongoDB::Monitoring for more details.

   password
       If an "auth_mechanism" requires a password, this	attribute will be
       used.  Otherwise, it will be ignored.

       This may	be provided in the connection string URI as a
       "username:password" pair	in the leading portion of the authority
       section before a	"@" character.	For example, to	authenticate as	user
       "mulder"	with password "trustno1":

	   mongodb://mulder:trustno1@localhost

       If the username or password have	a ":" or "@" in	it, they must be URL
       encoded.	 An empty password still requires a ":"	character.

   port
       If a network port is not	specified as part of the "host"	attribute,
       this attribute provides the port	to use.	 It defaults to	27107.

   read_concern_level
       The read	concern	level determines the consistency level required	of
       data being read.

       The default level is "undef", which means the server will use its
       configured default.

       If the level is set to "local", reads will return the latest data a
       server has locally.

       Additional levels are storage engine specific.  See Read	Concern
       <http://docs.mongodb.org/manual/search/?query=readConcern> in the
       MongoDB documentation for more details.

       This may	be set in a connection string with the the "readConcernLevel"
       option.

   read_pref_mode
       The read	preference mode	determines which server	types are candidates
       for a read operation.  Valid values are:

       o   primary

       o   primaryPreferred

       o   secondary

       o   secondaryPreferred

       o   nearest

       For core	documentation on read preference see
       <http://docs.mongodb.org/manual/core/read-preference/>.

       This may	be set in a connection string with the "readPreference"
       option.

   read_pref_tag_sets
       The "read_pref_tag_sets"	parameter is an	ordered	list of	tag sets used
       to restrict the eligibility of servers, such as for data	center
       awareness.  It must be an array reference of hash references.

       The application of "read_pref_tag_sets" varies depending	on the
       "read_pref_mode"	parameter.  If the "read_pref_mode" is 'primary', then
       "read_pref_tag_sets" must not be	supplied.

       For core	documentation on read preference see
       <http://docs.mongodb.org/manual/core/read-preference/>.

       This may	be set in a connection string with the "readPreferenceTags"
       option.	If given, the value must be key/value pairs joined with	a ":".
       Multiple	pairs must be separated	by a comma.  If	": or "," appear in a
       key or value, they must be URL encoded.	The "readPreferenceTags"
       option may appear more than once, in which case each document will be
       added to	the tag	set list.

   replica_set_name
       Specifies the replica set name to connect to.  If this string is	non-
       empty, then the topology	is treated as a	replica	set and	all server
       replica set names must match this or they will be removed from the
       topology.

       This may	be set in a connection string with the "replicaSet" option.

   retry_reads
   retry_writes
       Whether the client should use retryable writes for supported commands.
       The default value is true, which	means that commands which support
       retryable writes	will be	retried	on certain errors, such	as "not
       master" and "node is recovering"	errors.

       This may	be set in a connection string with the "retryWrites" option.

       Note that this is only supported	on MongoDB > 3.6 in Replica Set	or
       Shard Clusters, and will	be ignored on other deployments.

       Unacknowledged write operations also do not support retryable writes,
       even when retry_writes has been enabled.

       The supported single statement write operations are currently as
       follows:

       o   "insert_one"

       o   "update_one"

       o   "replace_one"

       o   "delete_one"

       o   "find_one_and_delete"

       o   "find_one_and_replace"

       o   "find_one_and_update"

       The supported multi statement write operations are as follows:

       o   "insert_many"

       o   "bulk_write"

       The multi statement operations may be ether ordered or unordered. Note
       that for	"bulk_write" operations, the request may not include
       update_many or delete_many operations.

   server_selection_timeout_ms
       This attribute specifies	the amount of time in milliseconds to wait for
       a suitable server to be available for a read or write operation.	 If no
       server is available within this time period, an exception will be
       thrown.

       The default is 30,000 ms.

       See "SERVER SELECTION" for more details.

       This may	be set in a connection string with the
       "serverSelectionTimeoutMS" option.

   server_selection_try_once
       This attribute controls whether the client will make only a single
       attempt to find a suitable server for a read or write operation.	 The
       default is true.

       When true, the client will not use the "server_selection_timeout_ms".
       Instead,	if the topology	information is stale and needs to be checked
       or if no	suitable server	is available, the client will make a single
       scan of all known servers to try	to find	a suitable one.

       When false, the client will continually scan known servers until	a
       suitable	server is found	or the "serverSelectionTimeoutMS" is reached.

       See "SERVER SELECTION" for more details.

       This may	be set in a connection string with the
       "serverSelectionTryOnce"	option.

   server_selector
       Optional. This takes a function that augments the server	selection
       rules.  The function takes as a parameter a list	of server descriptions
       representing the	suitable servers for the read or write operation, and
       returns a list of server	descriptions that should still be considered
       suitable. Most users should rely	on the default server selection
       algorithm and should not	need to	set this attribute.

   socket_check_interval_ms
       If a socket to a	server has not been used in this many milliseconds, an
       "ismaster" command will be issued to check the status of	the server
       before issuing any reads	or writes. Must	be non-negative.

       The default is 5,000 ms.

       This may	be set in a connection string with the "socketCheckIntervalMS"
       option.

   socket_timeout_ms
       This attribute specifies	the amount of time in milliseconds to wait for
       a reply from the	server before issuing a	network	exception.

       The default is 30,000 ms.

       If set to a negative value, socket operations will block	indefinitely
       until the server	replies	or until the operating system TCP/IP stack
       gives up.

       The driver automatically	sets the TCP keepalive option when
       initializing the	socket.	For keepalive related issues, check the
       MongoDB documentation for Does TCP keepalive time affect	MongoDB
       Deployments? <https://docs.mongodb.com/v3.2/faq/diagnostics/#does-tcp-
       keepalive-time-affect-mongodb-deployments>.

       A zero value polls the socket for available data	and is thus likely to
       fail except when	talking	to a local process (and	perhaps	even then).

       This may	be set in a connection string with the "socketTimeoutMS"
       option.

   ssl
	   ssl => 1
	   ssl => \%ssl_options

       This tells the driver that you are connecting to	an SSL mongodb
       instance.

       You must	have IO::Socket::SSL 1.42+ and Net::SSLeay 1.49+ installed for
       SSL support.

       The "ssl" attribute takes either	a boolean value	or a hash reference of
       options to pass to IO::Socket::SSL.  For	example, to set	a CA file to
       validate	the server certificate and set a client	certificate for	the
       server to validate, you could set the attribute like this:

	   ssl => {
	       SSL_ca_file   =>	"/path/to/ca.pem",
	       SSL_cert_file =>	"/path/to/client.pem",
	   }

       If "SSL_ca_file"	is not provided, server	certificates are verified
       against a default list of CAs, either Mozilla::CA or an operating-
       system-specific default CA file.	 To disable verification, you can use
       "SSL_verify_mode	=> 0x00".

       You are strongly	encouraged to use your own CA file for increased
       security.

       Server hostnames	are also validated against the CN name in the server
       certificate using "SSL_verifycn_scheme => 'http'".  You can use the
       scheme 'none' to	disable	this check.

       Disabling certificate or	hostname verification is a security risk and
       is not recommended.

       This may	be set to the string 'true' or 'false' in a connection string
       with the	"ssl" option, which will enable	ssl with default
       configuration.  (See connection string URI for additional TLS
       configuration options.)

   username
       Optional	username for this client connection.  If this field is set,
       the client will attempt to authenticate when connecting to servers.
       Depending on the	"auth_mechanism", the "password" field or other
       attributes will need to be set for authentication to succeed.

       This may	be provided in the connection string URI as a
       "username:password" pair	in the leading portion of the authority
       section before a	"@" character.	For example, to	authenticate as	user
       "mulder"	with password "trustno1":

	   mongodb://mulder:trustno1@localhost

       If the username or password have	a ":" or "@" in	it, they must be URL
       encoded.	 An empty password still requires a ":"	character.

   w
       The client write	concern.

       o   0 Unacknowledged. MongoClient will NOT wait for an acknowledgment
	   that	the server has received	and processed the request. Older
	   documentation may refer to this as "fire-and-forget"	mode.  This
	   option is not recommended.

       o   1 Acknowledged. MongoClient will wait until the primary MongoDB
	   acknowledges	the write.

       o   2 Replica acknowledged. MongoClient will wait until at least	two
	   replicas (primary and one secondary)	acknowledge the	write. You can
	   set a higher	number for more	replicas.

       o   "all" All replicas acknowledged.

       o   "majority" A	majority of replicas acknowledged.

       If not set, the server default is used, which is	typically "1".

       In MongoDB v2.0+, you can "tag" replica members.	With "tagging" you can
       specify a custom	write concern For more information see Data Center
       Awareness <http://docs.mongodb.org/manual/data-center-awareness/>

       This may	be set in a connection string with the "w" option.

   wtimeout
       The number of milliseconds an operation should wait for "w" secondaries
       to replicate it.

       Defaults	to 1000	(1 second). If you set this to undef, it could block
       indefinitely (or	until socket timeout is	reached).

       See "w" above for more information.

       This may	be set in a connection string with the "wTimeoutMS" option.

METHODS
   read_preference
       Returns a MongoDB::ReadPreference object	constructed from
       "read_pref_mode"	and "read_pref_tag_sets"

       The use of "read_preference" as a mutator has been removed.  Read
       preference is read-only.	 If you	need a different read preference for a
       database	or collection, you can specify that in "get_database" or
       "get_collection".

   write_concern
       Returns a MongoDB::WriteConcern object constructed from "w",
       "write_concern" and "j".

   read_concern
       Returns a MongoDB::ReadConcern object constructed from
       "read_concern_level".

   topology_type
       Returns an enumerated topology type.  If	the "replica_set_name" is set,
       the value will be either	'ReplicaSetWithPrimary'	or
       'ReplicaSetNoPrimary' (if the primary is	down or	not yet	discovered).
       Without "replica_set_name", if there is more than one server in the
       list of hosts, the type will be 'Sharded'.

       With only a single host and no replica set name,	the topology type will
       start as	'Direct' until the server is contacted the first time, after
       which the type will be 'Sharded'	for a mongos or	'Single' for
       standalone server or direct connection to a replica set member.

   connect
	   $client->connect;

       Calling this method is unnecessary, as connections are established
       automatically as	needed.	 It is kept for	backwards compatibility.
       Calling it will check all servers in the	deployment which ensures a
       connection to any that are available.

       See "reconnect" for a method that is useful when	using forks or
       threads.

   disconnect
	   $client->disconnect;

       Drops all connections to	servers.

   reconnect
	   $client->reconnect;

       This method closes all connections to the server, as if "disconnect"
       were called, and	then immediately reconnects.  It also clears the
       session cache.  Use this	after forking or spawning off a	new thread.

   topology_status
	   $client->topology_status;
	   $client->topology_status( refresh =>	1 );

       Returns a hash reference	with server topology information like this:

	   {
	       'topology_type' => 'ReplicaSetWithPrimary'
	       'replica_set_name' => 'foo',
	       'last_scan_time'	  => '1433766895.183241',
	       'servers'	  => [
		   {
		       'address'     =>	'localhost:50003',
		       'ewma_rtt_ms' =>	'0.223462326',
		       'type'	     =>	'RSSecondary'
		   },
		   {
		       'address'     =>	'localhost:50437',
		       'ewma_rtt_ms' =>	'0.268435456',
		       'type'	     =>	'RSArbiter'
		   },
		   {
		       'address'     =>	'localhost:50829',
		       'ewma_rtt_ms' =>	'0.737782272',
		       'type'	     =>	'RSPrimary'
		   }
	       },
	   }

       If the 'refresh'	argument is true, then the topology will be scanned to
       update server data before returning the hash reference.

   start_session
	   $client->start_session;
	   $client->start_session( $options );

       Returns a new MongoDB::ClientSession with the supplied options.

       will throw a "MongoDB::ConfigurationError" if sessions are not
       supported by the	connected MongoDB deployment.

       the options hash	is an optional hash which can have the following keys:

       o   "causalConsistency" - Enable	Causally Consistent reads for this
	   session. Defaults to	true.

       for more	information see	"options" in MongoDB::ClientSession.

   list_databases
	   # get all information on all	databases
	   my @dbs = $client->list_databases;

	   # get only the foo databases
	   my @foo_dbs = $client->list_databases({ filter => { name => qr/^foo/	} });

       Lists all databases with	information on each database. Supports
       filtering by any	of the output fields under the "filter"	argument, such
       as:

       o   "name"

       o   "sizeOnDisk"

       o   "empty"

       o   "shards"

   database_names
	   my @dbs = $client->database_names;

	   # get only the foo database names
	   my @foo_dbs = $client->database_names({ filter => { name => qr/^foo/	} });

       List of all database names on the MongoDB server. Supports filters in
       the same	way as "list_databases".

   get_database, db
	   my $database	= $client->get_database('foo');
	   my $database	= $client->get_database('foo', $options);
	   my $database	= $client->db('foo', $options);

       Returns a MongoDB::Database instance for	the database with the given
       $name.

       It takes	an optional hash reference of options that are passed to the
       MongoDB::Database constructor.

       The "db"	method is an alias for "get_database".

   get_namespace, ns
	   my $collection = $client->get_namespace('test.foo');
	   my $collection = $client->get_namespace('test.foo', $options);
	   my $collection = $client->ns('test.foo', $options);

       Returns a MongoDB::Collection instance for the given namespace.	The
       namespace has both the database name and	the collection name separated
       with a dot character.

       This is a quick way to get a collection object if you don't need	the
       database	object separately.

       It takes	an optional hash reference of options that are passed to the
       MongoDB::Collection constructor.	 The intermediate MongoDB::Database
       object will be created with default options.

       The "ns"	method is an alias for "get_namespace".

   fsync(\%args)
	   $client->fsync();

       A function that will forces the server to flush all pending writes to
       the storage layer.

       The fsync operation is synchronous by default, to run fsync
       asynchronously, use the following form:

	   $client->fsync({async => 1});

       The primary use of fsync	is to lock the database	during backup
       operations. This	will flush all data to the data	storage	layer and
       block all write operations until	you unlock the database. Note: you can
       still read while	the database is	locked.

	   $conn->fsync({lock => 1});

   fsync_unlock
	   $conn->fsync_unlock();

       Unlocks a database server to allow writes and reverses the operation of
       a $conn->fsync({lock => 1}); operation.

   watch
       Watches for changes on the cluster.

       Perform an aggregation with an implicit initial $changeStream stage and
       returns a MongoDB::ChangeStream result which can	be used	to iterate
       over the	changes	in the cluster.	This functionality is available	since
       MongoDB 4.0.

	   my $stream =	$client->watch();
	   my $stream =	$client->watch(	\@pipeline );
	   my $stream =	$client->watch(	\@pipeline, \%options );

	   while (1) {

	       # This inner loop will only run until no	more changes are
	       # available.
	       while (my $change = $stream->next) {
		   # process $change
	       }
	   }

       The returned stream will	not block forever waiting for changes. If you
       want to respond to changes over a longer	time use "maxAwaitTimeMS" and
       regularly call "next" in	a loop.

       See "watch" in MongoDB::Collection for details on usage and available
       options.

DEPLOYMENT TOPOLOGY
       MongoDB can operate as a	single server or as a distributed system.  One
       or more servers that collectively provide access	to a single logical
       set of MongoDB databases	are referred to	as a "deployment".

       There are three types of	deployments:

       o   Single server a a stand-alone mongod	database

       o   Replica set a a set of mongod databases with	data replication and
	   fail-over capability

       o   Sharded cluster aA a	distributed deployment that spreads data
	   across one or more shards, each of which can	be a replica set.
	   Clients communicate with a mongos process that routes operations to
	   the correct share.

       The state of a deployment, including its	type, which servers are
       members,	the server types of members and	the round-trip network latency
       to members is referred to as the	"topology" of the deployment.

       To the greatest extent possible,	the MongoDB driver abstracts away the
       details of communicating	with different deployment types.  It
       determines the deployment topology through a combination	of the
       connection string, configuration	options	and direct discovery
       communicating with servers in the deployment.

CONNECTION STRING URI
       MongoDB uses a pseudo-URI connection string to specify one or more
       servers to connect to, along with configuration options.

       NOTE: any non-printable ASCII characters	should be UTF-8	encoded	and
       converted URL-escaped characters.

       To connect to more than one database server, provide host or host:port
       pairs as	a comma	separated list:

	   mongodb://host1[:port1][,host2[:port2],...[,hostN[:portN]]]

       This list is referred to	as the "seed list".  An	arbitrary number of
       hosts can be specified.	If a port is not specified for a given host,
       it will default to 27017.

       If multiple hosts are given in the seed list or discovered by talking
       to servers in the seed list, they must all be replica set members or
       must all	be mongos servers for a	sharded	cluster.

       A replica set MUST have the "replicaSet"	option set to the replica set
       name.

       If there	is only	single host in the seed	list and "replicaSet" is not
       provided, the deployment	is treated as a	single server deployment and
       all reads and writes will be sent to that host.

       Providing a replica set member as a single host without the set name is
       the way to get a	"direct	connection" for	carrying out administrative
       activities on that server.

       The connection string may also have a username and password:

	   mongodb://username:password@host1:port1,host2:port2

       The username and	password must be URL-escaped.

       A optional database name	for authentication may be given:

	   mongodb://username:password@host1:port1,host2:port2/my_database

       Finally,	connection string options may be given as URI attribute	pairs
       in a query string:

	   mongodb://host1:port1,host2:port2/?ssl=1&wtimeoutMS=1000
	   mongodb://username:password@host1:port1,host2:port2/my_database?ssl=1&wtimeoutMS=1000

       The currently supported connection string options are:

       o   "appName"

       o   "authMechanism"

       o   "authMechanismProperties"

       o   "authSource"

       o   "compressors"

       o   "connect"

       o   "connectTimeoutMS"

       o   "heartbeatFrequencyMS"

       o   "journal"

       o   "localThresholdMS"

       o   "maxStalenessSeconds"

       o   "maxTimeMS"

       o   "readConcernLevel"

       o   "readPreference"

       o   "readPreferenceTags"

       o   "replicaSet"

       o   "retryReads"

       o   "retryWrites"

       o   "serverSelectionTimeoutMS"

       o   "serverSelectionTryOnce"

       o   "socketCheckIntervalMS"

       o   "socketTimeoutMS"

       o   "ssl"

       o   "tls" (an alias for "ssl")

       o   "tlsAllowInvalidCertificates"

       o   "tlsAllowInvalidHostnames"

       o   "tlsCAFile"

       o   "tlsCertificateKeyFile"

       o   "tlsCertificateKeyFilePassword"

       o   "tlsInsecure"

       o   "w"

       o   "wTimeoutMS"

       o   "zlibCompressionLevel"

       NOTE: Options specified in the connection string	take precedence	over
       options provided	as constructor arguments.

       See the official	MongoDB	documentation on connection strings for	more
       on the URI format and connection	string options:
       <http://docs.mongodb.org/manual/reference/connection-string/>.

SERVER SELECTION
       For a single server deployment or a direct connection to	a mongod or
       mongos, all reads and writes are	sent to	that server.  Any read-
       preference is ignored.

       When connected to a deployment with multiple servers, such as a replica
       set or sharded cluster, the driver chooses a server for operations
       based on	the type of operation (read or write), application-provided
       server selector,	the types of servers available and a read preference.

       For a replica set deployment, writes are	sent to	the primary (if
       available) and reads are	sent to	a server based on the
       "read_preference" attribute, which defaults to sending reads to the
       primary.	 See MongoDB::ReadPreference for more.

       For a sharded cluster reads and writes are distributed across mongos
       servers in the seed list.  Any read preference is passed	through	to the
       mongos and used by it when executing reads against shards.

       If multiple servers can service an operation (e.g. multiple mongos
       servers,	or multiple replica set	members), one is chosen	by filtering
       with server selector and	then at	random from within the "latency
       window".	 The server with the shortest average round-trip time (RTT) is
       always in the window.  Any servers with an average round-trip time less
       than or equal to	the shortest RTT plus the "local_threshold_ms" are
       also in the latency window.

       If a suitable server is not immediately available, what happens next
       depends on the "server_selection_try_once" option.

       If that option is true, a single	topology scan will be performed.
       Afterwards if a suitable	server is available, it	will be	returned;
       otherwise, an exception is thrown.

       If that option is false,	the driver will	do topology scans repeatedly
       looking for a suitable server.  When more than
       "server_selection_timeout_ms" milliseconds have elapsed since the start
       of server selection without a suitable server being found, an exception
       is thrown.

       Note: the actual	maximum	wait time for server selection could be	as
       long "server_selection_timeout_ms" plus the amount of time required to
       do a topology scan.

SERVER MONITORING AND FAILOVER
       When the	client first needs to find a server for	a database operation,
       all servers from	the "host" attribute are scanned to determine which
       servers to monitor.  If the deployment is a replica set,	additional
       hosts may be discovered in this process.	 Invalid hosts are dropped.

       After the initial scan, whenever	the servers have not been checked in
       "heartbeat_frequency_ms"	milliseconds, the scan will be repeated.  This
       amortizes monitoring time over many of operations.  Additionally, if a
       socket has been idle for	a while, it will be checked before being used
       for an operation.

       If a server operation fails because of a	"not master" or	"node is
       recovering" error, or if	there is a network error or timeout, then the
       server is flagged as unavailable	and exception will be thrown.  See
       MongoDB::Errors for exception types.

       If the error is caught and handled, the next operation will rescan all
       servers immediately to update its view of the topology.	The driver can
       continue	to function as long as servers are suitable per	"SERVER
       SELECTION".

       When catching an	exception, users must determine	whether	or not their
       application should retry	an operation based on the specific operation
       attempted and other use-case-specific considerations.  For automating
       retries despite exceptions, consider using the Try::Tiny::Retry module.

TRANSPORT LAYER	SECURITY
       Warning:	industry best practices, and some regulations, require the use
       of TLS 1.1 or newer.

       Some operating systems or versions may not provide an OpenSSL version
       new enough to support the latest	TLS protocols.	If your	OpenSSL
       library version number is less than 1.0.1, then support for TLS 1.1 or
       newer is	not available. Contact your operating system vendor for	a
       solution	or upgrade to a	newer operating	system distribution.

       See also	the documentation for Net::SSLeay for details on installing
       and compiling against OpenSSL.

       TLS connections in the driver rely on the default settings provided by
       IO::Socket::SSL,	but allow you to pass custom configuration to it.
       Please read its documentation carefully to see how to control your TLS
       configuration.

AUTHENTICATION
       The MongoDB server provides several authentication mechanisms, though
       some are	only available in the Enterprise edition.

       MongoDB client authentication is	controlled via the "auth_mechanism"
       attribute, which	takes one of the following values:

       NOTE: MONGODB-CR	was deprecated with the	release	of MongoDB 3.6 and is
       no longer supported by MongoDB 4.0.

       o   MONGODB-CR -- legacy	username-password challenge-response (<	4.0)

       o   SCRAM-SHA-1 -- secure username-password challenge-response (3.0+)

       o   MONGODB-X509	-- SSL client certificate authentication (2.6+)

       o   PLAIN -- LDAP authentication	via SASL PLAIN (Enterprise only)

       o   GSSAPI -- Kerberos authentication (Enterprise only)

       The mechanism to	use depends on the authentication configuration	of the
       server.	See the	core documentation on authentication:
       <http://docs.mongodb.org/manual/core/access-control/>.

       Usage information for each mechanism is given below.

   MONGODB-CR and SCRAM-SHA-1 (for username/password)
       These mechanisms	require	a username and password, given either as
       constructor attributes or in the	"host" connection string.

       If a username is	provided and an	authentication mechanism is not
       specified, the client will use SCRAM-SHA-1 for version 3.0 or later
       servers and will	fall back to MONGODB-CR	for older servers.

	   my $mc = MongoDB::MongoClient->new(
	       host => "mongodb://mongo.example.com/",
	       username	=> "johndoe",
	       password	=> "trustno1",
	   );

	   my $mc = MongoDB::MongoClient->new(
	       host => "mongodb://johndoe:trustno1@mongo.example.com/",
	   );

       Usernames and passwords will be UTF-8 encoded before use.  The password
       is never	sent over the wire -- only a secure digest is used.  The
       SCRAM-SHA-1 mechanism is	the Salted Challenge Response Authentication
       Mechanism defined in RFC	5802 <http://tools.ietf.org/html/rfc5802>.

       The default database for	authentication is 'admin'.  If another
       database	name should be used, specify it	with the "db_name" attribute
       or via the connection string.

	   db_name => auth_db

	   mongodb://johndoe:trustno1@mongo.example.com/auth_db

   MONGODB-X509	(for SSL client	certificate)
       X509 authentication requires SSL	support	(IO::Socket::SSL), requires
       that a client certificate be configured in the ssl parameters, and
       requires	specifying the "MONGODB-X509" authentication mechanism.

	   my $mc = MongoDB::MongoClient->new(
	       host => "mongodb://sslmongo.example.com/",
	       ssl => {
		   SSL_ca_file	 => "certs/ca.pem",
		   SSL_cert_file => "certs/client.pem",
	       },
	       auth_mechanism => "MONGODB-X509",
	   );

       Note: Since MongoDB Perl	driver v1.8.0, you no longer need to specify a
       "username" parameter for	X509 authentication; the username will be
       extracted automatically from the	certificate.

   PLAIN (for LDAP)
       This mechanism requires a username and password,	which will be UTF-8
       encoded before use.  The	"auth_mechanism" parameter must	be given as a
       constructor attribute or	in the "host" connection string:

	   my $mc = MongoDB::MongoClient->new(
	       host => "mongodb://mongo.example.com/",
	       username	=> "johndoe",
	       password	=> "trustno1",
	       auth_mechanism => "PLAIN",
	   );

	   my $mc = MongoDB::MongoClient->new(
	       host => "mongodb://johndoe:trustno1@mongo.example.com/authMechanism=PLAIN",
	   );

   GSSAPI (for Kerberos)
       Kerberos	authentication requires	the CPAN module	Authen::SASL and a
       GSSAPI-capable backend.

       On Debian systems, Authen::SASL may be available	as
       "libauthen-sasl-perl"; on RHEL systems, it may be available as
       "perl-Authen-SASL".

       The Authen::SASL::Perl backend comes with Authen::SASL and requires the
       GSSAPI CPAN module for GSSAPI support.  On Debian systems, this may be
       available as "libgssapi-perl"; on RHEL systems, it may be available as
       "perl-GSSAPI".

       Installing the GSSAPI module from CPAN rather than an OS	package
       requires	"libkrb5" and the "krb5-config"	utility	(available for
       Debian/RHEL systems in the "libkrb5-dev"	package).

       Alternatively, the Authen::SASL::XS or Authen::SASL::Cyrus modules may
       be used.	 Both rely on Cyrus "libsasl".	Authen::SASL::XS is preferred,
       but not yet available as	an OS package.	Authen::SASL::Cyrus is
       available on Debian as "libauthen-sasl-cyrus-perl" and on RHEL as
       "perl-Authen-SASL-Cyrus".

       Installing Authen::SASL::XS or Authen::SASL::Cyrus from CPAN requires
       "libsasl".  On Debian systems, it is available from "libsasl2-dev"; on
       RHEL, it	is available in	"cyrus-sasl-devel".

       To use the GSSAPI mechanism, first run "kinit" to authenticate with the
       ticket granting service:

	   $ kinit johndoe@EXAMPLE.COM

       Configure MongoDB::MongoClient with the principal name as the
       "username" parameter and	specify	'GSSAPI' as the	"auth_mechanism":

	   my $mc = MongoDB::MongoClient->new(
	       host => 'mongodb://mongo.example.com',
	       username	=> 'johndoe@EXAMPLE.COM',
	       auth_mechanism => 'GSSAPI',
	   );

       Both can	be specified in	the "host" connection string, keeping in mind
       that the	'@' in the principal name must be encoded as "%40":

	   my $mc = MongoDB::MongoClient->new(
	       host =>
		 'mongodb://johndoe%40EXAMPLE.COM@mongo.example.com/?authMechanism=GSSAPI',
	   );

       The default service name	is 'mongodb'.  It can be changed with the
       "auth_mechanism_properties" attribute or	in the connection string.

	   auth_mechanism_properties =>	{ SERVICE_NAME => 'other_service' }

	   mongodb://.../?authMechanism=GSSAPI&authMechanismProperties=SERVICE_NAME:other_service

THREAD-SAFETY AND FORK-SAFETY
       You MUST	call the "reconnect" method on any MongoDB::MongoClient
       objects after forking or	spawning a thread.

       NOTE: Per threads documentation,	use of Perl threads is discouraged by
       the maintainers of Perl and the MongoDB Perl driver does	not test or
       provide support for use with threads.

AUTHORS
       o   David Golden	<david@mongodb.com>

       o   Rassi <rassi@mongodb.com>

       o   Mike	Friedman <friedo@friedo.com>

       o   Kristina Chodorow <k.chodorow@gmail.com>

       o   Florian Ragwitz <rafl@debian.org>

COPYRIGHT AND LICENSE
       This software is	Copyright (c) 2020 by MongoDB, Inc.

       This is free software, licensed under:

	 The Apache License, Version 2.0, January 2004

perl v5.32.0			  2020-08-13	       MongoDB::MongoClient(3)

NAME | VERSION | SYNOPSIS | DESCRIPTION | ATTRIBUTES | METHODS | DEPLOYMENT TOPOLOGY | CONNECTION STRING URI | SERVER SELECTION | SERVER MONITORING AND FAILOVER | TRANSPORT LAYER SECURITY | AUTHENTICATION | THREAD-SAFETY AND FORK-SAFETY | AUTHORS | COPYRIGHT AND LICENSE

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=MongoDB::MongoClient&sektion=3&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help