MongoDB::MongoClient - phpMan

Command: man perldoc info search(apropos)  


MongoDB::MongoClient(3pm)      User Contributed Perl Documentation      MongoDB::MongoClient(3pm)

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 stand-alone mongod database

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

       o   Sharded cluster -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 AT mongo.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 AT mongo.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 AT mongo.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 AT 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 AT 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 AT mongo.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 AT mongodb.com>

       o   Rassi <rassi AT mongodb.com>

       o   Mike Friedman <friedo AT friedo.com>

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

       o   Florian Ragwitz <rafl AT 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.30.3                                2020-08-15                  MongoDB::MongoClient(3pm)

Generated by $Id: phpMan.php,v 4.55 2007/09/05 04:42:51 chedong Exp $ Author: Che Dong
On Apache
Under GNU General Public License
2024-12-12 19:37 @3.149.29.224 CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
Valid XHTML 1.0!Valid CSS!