|
System information
PHP 7.0.15-1+deb.sury.org~trusty+1 (cli) (built: Jan 20 2017 09:16:11) ( NTS )
|
Copyright (c) 1997-2017 The PHP Group
|
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
|
with Zend OPcache v7.0.15-1+deb.sury.org~trusty+1, Copyright (c) 1999-2017, by Zend Technologies
|
|
pecl mongodb 1.2.5
|
mongodb 3.4.2
|
Ubuntu 14.04.5
|
Linux 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
|
We run a cluster with 27 shards and each application uses a local mongos to connect to it. We have the balancer stopped.
We often see Exception for querys to collections which are sharded. Everytime there is a change to shard version of the collection, our PHP clients report an error on a simple find operation. Sofar we have never seen an exception for our non PHP clients.
It seems that this issue was introduced with mongodb version 3.2.x, but we can also reproduce it on 3.4.2 in our dev environment.
To reproduce it in our dev environemnt I started to shard a collection, but I could also move a chunk or split a chunk. I choose this collection because we see problems for querys to this collection in production which runs version 3.2.10 and we hadn't sharded it in our dev environment so far (very small in dev).
There are no errors in router.log
Before we sharded the collection our PHP application showed no errors.
After sharding our PHP client reports:
[data.items] shard version not ok: version epoch mismatch detected for data.items, the collection may have been dropped and recreated ( ns : data.items, received : 0|0||000000000000000000000000, wanted : 1|0||58a46d88be4b4925a7638e2f, send ) /path/to/code/vendor/php/mongodb/Find.php (206) MongoDB\Driver\Server::executeQuery
|
Stacktrace:
[23]
|
File: /path/to/code/src/model/dfp/connectors/mdb/MdbLineItemConnector.php in line 68
|
Method: rg\ODM\MongoDB\Cursor->toArray
|
|
[24]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/rg/ODM/MongoDB/Cursor.php in line 277
|
Method: Doctrine\MongoDB\Cursor->toArray
|
Parameter: [true]
|
|
[25]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 629
|
Method: Doctrine\MongoDB\Cursor->retry
|
Parameter: [Closure, true]
|
|
[26]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
|
Method: Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
|
|
[27]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 628
|
Parameter: [rg\core\base\objectManagers\mongodb\LoggingCursor]
|
|
[28]
|
Method: rg\core\base\objectManagers\mongodb\LoggingCursor->rewind
|
|
[29]
|
File: /path/to/code/src/core/base/objectManagers/mongodb/LoggingCursor.php in line 253
|
Method: Doctrine\MongoDB\Cursor->rewind
|
|
[30]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 490
|
Method: Doctrine\MongoDB\Cursor->retry
|
Parameter: [Closure, false]
|
|
[31]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
|
Method: Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
|
|
[32]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 489
|
Method: Alcaeus\MongoDbAdapter\AbstractCursor->rewind
|
|
[33]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 190
|
Method: Alcaeus\MongoDbAdapter\AbstractCursor->ensureIterator
|
|
[34]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 297
|
Method: MongoCursor->ensureCursor
|
|
[35]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 443
|
Method: MongoCursor->doQuery
|
|
[36]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 166
|
Method: MongoDB\Collection->find
|
Parameter: [MongoDB\Model\BSONDocument: ['o' => MongoDB\Model\BSONDocument: ['$in' => ['0' => 123456, '1' => 275383959000, '2' => 114204279, '3' => 233433999, '4' => 233014719, '5' => 237809079, '6' => 247189479, '7' => 251772159, '8' => 260437839, '9' => 275383959, '10' => 285140199, [10more ...]]], '$comment' => 'cId f8688c0e3b4b6de7b86d0c38569fb290,vId 165...'], ['batchSize' => 0, 'modifiers' => [], 'projection' => [], 'readPreference' => MongoDB\Driver\ReadPreference, 'readConcern' => MongoDB\Driver\ReadConcern, 'typeMap' => ['array' => 'MongoDB\Model\BSONArray', 'document' => 'MongoDB\Model\BSONDocument', 'root' => 'MongoDB\Model\BSONDocument']]]
|
|
[37]
|
File: /path/to/code/vendor/composer/mongodb/mongodb/src/Collection.php in line 525
|
Method: MongoDB\Operation\Find->execute
|
Parameter: [MongoDB\Driver\Server: [MongoDB\Driver\Server Object
|
(
|
[host] => localhost
|
[port] => 27017
|
[type] => 2
|
[is_primary] =>
|
[is_secondary] =>
|
[is_arbiter] =>
|
[is_hidden] =>
|
[is_passive] =>
|
[last_is_master] => Array
|
(
|
[ismaster] => 1
|
[msg] => isdbgrid
|
[maxBsonObjectSize] => 16777216
|
[maxMessageSizeBytes] => 48000000
|
[maxWriteBatchSize] => 1000
|
[localTime] => MongoDB\BSON\UTCDateTime Object
|
(
|
[milliseconds] => 1487171166812
|
)
|
|
[maxWireVersion] => 5
|
[minWireVersion] => 0
|
[ok] => 1
|
)
|
|
[round_trip_time] => 0
|
)
|
]]
|
|
[38]
|
File: /path/to/code/vendor/php/mongodb/Find.php in line 206
|
Method: MongoDB\Driver\Server->executeQuery
|
Parameter: ['data.items', MongoDB\Driver\Query, MongoDB\Driver\ReadPreference]
|
To fix the router reporting this exception on a query we found 3 ways:
- restart router
- flushRouterConfig
- do a find query on this collection via mongo shell. (tested with version 3.4.2 only)
Could it be that routers only trigger chunk information updates when a client does an operation on a collection? -> this is broken for php driver only?
Since we can reproduce it in our dev environment with version 3.4.2, we our glad to debug this with your help.
This is a blocker for us in production since even the balancer is off, autosplits also cause this issue.
|
|
With new version we don't have this issue anymore.
|
|
Thanks jmikola for bringing me into the loop. I've released 1.0.11 for the adapter library which fixes what seems to be the root cause of this.
|
|
Cross-linking with an upstream issue on alcaeus/mongo-php-adapter#170 to address a batchSize of zero appearing in find commands.
|
|
Quoting an analysis from esha.maharishi:
Ah, so the issue is that the find is being issued with a batchSize=0, and it's a known issue that issuing a find with batchSize=0 against mongos in versions before 3.5.6 delays actually contacting the shards until data is requested through getMore (SERVER-27286).
Then, because the getMore command on mongos does not handle retrying on stale version errors (and the error is bubbled up as an error status rather than an exception, so it is not caught by the stale version retry loop in Strategy::clientCommandOp), the error is bubbled all the way back up to the client. This is why the PHP driver is seeing the error.
...
Until then, a fix for users could be to not issue finds with batchSize=0 (does the PHP driver automatically do this?).
The batchSize issue is described in more detail in this comment in SERVER-27286.
As for PHP, neither the driver nor libmongoc set batchSize on the find command by default. That said, the stack trace in the OP includes the community-developed mongo-php-adapter library, which implements the legacy ext-mongo driver API for the newer ext-mongodb driver. This may be supplying a default value based on the following code:
Since the $batchSize property defaults to 0 instead of null, I believe it's included in the options passed to MongoDB\Collection::find() in our library, which will include the option when the driver and libmongoc issue the find command. An immediate work-around may be to patch the default value to 0 until the adapter library can address this. That's likely easier than explicitly specifying a null batchSize through all of your ODM queries.
|
|
Ah, so the issue is that the find is being issued with a batchSize=0, and it's a known issue that issuing a find with batchSize=0 against mongos in versions before 3.5.6 delays actually contacting the shards until data is requested through getMore (SERVER-27286).
Then, because the getMore command on mongos does not handle retrying on stale version errors (and the error is bubbled up as an error status rather than an exception, so it is not caught by the stale version retry loop in Strategy::clientCommandOp), the error is bubbled all the way back up to the client. This is why the PHP driver is seeing the error.
I'm posting a walk through of steffen's logs in a developer-only comment below this, to keep the logs private.
I can think of a couple fixes:
- re-triage the backports for
SERVER-27286 from 'won't fix', since it still seems to be causing issues
- re-triage
SERVER-28943 to make the shard re-check the version after it refreshes (and backport it...)
- put a band-aid in for 3.4 (and maybe 3.2) to make mongos's getMore throw on stale version errors, so that the exception is caught by the retry loop in Strategy::clientCommandOp and the command is re-tried
kaloian.manassiev, david.storch?
Until then, a fix for users could be to not issue finds with batchSize=0 (does the PHP driver automatically do this?).
|
|
Thanks steffen, anonymous.user for the quick response, taking a look at these now.
|
|
I uploaded some logs.
Collection: dfp.lineItems
Timeline:
2017-04-25T06:48:24.990 moveChunk via router master-1
2017-04-25T06:51:07 query on dfp.lineItems via php driver on router app-0
->
RequirementException: MongoException: [dfp.lineItems] shard version not ok: version mismatch detected for dfp.lineItems ( ns : dfp.lineItems, received : 18|0||58a46d88be4b4925a7638e2f, wanted : 17|1||58a46d88be4b4925a7638e2f, send ) in /vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/ExceptionConverter.php (83) when fullfilling requirement [lineItems] in [rg\modules\adminads\actions\AdCampaignListItem]
|
|
|
Hi Steffen,
I've created a secure upload portal. Files uploaded to this portal are visible only to MongoDB employees and are routinely deleted after some time.
Thank you,
Thomas
|
|
Where can I upload the logs and keep them private?
|
|
So I can see that a shard returns the same stale version error in 3.4 by issuing a find from a stale mongos after moving the (only) chunk out of a shard, but mongos is supposed to (and seems to) retry up to 10 times after getting the error:
// stale mongos refreshes its chunks
|
[js_test:test] 2017-04-24T10:52:22.556-0400 s15513| 2017-04-24T10:52:22.556-0400 I SHARDING [conn1] Refreshing chunks for collection test.foo based on version 1|0||58fe11257b31e29c057ad03c
|
[js_test:test] 2017-04-24T10:52:22.563-0400 s15513| 2017-04-24T10:52:22.563-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c
|
|
// donor shard throws because its expected version is 0|0; it does a refresh just before sending the response back to mongos
|
[js_test:test] 2017-04-24T10:52:22.568-0400 d15511| 2017-04-24T10:52:22.568-0400 I SHARDING [conn13] Refreshing chunks for collection test.foo based on version 1|0||58fe11257b31e29c057ad03c
|
[js_test:test] 2017-04-24T10:52:22.576-0400 d15511| 2017-04-24T10:52:22.575-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c
|
[js_test:test] 2017-04-24T10:52:22.576-0400 d15511| 2017-04-24T10:52:22.576-0400 I SHARDING [conn13] Refreshing metadata for collection test.foo from collection version: 1|0||58fe11257b31e29c057ad03c, shard version: 0|0||58fe11257b31e29c057ad03c to collection version: 2|0||58fe11257b31e29c057ad03c, shard version: 2|0||58fe11257b31e29c057ad03c
|
|
// stale mongos receives "shard version not ok, the collection may have been dropped":
|
[js_test:test] 2017-04-24T10:52:22.577-0400 s15513| 2017-04-24T10:52:22.576-0400 D QUERY [conn1] Received error status for query query: { _id: 6.0 } sort: {} projection: {} on attempt 1 of 10: SendStaleConfig: [test.foo] shard version not ok: this shard no longer contains chunks for test.foo, the collection may have been dropped ( ns : test.foo, received : 2|0||58fe11257b31e29c057ad03c, wanted : 0|0||58fe11257b31e29c057ad03c, send )
|
|
// stale mongos refreshes again, finds the same collection version, and then succeeds in doing the find
|
[js_test:test] 2017-04-24T10:52:22.577-0400 s15513| 2017-04-24T10:52:22.577-0400 I SHARDING [conn1] Refreshing chunks for collection test.foo based on version 2|0||58fe11257b31e29c057ad03c
|
[js_test:test] 2017-04-24T10:52:22.584-0400 s15513| 2017-04-24T10:52:22.584-0400 I SHARDING [CatalogCacheLoader-0] Refresh for collection test.foo took 7 ms and found version 2|0||58fe11257b31e29c057ad03c
|
What I don't understand is why the mongos doesn't seem to be retrying the find internally in the reporter's case (in my repro, note how mongos logs "on attempt 1 of 10: SendStaleConfig" and then retries).
That line is logged at level 1 by mongos; steffen and crashdgc@gmail.com, would you be able to send logs from a repro using verbosity level 3 for both mongos and the shards? (Log level 3 will allow us to additionally see every network request being sent out from mongos).
|
|
And tested with 3.4.4 -> still a BIG issue.
|
|
Also happening with mongodb version 3.4.3 nad php mongodb 1.2.8.
|
|
1. we use default (primary) read preference.
2. Complete log here https://www.dropbox.com/s/7mq504n1f62dfrw/mongodb_logs.zip?dl=0
|
|
Hi crashdgc@gmail.com,
We're continuing to continuing to investigate. Would you please answer the same questions as above?
- Would you please clarify which read preference you are using for your find commands?
- Would you please provide the complete mongod log files of a primary in the cluster and an affected mongos?
This will help us determine which systems may be affected.
Thank you,
Thomas
|
|
we have same error on versions 3.4.2 and 3.4.3
Client error:
[database.comments] shard version not ok: this shard no longer contains chunks for database.comments, the collection may have been dropped ( ns : database.comments, received : 2|0||58dcc0d9ce84cfb999bbdace, wanted : 0|0||58dcc0d9ce84cfb999bbdace, send ) with code: 13388
|
|
From mongos.log
2017-03-30T08:28:24.067+0000 I SHARDING [conn42] autosplitted database.comments chunk: shard: rs1, lastmod: 1|0||58dcc0d9ce84cfb999bbdace, [{ post_id: MinKey }, { post_id: MaxKey }) into 3 parts (splitThreshold 921)
|
2017-03-30T08:28:24.067+0000 I SHARDING [conn42] ChunkManager loading chunks for database.comments sequenceNumber: 30 based on: 1|0||58dcc0d9ce84cfb999bbdace
|
2017-03-30T08:28:24.068+0000 I SHARDING [conn42] ChunkManager load took 0 ms and found version 1|3||58dcc0d9ce84cfb999bbdace
|
2017-03-30T08:28:24.172+0000 I SHARDING [conn42] ChunkManager loading chunks for database.comments sequenceNumber: 31 based on: 1|3||58dcc0d9ce84cfb999bbdace
|
2017-03-30T08:28:24.173+0000 I SHARDING [conn42] ChunkManager load took 0 ms and found version 2|1||58dcc0d9ce84cfb999bbdace
|
|
From shard-2/repl-1/mongod.log
2017-03-30T08:28:24.103+0000 I INDEX [migrateThread] build index done. scanned 0 total records. 0 secs
|
2017-03-30T08:28:24.104+0000 I SHARDING [migrateThread] Deleter starting delete for: database.comments from { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }, with opId: 2624
|
2017-03-30T08:28:24.105+0000 I SHARDING [migrateThread] rangeDeleter deleted 0 documents for database.comments from { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
|
2017-03-30T08:28:24.145+0000 I SHARDING [migrateThread] Waiting for replication to catch up before entering critical section
|
2017-03-30T08:28:24.146+0000 I SHARDING [migrateThread] migrate commit succeeded flushing to secondaries for 'database.comments' { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
|
2017-03-30T08:28:24.156+0000 I SHARDING [migrateThread] migrate commit succeeded flushing to secondaries for 'database.comments' { post_id: MinKey } -> { post_id: ObjectId('58dcc143ffc154015839827e') }
|
2017-03-30T08:28:24.156+0000 I SHARDING [migrateThread] about to log metadata event into changelog: { _id: "e3a45e0f8486-2017-03-30T08:28:24.156+0000-58dcc1a808b7b342b963e741", server: "e3a45e0f8486", clientAddr: "", time: new Date(1490862504156), what: "moveChunk.to", ns: "database.comments", details: { min: { post_id: MinKey }, max: { post_id: ObjectId('58dcc143ffc154015839827e') }, step 1 of 6: 14, step 2 of 6: 39, step 3 of 6: 1, step 4 of 6: 0, step 5 of 6: 11, step 6 of 6: 0, note: "success" } }
|
2017-03-30T08:28:24.249+0000 I SHARDING [conn41] MetadataLoader loading chunks for database.comments based on: 1|3||58dcc0d9ce84cfb999bbdace
|
2017-03-30T08:28:24.250+0000 I SHARDING [conn41] Refreshing metadata for collection database.comments from collection version: 1|3||58dcc0d9ce84cfb999bbdace, shard version: 0|0||58dcc0d9ce84cfb999bbdace to collection version: 2|1||58dcc0d9ce84cfb999bbdace, shard version: 2|0||58dcc0d9ce84cfb999bbdace
|
2017-03-30T08:28:24.250+0000 I SHARDING [conn41] MetadataLoader took 1 ms and found version 2|1||58dcc0d9ce84cfb999bbdace
|
|
|
|
We started a chunk balance at
2017-02-22T11:03:38
for collection "dfp.lineItems" on router app-0.
sh.moveChunk("dfp.lineItems", { "o" : { MinKey : 1 }, "_id" : { MinKey : 1 } }, 'shard0001')
|
Php application showed Exceptions now on both app routers.
ReadPreference is PrimaryPreferred.
Primarys:
mongs-4 is sending
mongs-3 is receiving
|
|
Hi steffen,
Thanks for reporting this issue, we're investigating and have a couple questions to help us better understand what is going on here.
- Would you please clarify which read preference you are using for your find commands?
- Would you please provide the complete mongod log files of a primary in the cluster and an affected mongos?
Thank you for your help,
Thomas
|
|
We did another test to show you, that it's not related to a collection just being sharded.
Setup: Our PHP applciation runs on 2 nodes (app-0 and app-1). Each with a mongo router.
Collection is sharded no errors since routers are up2date.
On app-1 we connect to the router and move the chunk of this collection via:
sh.moveChunk("data.items", { "o" : { MinKey : 1 }, "_id" : { MinKey : 1 } }, 'shard0002')
|
This is succesfull.
Now we call my php application (web page via php7-fpm) to use app-0 or app-1.
Result is, that app-1 has no issues but app-0, which didn't do the chunk move, shows again exception in PHP application.
[data.items] shard version not ok: this shard no longer contains chunks for data.items, the collection may have been dropped ( ns : data.items, received : 1|0||58a46d88be4b4925a7638e2f, wanted : 0|0||58a46d88be4b4925a7638e2f, send ) /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/ExceptionConverter.php (83) Alcaeus\MongoDbAdapter\ExceptionConverter::toLegacy
|
|
Stacktrace:
|
[snip]
|
|
[23]
|
File: /path/to/code/src/model/dfp/connectors/mdb/MdbLineItemConnector.php in line 68
|
Method: rg\ODM\MongoDB\Cursor->toArray
|
|
[24]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/rg/ODM/MongoDB/Cursor.php in line 277
|
Method: Doctrine\MongoDB\Cursor->toArray
|
Parameter: [true]
|
|
[25]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 629
|
Method: Doctrine\MongoDB\Cursor->retry
|
Parameter: [Closure, true]
|
|
[26]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
|
Method: Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
|
|
[27]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 628
|
Parameter: [rg\core\base\objectManagers\mongodb\LoggingCursor]
|
|
[28]
|
Method: rg\core\base\objectManagers\mongodb\LoggingCursor->rewind
|
|
[29]
|
File: /path/to/code/src/core/base/objectManagers/mongodb/LoggingCursor.php in line 253
|
Method: Doctrine\MongoDB\Cursor->rewind
|
|
[30]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 490
|
Method: Doctrine\MongoDB\Cursor->retry
|
Parameter: [Closure, false]
|
|
[31]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 666
|
Method: Doctrine\MongoDB\Cursor->Doctrine\MongoDB\{closure}
|
|
[32]
|
File: /path/to/code/vendor/composer/rg/mongodb-odm-light/lib/Doctrine/MongoDB/Cursor.php in line 489
|
Method: Alcaeus\MongoDbAdapter\AbstractCursor->rewind
|
|
[33]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 190
|
Method: Alcaeus\MongoDbAdapter\AbstractCursor->ensureIterator
|
|
[34]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Alcaeus/MongoDbAdapter/AbstractCursor.php in line 297
|
Method: MongoCursor->ensureCursor
|
|
[35]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 443
|
Method: MongoCursor->doQuery
|
|
[36]
|
File: /path/to/code/vendor/composer/alcaeus/mongo-php-adapter/lib/Mongo/MongoCursor.php in line 166
|
Method: MongoDB\Collection->find
|
Parameter: [MongoDB\Model\BSONDocument: ['o' => MongoDB\Model\BSONDocument: ['$in' => ['0' => 123456, '1' => 275383959000, '2' => 114204279, '3' => 233433999, '4' => 233014719, '5' => 237809079, '6' => 247189479, '7' => 251772159, '8' => 260437839, '9' => 275383959, '10' => 285140199, [10more ...]]], '$comment' => 'cId 4a05305c7e3b17a7cccd37f0520d3722,vId 165...'], ['batchSize' => 0, 'modifiers' => [], 'projection' => [], 'readPreference' => MongoDB\Driver\ReadPreference, 'readConcern' => MongoDB\Driver\ReadConcern, 'typeMap' => ['array' => 'MongoDB\Model\BSONArray', 'document' => 'MongoDB\Model\BSONDocument', 'root' => 'MongoDB\Model\BSONDocument']]]
|
|
[37]
|
File: /path/to/code/vendor/composer/mongodb/mongodb/src/Collection.php in line 525
|
Method: MongoDB\Operation\Find->execute
|
Parameter: [MongoDB\Driver\Server: [MongoDB\Driver\Server Object
|
(
|
[host] => localhost
|
[port] => 27017
|
[type] => 2
|
[is_primary] =>
|
[is_secondary] =>
|
[is_arbiter] =>
|
[is_hidden] =>
|
[is_passive] =>
|
[last_is_master] => Array
|
(
|
[ismaster] => 1
|
[msg] => isdbgrid
|
[maxBsonObjectSize] => 16777216
|
[maxMessageSizeBytes] => 48000000
|
[maxWriteBatchSize] => 1000
|
[localTime] => MongoDB\BSON\UTCDateTime Object
|
(
|
[milliseconds] => 1487178165007
|
)
|
|
[maxWireVersion] => 5
|
[minWireVersion] => 0
|
[ok] => 1
|
)
|
|
[round_trip_time] => 0
|
)
|
]]
|
|
[38]
|
File: /path/to/code/vendor/php/mongodb/Find.php in line 206
|
Method: MongoDB\Driver\Server->executeQuery
|
Parameter: ['data.items', MongoDB\Driver\Query, MongoDB\Driver\ReadPreference]
|
|
Generated at Thu Feb 08 04:16:54 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.