Blog | dinosaur blog

redis

September 25, 2021 · 3 min read

1 类型 string
list set zset hash

2 对应的命令

set 命令 edis/src/t_string.c
string 的过期不是实时的

list lpush lpop / 有ziplist 和双向链表组成

hash 有两个hashtable ，一个是内容一个谁拿来扩容

set 谁由intset 和 hashtable组成

zset ziplist+ skiplist

3 aof/rdb

aof 谁append only file 都是可读的文本 rdb谁整个盘快照

4 redis 淘汰

noeviction:如果缓存数据超过了maxmemory限定值，并且客户端正在执行的命令(大部分的写入指令，但DEL和几个指令例外)会导致内存分配，则向客户端返回错误响应 allkeys-lru: 对所有的键都采取LRU淘汰 volatile-lru: 仅对设置了过期时间的键采取LRU淘汰 allkeys-random: 随机回收所有的键 volatile-random: 随机回收设置过期时间的键 volatile-ttl: 仅淘汰设置了过期时间的键---淘汰生存时间TTL(Time To Live)更小的键

5 HA

Redis Cluster master-replica model

In order to remain available when a subset of master nodes are failing or are not able to communicate with the majority of nodes, Redis Cluster uses a master-replica model where every hash slot has from 1 (the master itself) to N replicas (N-1 additional replica nodes).

In our example cluster with nodes A, B, C, if node B fails the cluster is not able to continue, since we no longer have a way to serve hash slots in the range 5501-11000.

However when the cluster is created (or at a later time) we add a replica node to every master, so that the final cluster is composed of A, B, C that are master nodes, and A1, B1, C1 that are replica nodes. This way, the system is able to continue if node B fails.

Node B1 replicates B, and B fails, the cluster will promote node B1 as the new master and will continue to operate correctly.

However, note that if nodes B and B1 fail at the same time, Redis Cluster is not able to continue to operate.

failover 错误转移

当master 失去连接后，slave会向master 发起一个paxos 选票

分片

分片会路由到不同胡slot，运算方式要crc16（key）% 16384

每个分片会有特定slot

一致性

不是强一致性，

Redis Cluster is not able to guarantee strong consistency. In practical terms this means that under certain conditions it is possible that Redis Cluster will lose writes that were acknowledged by the system to the client.

The first reason why Redis Cluster can lose writes is because it uses asynchronous replication. This means that during writes the following happens:

Your client writes to the master B. The master B replies OK to your client. The master B propagates the write to its replicas B1, B2 and B3.

因为是异步的

缓存穿透雪崩

穿透是指通过redis 雪崩就是指同时失效

限流

https://segmentfault.com/a/1190000040570911

Welcome

August 26, 2021 · One min read

Sébastien Lorber

Docusaurus maintainer

Yangshun Tay

Front End Engineer @ Facebook

Docusaurus blogging features are powered by the blog plugin.

Simply add Markdown files (or folders) to the blog directory.

Regular blog authors can be added to authors.yml.

The blog post date can be extracted from filenames, such as:

2019-05-30-welcome.md
2019-05-30-welcome/index.md

A blog post folder can be convenient to co-locate blog post images:

The blog supports tags as well!

And if you don't want a blog: just delete this directory, and use blog: false in your Docusaurus config.

redis 主从切换和高可用

August 9, 2021 · One min read

MDX Blog Post

August 1, 2021 · One min read

Sébastien Lorber

Docusaurus maintainer

Blog posts support Docusaurus Markdown features, such as MDX.

tip

Use the power of React to create interactive blog posts.

<button onClick={() => alert('button clicked!')}>Click me!</button>

mysql 5.7 in 的优化引起的bug

July 29, 2021 · 3 min read

起因

有个1700w的表需要初始化 , 然后我们需要分批取id范围是[1 , 1000) , [1000 , 2000)的值

问题

很简单的sql

update  test set    a.value=1 where id in ( 1 , 2 , 7 , 9.... 1000);
update  test set    a.value=1 where id in ( 1001 , 1002 , 1005 , ... 2000);

这里的id大概有100个左右 ,id是单调递增,基本连续

测试环境很正常,非常快 , 通过这个sql , 我们可以一秒update 1w以上的行

但是生产环境这个update特别特别慢,update 1000 行大概需要 50s以上

排查

定位经过很多尝试,
定位到是update这个sql特别慢,而且是但是测试环境非常快,生产环境非常慢

尝试explain

explain 
update  test as a set    a.value=1 where id in ( 1 , 2 , 7 , 9....);

生产环境下是这样:

Using where; Using temporary

但是测试环境是:

Using where

开始搜索,找到了类似的原因: https://bugs.mysql.com/bug.php?id=80424 对比了一下版本: 生产环境:5.7.9-log 测试环境:5.7.22-log

确定binlog的记录形式:

SELECT @@binlog_row_image

结果是

FULL

这个bug被5.7.15以上修复,所以测试环境没有问题,生产环境有问题

解决

因为生产版本的mysql几乎没有升级的可能,这个批量的刷数据如果10条/s估计要刷一个星期,所以我们尝试了很多写法避免这个优化,最后使用了这个写法避免生产版本的mysql的bug 不使用in 而是使用join 防止这个优化器的bug

DESC
UPDATE `test` a JOIN (
SELECT id FROM test t   WHERE  `id` IN (516,517,518,519,520,521,522,523,524,525,526,527,528,529,530,531,533,532)
) t ON a.id = t.id
SET a.isvisible = -1;

优化后不用temp了

"id"	"select_type"	"table"	"partitions"	"type"	   "possible_keys"	"key"	"key_len"	"ref"	"rows"	"filtered"	"Extra"
"1"	    "UPDATE"	     "a"	\N	            "range"	    "PRIMARY"	    "PRIMARY"	"4"	     \N	    "104"	"100.00"	"Using where"
"1"	    "SIMPLE"	     "b"	\N	            "eq_ref"	"PRIMARY"	   "PRIMARY"	"4"	   "a.id"	"1"	    "100.00"	"Using index"

事后扒代码

通过https://bugs.mysql.com/bug.php?id=80424 提供的patch大概定位到原因

为什么会使用temp表?

第六个参数是判断是否需要使用temp的 ,也就是 !using_filesort && (used_key_is_modified || order)

    Modification_plan plan(thd, MT_UPDATE, &qep_tab,
                           used_index, limit,
                           (!using_filesort && (used_key_is_modified || order)),
                           using_filesort, used_key_is_modified, rows);

查看Modification_plan这个类的定义:

  Modification_plan(THD *thd_arg,
                    enum_mod_type mt, QEP_TAB *qep_tab,
                    uint key_arg, ha_rows limit_arg, bool need_tmp_table_arg,
                    bool need_sort_arg, bool used_key_is_modified_arg,
                    ha_rows rows);

在这个问题中是 used_key_is_modified = true, 所以会产生temp表

tcp_nodelay

July 15, 2021 · 8 min read

tcp_nodealy

 The solution to the small-packet problem
 解决小包问题的方法

Clearly an adaptive approach is desirable.  One  would  expect  a
proposal  for  an  adaptive  inter-packet time limit based on the
round-trip delay observed by TCP.  While such a  mechanism  could
certainly  be  implemented,  it  is  unnecessary.   A  simple and
elegant solution has been discovered.

The solution is to inhibit the sending of new TCP  segments  when
new  outgoing  data  arrives  from  the  user  if  any previously
transmitted data on the connection remains unacknowledged.   This
inhibition  is  to be unconditional; no timers, tests for size of
data received, or other conditions are required.   Implementation
typically requires one or two lines inside a TCP program.
解决的方式是如果之前发送的数据没有被ack,阻止发送新的tcp段.这个抑制条件是不需要前置的条件的:不需要定时器,不需要探测包是否被接收,以及其他条件.实现上只需要添加一两行代码在tcp程序里面


At first glance, this solution seems to imply drastic changes  in
the  behavior of TCP.  This is not so.  It all works out right in
the end.  Let us see why this is so.
乍看起来,这会很大地改变tcp的行为.但是实际上并不是这样,这从头到尾都没有太大变化.让我们看看为什么是这样.

When a user process writes to a TCP connection, TCP receives some
data.   It  may  hold  that data for future sending or may send a
packet immediately.  If it refrains from  sending  now,  it  will
typically send the data later when an incoming packet arrives and
changes the state of the system.  The state changes in one of two
ways;  the incoming packet acknowledges old data the distant host
has received, or announces the availability of  buffer  space  in
the  distant  host  for  new  data.  (This last is referred to as
"updating the window").    Each time data arrives  on  a  connec-
tion,  TCP must reexamine its current state and perhaps send some
packets out.  Thus, when we omit sending data on arrival from the
user,  we  are  simply  deferring its transmission until the next
message arrives from the distant host.   A  message  must  always
arrive soon unless the connection was previously idle or communi-
cations with the other end have been lost.  In  the  first  case,
the  idle  connection,  our  scheme will result in a packet being
sent whenever the user writes to the TCP connection.  Thus we  do
not  deadlock  in  the idle condition.  In the second case, where
当一个用户写消息到tcp连接,Tcp协议栈会受到这些信息.tcp协议栈会保持这些内容或者立马发送这些内容.



RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

the distant host has failed, sending more data is futile  anyway.
Note  that we have done nothing to inhibit normal TCP retransmis-
sion logic, so lost messages are not a problem.

Examination of the behavior of this scheme under  various  condi-
tions  demonstrates  that the scheme does work in all cases.  The
first case to examine is the one we wanted to solve, that of  the
character-oriented  Telnet  connection.   Let us suppose that the
user is sending TCP a new character every  200ms,  and  that  the
connection  is  via  an Ethernet with a round-trip time including
software processing of 50ms.  Without any  mechanism  to  prevent
small-packet congestion, one packet will be sent for each charac-
ter, and response will be optimal.  Overhead will be  4000%,  but
this  is  acceptable  on  an Ethernet.  The classic timer scheme,
with a limit of 2 packets per second, will  cause  two  or  three
characters to be sent per packet.  Response will thus be degraded
even though on a high-bandwidth  Ethernet  this  is  unnecessary.
Overhead  will  drop  to  1500%, but on an Ethernet this is a bad
tradeoff.  With our scheme, every character the user  types  will
find  TCP with an idle connection, and the character will be sent
at once, just as in the no-control case.  The user  will  see  no
visible  delay.   Thus,  our  scheme  performs as well as the no-
control scheme and provides better responsiveness than the  timer
scheme.

The second case to examine is the same Telnet  test  but  over  a
long-haul  link  with  a  5-second  round trip time.  Without any
mechanism to prevent  small-packet  congestion,  25  new  packets
would be sent in 5 seconds.* Overhead here is  4000%.   With  the
classic timer scheme, and the same limit of 2 packets per second,
there would still be 10 packets outstanding and  contributing  to
congestion.  Round-trip time will not be improved by sending many
packets, of course; in general it will be worse since the packets
will  contend  for line time.  Overhead now drops to 1500%.  With
our scheme, however, the first character from the user would find
an  idle  TCP connection and would be sent immediately.  The next
24 characters, arriving from the user at 200ms  intervals,  would
be  held  pending  a  message from the distant host.  When an ACK
arrived for the first packet at the end of 5  seconds,  a  single
packet  with  the 24 queued characters would be sent.  Our scheme
thus results in an overhead reduction to 320% with no penalty  in
response  time.   Response time will usually be improved with our
scheme because packet overhead is reduced, here by  a  factor  of
4.7 over the classic timer scheme.  Congestion will be reduced by
this factor and round-trip delay will decrease sharply.  For this
________
  * This problem is not seen in the pure ARPANET case because the
    IMPs will block the host when the count of packets
    outstanding becomes excessive, but in the case where a pure
    datagram local net (such as an Ethernet) or a pure datagram
    gateway (such as an ARPANET / MILNET gateway) is involved, it
    is possible to have large numbers of tiny packets
    outstanding.



RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

case, our scheme has a striking  advantage  over  either  of  the
other approaches.

We use our scheme for all TCP connections, not just  Telnet  con-
nections.   Let us see what happens for a file transfer data con-
nection using our technique. The two extreme cases will again  be
considered.

As before, we first consider the Ethernet case.  The user is  now
writing data to TCP in 512 byte blocks as fast as TCP will accept
them.  The user's first write to TCP will start things going; our
first  datagram  will  be  512+40  bytes  or 552 bytes long.  The
user's second write to TCP will not cause a send but  will  cause
the  block  to  be buffered.  Assume that the user fills up TCP's
outgoing buffer area before the first ACK comes back.  Then  when
the  ACK  comes in, all queued data up to the window size will be
sent.  From then on, the window will be kept full,  as  each  ACK
initiates  a  sending  cycle  and queued data is sent out.  Thus,
after a one round-trip time initial period when only one block is
sent,  our  scheme  settles down into a maximum-throughput condi-
tion.  The delay in startup is only 50ms on the Ethernet, so  the
startup  transient  is  insignificant.  All three schemes provide
equivalent performance for this case.

Finally, let us look at a file transfer over the  5-second  round
trip  time connection.  Again, only one packet will be sent until
the first ACK comes back; the window will then be filled and kept
full.   Since the round-trip time is 5 seconds, only 512 bytes of
data are transmitted in the first 5 seconds.  Assuming a 2K  win-
dow,  once  the first ACK comes in, 2K of data will be sent and a
steady rate of 2K per 5 seconds will  be  maintained  thereafter.
Only  for  this  case is our scheme inferior to the timer scheme,
and the difference is only in the startup transient; steady-state
throughput  is  identical.  The naive scheme and the timer scheme
would both take 250 seconds to transmit a 100K  byte  file  under
the  above  conditions  and  our scheme would take 254 seconds, a
difference of 1.6%.

Thus, for all cases examined, our scheme provides at least 98% of
the  performance  of  both other schemes, and provides a dramatic
improvement in Telnet performance over paths with long round trip
times.   We  use  our  scheme  in  the  Ford  Aerospace  Software
Engineering Network, and are able to run screen editors over Eth-
ernet and talk to distant TOPS-20 hosts with improved performance
in both cases.

skiplist

June 22, 2021 · 6 min read

跳表 skiplist

Binary trees can be used for representing abstract data types such as dictionaries and ordered lists. They work well when the elements are inserted in a random order. 二叉树可以使用来表达一个词典或者一个有序列表.当二叉树的元素插入是随机顺序的时候,他可以工作很好

Some sequences of operations, such as inserting the elements in order, produce degenerate data structures that perform very poo.rly. 但是一些特定的顺序,举个例子,如果插入的数据本身已经是有序的,那么效果则会很差 If it were possible to randomly permute the list of items to be inserted, trees would work well with high probability for any input sequence. 如果可以产生随机的数据去插入,那么树会对输入的性能变得非常好 In most cases queries must be answered online, so randomly permuting the input is impractical. Balanced tree algorithms rearrange the tree as operations are performed to maintain certain balance conditions and assure good performance. 在大部分的情况必须实时查询,所以随机交换输入是不可能的,平衡树需要重排来保证某些平衡的条件和确保比较好的性能 Skip lists are a probabilistic alternative to balanced trees. 跳表相对于平衡树来说是另外一个选择 Skip lists are balanced by consulting a random number generator. 跳表的平衡是通过获取一个随机数 Although skip lists have bad worstcase performance, no input sequence consistently produces the worst-case performance (much like quicksort when the pivot element is chosen randomly). 虽然跳表也有bad case(举个例子每次随机的高度都一样) , 但是没有一个输入序列可以把这个bad case稳定的生成(因为是随机产生所以不会一直产生最坏情况) It is very unlikely a skip list data structure will be significantly unbalanced (e.g., for a dictionary of more than 250 elements, the chance that a search will take more than three-times the expeci.ed time is less than one in a million). Skip lists have balance properties similar to that of search trees built by random insertions, yet do not require insertions to be random. 这不太可能跳表变得非常显著地不平衡,跳表的平衡性质和一个随机插入的搜索树相类似,但是不需要随机去插入 It is easier to balance a data structure probabilistitally than to explicitly maintain the balance. 通过概率去平衡一个暑假结构比显式保持它的平衡要简单 For many applications, skip lists are a more natural representation than trees, and they lead to simpler algorithms. 对于很多应用,相对于树来说跳表会更加自然. The simplicity of skip list algorithms makes them easier to implement and provides significant constant factor speed improvements over balanced tree and self-adjusting tree algorithms. 跳表的简易型可以实现和提供一个显著的常量因子去比平衡树和自适应树更好 Skip lists are also very space efficient. 跳表的空间利用率很高 They can easily be configured to require an average of 1% pointers per element (or even less) and do not require balance or priority information to be stored with each node. 他们可以需要平均百分之1的指针和不需要平衡或者权重信息取存储每个节点

SKIP LISTS 跳表 We might need to examine every node of the list when searching a linked list (Figure la). 当我们使用链表这个结构来存储数据,如果我们要搜索某个节点,我们需要顺序遍历每个节点. If the list is stored in sorted order and every other node of the list also has a pointer to the node two ahead of it in the list (Figure lb), we have to examine no more than [n/21 +1 nodes (where n is the length of the list). 如果这个list是 Also giving every fourth node a pointer four ahead (Figure lc) requires that no more than rn/41 + 2 nodes be examined. If every (27th node has a pointer 2’ nodes ahead (Figure Id), the number of nodes that must be examined can be reduced to rlog,nl while only doubling the number of pointers. This data structure could be used for fast searching, but insertion and deletion would be impractical. A node that has k forward pointers is called a level k node. If every (2’)th node has a pointer 2’ nodes ahead, then levels of nodes are distributed in a simple pattern: 50 percent are level 1, 25 percent are level 2, 12.5 percent are level 3 and so on. What would happen if the levels of nodes were chosen randomly, but in the same proportions (e.g., as in Figure le)? A node’s ith forward pointer, instead of pointing 2’-’ nodes ahead, points to the next node of level i or higher. Insertions or deletions would require only local modifications; the level of a node, chosen randomly when the node is inserted, need never change. Some arrangements of levels would give poor execution times, but we will see that such arrangements are rare. Because these data structures are linked lists with extra pointers that s

mongoinsert

June 4, 2021 · 8 min read

mongo 的wiredtiger 是怎么组织kv结构的呢? 我现在还是没有弄懂

堆栈:

Thread 41 "conn1" hit Breakpoint 5, __wt_btcur_insert (cbt=cbt@entry=0x555560bd2000) at src/third_party/wiredtiger/src/btree/bt_cursor.c:763
763	{
(gdb) bt
#0  __wt_btcur_insert (cbt=cbt@entry=0x555560bd2000) at src/third_party/wiredtiger/src/btree/bt_cursor.c:763
#1  0x0000555556d6149a in __curfile_insert (cursor=0x555560bd2000) at src/third_party/wiredtiger/src/cursor/cur_file.c:266
#2  0x0000555556cd3ef4 in mongo::wiredTigerCursorInsert (opCtx=opCtx@entry=0x555560af8180, cursor=cursor@entry=0x555560bd2000)
    at src/mongo/db/storage/wiredtiger/wiredtiger_cursor_helpers.cpp:39
#3  0x0000555556d131bd in mongo::WiredTigerRecordStore::_insertRecords (this=0x55555bfddc00, opCtx=0x555560af8180, records=<optimized out>, timestamps=0x55555c01a478, nRecords=1)
    at src/mongo/db/storage/wiredtiger/wiredtiger_record_store.cpp:1319
#4  0x0000555556d13ae7 in mongo::WiredTigerRecordStore::insertRecords (this=<optimized out>, opCtx=<optimized out>, records=<optimized out>, timestamps=...)
    at /usr/include/c++/9/bits/stl_vector.h:915
#5  0x0000555557bf9972 in mongo::CollectionImpl::_insertDocuments (this=0x55555bfe1410, opCtx=0x555560af8180, begin=..., end=..., opDebug=0x555560b40a50, fromMigrate=false)
    at /usr/include/c++/9/bits/unique_ptr.h:360
#6  0x0000555557bfa333 in mongo::CollectionImpl::insertDocuments (this=this@entry=0x55555bfe1410, opCtx=opCtx@entry=0x555560af8180, begin=begin@entry=
        {stmtIds = std::vector of length 1, capacity 1 = {-1}, oplogSlot = {static kTermFieldName = {_data = 0x555559e64ab2 "t", _size = 1}, static kTimestampFieldName = {_data = 0x555559e5c074 "ts", _size = 2}, static kUninitializedTerm = -1, static kInitialTerm = 0, _timestamp = {static kAllowUnstableCheckpointsSentinel = {static kAllowUnstableCheckpointsSentinel = <same as static member of an already seen type>, i = 1, secs = 0}, i = 0, secs = 0}, _term = -1}, doc = {static kMinBSONLength = 5 '\005', static kEmptyObjectPrototype = "\005\000\000\000", _objdata = 0x55556036f92b "-", _ownedBuffer = {_buffer = {_holder = {px = 0x55556036f900}, static kHolderSize = 8}}}}, end=end@entry=
    {stmtIds = std::vector of length -28, capacity 23456275625363 = {<error reading variable>, opDebug=0x555560b40a50, fromMigrate=false)
    at src/mongo/db/catalog/collection_impl.cpp:663
#7  0x0000555557a0a1ae in mongo::write_ops_exec::(anonymous namespace)::insertDocuments (opCtx=0x555560af8180, collection=..., begin=..., end=
    {stmtIds = std::vector of length -28, capacity 23456275625363 = {<error reading variable>, fromMigrate=<optimized out>) at /usr/include/c++/9/bits/stl_iterator.h:871
#8  0x0000555557a0a631 in mongo::write_ops_exec::(anonymous namespace)::<lambda()>::operator()(void) const (__closure=0x7fffe5962a30) at src/mongo/db/catalog_raii.h:151
#9  0x0000555557a0ac1b in mongo::writeConflictRetry<mongo::write_ops_exec::(anonymous namespace)::insertBatchAndHandleErrors(mongo::OperationContext*, const mongo::write_ops::InsertCommandRequest&, std::vector<mongo::InsertStatement>&, mongo::write_ops_exec::(anonymous namespace)::LastOpFixer*, mongo::write_ops_exec::WriteResult*, mongo::OperationSource)::<lambda()> > (f=..., ns=..., opStr=..., opCtx=0x555560af8180) at /usr/include/c++/9/bits/stl_iterator.h:806
#10 mongo::write_ops_exec::(anonymous namespace)::insertBatchAndHandleErrors (source=<optimized out>, out=<optimized out>, lastOpFixer=<optimized out>, 
    batch=std::vector of length 1, capacity 1 = {...}, wholeOp=..., opCtx=<optimized out>) at src/mongo/db/ops/write_ops_exec.cpp:502
#11 mongo::write_ops_exec::performInserts (opCtx=<optimized out>, opCtx@entry=0x555560af8180, wholeOp=..., source=@0x7fffe5962e00: mongo::kStandard)
    at src/mongo/db/ops/write_ops_exec.cpp:655
#12 0x000055555791d28e in mongo::(anonymous namespace)::CmdInsert::Invocation::typedRun (this=0x555560ba0000, opCtx=0x555560af8180) at src/mongo/db/commands.h:1173
#13 0x000055555791e8a0 in mongo::TypedCommand<mongo::(anonymous namespace)::CmdInsert>::InvocationBase::_callTypedRun (opCtx=<optimized out>, this=<optimized out>)
    at src/mongo/db/commands.h:1255
#14 mongo::TypedCommand<mongo::(anonymous namespace)::CmdInsert>::InvocationBase::_runImpl (reply=0x555561392000, opCtx=<optimized out>, this=<optimized out>)
    at src/mongo/db/commands.h:1256
#15 mongo::TypedCommand<mongo::(anonymous namespace)::CmdInsert>::InvocationBase::run (this=<optimized out>, opCtx=<optimized out>, reply=0x555561392000)
    at src/mongo/db/commands.h:1261
#16 0x0000555558791662 in mongo::CommandHelpers::runCommandInvocation (opCtx=0x555560af8180, request=..., invocation=0x555560ba0000, response=0x555561392000)
    at src/mongo/db/commands.cpp:200
#17 0x0000555558797d73 in mongo::CommandHelpers::<lambda()>::operator() (__closure=0x7fffe5963180) at src/mongo/db/commands.cpp:184
#18 mongo::makeReadyFutureWith<mongo::CommandHelpers::runCommandInvocation(std::shared_ptr<mongo::RequestExecutionContext>, std::shared_ptr<mongo::CommandInvocation>, mongo::transport::ServiceExecutor::ThreadingModel)::<lambda()> > (func=...) at src/mongo/util/future.h:1208
#19 mongo::CommandHelpers::runCommandInvocation (rec=std::shared_ptr<class mongo::RequestExecutionContext> (use count 11, weak count 0) = {...}, 
    invocation=std::shared_ptr<class mongo::CommandInvocation> (use count 3, weak count 0) = {...}, threadingModel=<optimized out>) at src/mongo/db/commands.cpp:185
#20 0x0000555556c48367 in mongo::(anonymous namespace)::runCommandInvocation (rec=std::shared_ptr<class mongo::RequestExecutionContext> (empty) = {...}, 
    invocation=std::shared_ptr<class mongo::CommandInvocation> (empty) = {...}) at /usr/include/c++/9/bits/shared_ptr_base.h:756
--Type <RET> for more, q to quit, c to continue without paging--
#21 0x0000555556c5c389 in mongo::(anonymous namespace)::InvokeCommand::<lambda()>::operator() (__closure=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:756
#22 mongo::makeReadyFutureWith<mongo::(anonymous namespace)::InvokeCommand::run()::<lambda()> > (func=...) at src/mongo/util/future.h:1211
#23 mongo::(anonymous namespace)::InvokeCommand::run (this=0x55555c01a4a0) at src/mongo/db/service_entry_point_common.cpp:842
#24 mongo::(anonymous namespace)::RunCommandImpl::<lambda(auto:78*)>::operator()<mongo::(anonymous namespace)::InvokeCommand> (__closure=<optimized out>, path=0x55555c01a4a0)
    at src/mongo/db/service_entry_point_common.cpp:1188
#25 mongo::future_util::AsyncState<mongo::(anonymous namespace)::InvokeCommand>::<lambda()>::operator() (this=<optimized out>, this=<optimized out>)
    at src/mongo/util/future_util.h:742
#26 mongo::makeReadyFutureWith<mongo::future_util::AsyncState<State>::thenWithState(Launcher&&) && [with Launcher = mongo::(anonymous namespace)::RunCommandImpl::_runCommand()::<lambda(auto:78*)>; State = mongo::(anonymous namespace)::InvokeCommand]::<lambda()> > (func=...) at src/mongo/util/future.h:1211
#27 mongo::future_util::AsyncState<mongo::(anonymous namespace)::InvokeCommand>::thenWithState<mongo::(anonymous namespace)::RunCommandImpl::_runCommand()::<lambda(auto:78*)> > (
    launcher=..., this=<optimized out>) at src/mongo/util/future_util.h:747
#28 mongo::(anonymous namespace)::RunCommandImpl::_runCommand (this=<optimized out>) at src/mongo/db/service_entry_point_common.cpp:1188
#29 0x0000555556c5cc32 in mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern::_runCommandWithFailPoint (this=0x555560ba00e0)
    at src/mongo/db/service_entry_point_common.cpp:1299
#30 0x0000555556c5d1c3 in mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern::_runImpl (this=0x555560ba00e0) at src/mongo/db/service_entry_point_common.cpp:1219
#31 0x0000555556c4b9ad in mongo::(anonymous namespace)::RunCommandImpl::<lambda()>::operator() (__closure=<optimized out>) at src/mongo/db/service_entry_point_common.cpp:730
#32 mongo::makeReadyFutureWith<mongo::(anonymous namespace)::RunCommandImpl::run()::<lambda()> > (func=...) at src/mongo/util/future.h:1211
#33 mongo::(anonymous namespace)::RunCommandImpl::run (this=0x555560ba00e0) at src/mongo/db/service_entry_point_common.cpp:728
#34 0x0000555556c4f5b2 in mongo::(anonymous namespace)::ExecCommandDatabase::<lambda()>::<lambda(auto:79*)>::operator()<mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern> (__closure=<optimized out>, runner=0x555560ba00e0) at src/mongo/db/service_entry_point_common.cpp:1651
#35 mongo::future_util::AsyncState<mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern>::<lambda()>::operator() (this=<optimized out>, this=<optimized out>)
    at src/mongo/util/future_util.h:742
#36 mongo::makeReadyFutureWith<mongo::future_util::AsyncState<State>::thenWithState(Launcher&&) && [with Launcher = mongo::(anonymous namespace)::ExecCommandDatabase::_commandExec()::<lambda()>::<lambda(auto:79*)>; State = mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern]::<lambda()> > (func=...) at src/mongo/util/future.h:1211
#37 mongo::future_util::AsyncState<mongo::(anonymous namespace)::RunCommandAndWaitForWriteConcern>::thenWithState<mongo::(anonymous namespace)::ExecCommandDatabase::_commandExec()::<lambda()>::<lambda(auto:79*)> > (launcher=..., this=<optimized out>) at src/mongo/util/future_util.h:747
#38 mongo::(anonymous namespace)::ExecCommandDatabase::<lambda()>::operator() (__closure=<synthetic pointer>) at src/mongo/db/service_entry_point_common.cpp:1651
#39 mongo::(anonymous namespace)::ExecCommandDatabase::_commandExec (this=0x555560b57800) at src/mongo/db/service_entry_point_common.cpp:1658
#40 0x0000555556c58516 in mongo::(anonymous namespace)::ExecCommandDatabase::<lambda()>::operator() (__closure=<optimized out>) at src/mongo/db/service_entry_point_common.cpp:625
#41 mongo::makeReadyFutureWith<mongo::(anonymous namespace)::ExecCommandDatabase::run()::<lambda()> > (func=...) at src/mongo/util/future.h:1211
#42 mongo::(anonymous namespace)::ExecCommandDatabase::run (this=0x555560b57800) at src/mongo/db/service_entry_point_common.cpp:623
#43 mongo::(anonymous namespace)::<lambda()>::<lambda(auto:81*)>::operator()<mongo::(anonymous namespace)::ExecCommandDatabase> (__closure=<optimized out>, runner=0x555560b57800)
    at src/mongo/db/service_entry_point_common.cpp:1880
#44 mongo::future_util::AsyncState<mongo::(anonymous namespace)::ExecCommandDatabase>::<lambda()>::operator()(void) const (this=<optimized out>, this=<optimized out>)
    at src/mongo/util/future_util.h:742
#45 0x0000555556c58be2 in mongo::makeReadyFutureWith<mongo::future_util::AsyncState<State>::thenWithState(Launcher&&) && [with Launcher = mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()> mutable::<lambda(auto:81*)>; State = mongo::(anonymous namespace)::ExecCommandDatabase]::<lambda()> > (func=...) at src/mongo/util/future.h:1206
#46 mongo::future_util::AsyncState<mongo::(anonymous namespace)::ExecCommandDatabase>::thenWithState<mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()> mutable::<lambda(auto:81*)> > (launcher=..., this=0x7fffe59639c0) at src/mongo/util/future_util.h:747
#47 mongo::(anonymous namespace)::<lambda()>::operator() (__closure=<optimized out>) at src/mongo/db/service_entry_point_common.cpp:1880
#48 mongo::future_details::call<mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>&> (func=...)
    at src/mongo/util/future_impl.h:255
--Type <RET> for more, q to quit, c to continue without paging--
#49 mongo::future_details::throwingCall<mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>&, mongo::future_details::FakeVoid> (func=...) at src/mongo/util/future_impl.h:308
#50 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda()>::<lambda(mongo::future_details::SharedState<mongo::future_details::FakeVoid>*, mongo::future_details::SharedState<void>*)>::operator() (output=0x555560b43200, input=<optimized out>, this=<optimized out>) at src/mongo/util/future_impl.h:935
#51 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda(mongo::future_details::SharedStateBase*)>::operator() (ssb=<optimized out>, this=<optimized out>)
    at src/mongo/util/future_impl.h:1257
#52 mongo::unique_function<void(mongo::future_details::SharedStateBase*)>::callRegularVoid<mongo::future_details::FutureImpl<T>::makeContinuation(OnReady&&) [with Result = void; OnReady = mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda()>::<lambda(mongo::future_details::SharedState<mongo::future_details::FakeVoid>*, mongo::future_details::SharedState<void>*)>; T = mongo::future_details::FakeVoid]::<lambda(mongo::future_details::SharedStateBase*)> > (args#0=<optimized out>, f=..., isVoid=...)
    at src/mongo/util/functional.h:145
#53 mongo::unique_function<void(mongo::future_details::SharedStateBase*)>::SpecificImpl::call(mongo::future_details::SharedStateBase *&&) (this=<optimized out>, 
    args#0=<optimized out>) at src/mongo/util/functional.h:159
#54 0x0000555556c14b27 in mongo::unique_function<void (mongo::future_details::SharedStateBase*)>::operator()(mongo::future_details::SharedStateBase*) const (args#0=<optimized out>, 
    this=0x555560b43818) at src/mongo/util/invariant.h:66
#55 mongo::future_details::SharedStateBase::transitionToFinished (this=0x555560b43800) at src/mongo/util/future_impl.h:441
#56 0x0000555556c5fcd2 in mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>::emplaceValue<mongo::future_details::FakeVoid> (this=<optimized out>)
    at /usr/include/c++/9/new:174
#57 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::future_details::FakeVoid&&)#1}::operator()(mongo::future_details::FakeVoid&&) const (this=<optimized out>, val=...) at src/mongo/util/future_impl.h:1146
#58 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::generalImpl<mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::future_details::FakeVoid&&)#1}, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::Status&&)#2}, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda()#3}>(mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::future_details::FakeVoid&&)#1}&&, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::Status&&)#2}&&, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda()#3}&&) (notReady=..., 
    fail=..., success=..., this=<optimized out>) at src/mongo/util/future_impl.h:1191
#59 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::generalImpl<mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::future_details::FakeVoid&&)#1}, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::Status&&)#2}, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda()#3}>(mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::future_details::FakeVoid&&)#1}&&, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda(mongo::Status&&)#2}&&, mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) &&::{lambda()#3}&&) (
    this=<optimized out>, success=..., fail=..., notReady=...) at src/mongo/util/future_impl.h:1182
#60 0x0000555556c520ac in mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::propagateResultTo(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*) && (output=<optimized out>, this=0x7fffe5963b40) at src/mongo/util/future_impl.h:1143
#61 mongo::SemiFuture<void>::propagateResultTo<mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*&>(mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>*&) && (arg=<synthetic pointer>: <optimized out>, this=0x7fffe5963b40) at src/mongo/util/future.h:285
#62 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda()>::<lambda(mongo::future_details::SharedState<mongo::future_details::FakeVoid>*, mongo::future_details::SharedState<void>*)>::operator() (output=0x555560b43800, input=<optimized out>, this=<optimized out>) at src/mongo/util/future_impl.h:935
#63 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda(mongo::future_details::SharedStateBase*)>::operator() (ssb=<optimized out>, this=<optimized out>)
--Type <RET> for more, q to quit, c to continue without paging--
    at src/mongo/util/future_impl.h:1257
#64 mongo::unique_function<void(mongo::future_details::SharedStateBase*)>::callRegularVoid<mongo::future_details::FutureImpl<T>::makeContinuation(OnReady&&) [with Result = void; OnReady = mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::(anonymous namespace)::executeCommand(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda()>::<lambda(mongo::future_details::SharedState<mongo::future_details::FakeVoid>*, mongo::future_details::SharedState<void>*)>; T = mongo::future_details::FakeVoid]::<lambda(mongo::future_details::SharedStateBase*)> > (args#0=<optimized out>, f=..., isVoid=...)
    at src/mongo/util/functional.h:145
#65 mongo::unique_function<void(mongo::future_details::SharedStateBase*)>::SpecificImpl::call(mongo::future_details::SharedStateBase *&&) (this=<optimized out>, 
    args#0=<optimized out>) at src/mongo/util/functional.h:159
#66 0x0000555556c14b27 in mongo::unique_function<void (mongo::future_details::SharedStateBase*)>::operator()(mongo::future_details::SharedStateBase*) const (args#0=<optimized out>, 
    this=0x555560b42d18) at src/mongo/util/invariant.h:66
#67 mongo::future_details::SharedStateBase::transitionToFinished (this=0x555560b42d00) at src/mongo/util/future_impl.h:441
#68 0x0000555556c59141 in mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid>::emplaceValue<>() (this=0x555560b42d00) at /usr/include/c++/9/new:174
#69 mongo::Promise<void>::emplaceValue<, 0>()::{lambda(boost::intrusive_ptr<mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid> >&&)#1}::operator()(boost::intrusive_ptr<mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid> >&&) const (this=<optimized out>, sharedState=<synthetic pointer>) at src/mongo/util/future.h:854
#70 mongo::Promise<void>::setImpl<mongo::Promise<void>::emplaceValue<, 0>()::{lambda(boost::intrusive_ptr<mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid> >&&)#1}>(mongo::Promise<void>::emplaceValue<, 0>()::{lambda(boost::intrusive_ptr<mongo::future_details::SharedStateImpl<mongo::future_details::FakeVoid> >&&)#1}&&) (doSet=..., 
    this=0x7fffe5963ce0) at src/mongo/util/future.h:895
#71 mongo::Promise<void>::emplaceValue<, 0>() (this=0x7fffe5963ce0) at src/mongo/util/future.h:853
#72 mongo::(anonymous namespace)::executeCommand (execContext=...) at src/mongo/db/service_entry_point_common.cpp:1892
#73 0x0000555556c59cbf in mongo::(anonymous namespace)::<lambda()>::operator() (__closure=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:756
#74 mongo::future_details::call<mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>&> (
    func=...) at src/mongo/util/future_impl.h:255
#75 mongo::future_details::throwingCall<mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>&, mongo::future_details::FakeVoid> (func=...) at src/mongo/util/future_impl.h:308
#76 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda(mongo::future_details::FakeVoid&&)>::operator()(mongo::future_details::FakeVoid &&) (val=..., 
    this=<optimized out>) at src/mongo/util/future_impl.h:917
#77 0x0000555556c59e8a in mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::generalImpl<mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda(mongo::future_details::FakeVoid&&)>, mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda(mongo::Status&&)>, mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda()> > (fail=..., notReady=..., success=..., this=0x7fffe5964110) at src/third_party/boost/boost/optional/detail/optional_aligned_storage.hpp:64
#78 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::then<mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()> > (func=..., this=0x7fffe5964110) at src/mongo/util/future_impl.h:940
#79 mongo::Future<void>::then<mongo::(anonymous namespace)::receivedCommands(std::shared_ptr<mongo::(anonymous namespace)::HandleRequest::ExecutionContext>)::<lambda()> > (
    func=..., this=0x7fffe5964110) at src/mongo/util/future.h:405
#80 mongo::(anonymous namespace)::receivedCommands (
    execContext=std::shared_ptr<class mongo::(anonymous namespace)::HandleRequest::ExecutionContext> (use count 11, weak count 0) = {...})
    at src/mongo/db/service_entry_point_common.cpp:1939
#81 0x0000555556c5b130 in mongo::(anonymous namespace)::CommandOpRunner::run (this=<optimized out>) at /usr/include/c++/9/ext/atomicity.h:96
#82 0x0000555556c54f9f in mongo::ServiceEntryPointCommon::handleRequest (opCtx=opCtx@entry=0x555560af8180, m=..., 
    behaviors=std::unique_ptr<const class mongo::ServiceEntryPointCommon::Hooks> = {...}) at src/mongo/db/service_entry_point_common.cpp:2441
#83 0x0000555556c41514 in mongo::ServiceEntryPointMongod::handleRequest (this=<optimized out>, opCtx=0x555560af8180, m=...) at /usr/include/c++/9/bits/move.h:74
--Type <RET> for more, q to quit, c to continue without paging--
#84 0x0000555556cabe0a in mongo::transport::ServiceStateMachine::Impl::processMessage (this=0x555560b81090) at src/mongo/transport/service_state_machine.cpp:466
#85 0x0000555556caf176 in mongo::transport::ServiceStateMachine::Impl::<lambda()>::operator() (__closure=<optimized out>) at src/mongo/transport/service_state_machine.cpp:559
#86 mongo::future_details::call<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()>&> (func=...) at src/mongo/util/future_impl.h:255
#87 mongo::future_details::throwingCall<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()>&, mongo::future_details::FakeVoid> (func=...)
    at src/mongo/util/future_impl.h:308
#88 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::<lambda(mongo::future_details::FakeVoid&&)>::operator() (this=<optimized out>, val=...)
    at src/mongo/util/future_impl.h:917
#89 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::generalImpl<mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda(mongo::future_details::FakeVoid&&)>, mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda(mongo::Status&&)>, mongo::future_details::FutureImpl<T>::then(Func&&) && [with Func = mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()>; T = mongo::future_details::FakeVoid]::<lambda()> > (fail=..., notReady=..., success=..., this=0x7fffe5964780) at src/mongo/util/future_impl.h:1184
#90 mongo::future_details::FutureImpl<mongo::future_details::FakeVoid>::then<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()> > (
    func=..., this=0x7fffe5964780) at src/mongo/util/future_impl.h:940
#91 mongo::Future<void>::then<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda()> > (func=..., this=0x7fffe5964780)
    at src/mongo/util/future.h:405
#92 mongo::transport::ServiceStateMachine::Impl::startNewLoop (execStatus=..., this=0x555560b81090) at src/mongo/transport/service_state_machine.cpp:559
#93 mongo::transport::ServiceStateMachine::Impl::startNewLoop (this=0x555560b81090, execStatus=...) at src/mongo/transport/service_state_machine.cpp:546
#94 0x0000555556caf8e4 in mongo::transport::ServiceStateMachine::Impl::<lambda(mongo::Status)>::<lambda(mongo::Status)>::<lambda()>::operator() (__closure=<synthetic pointer>, 
    __closure=<synthetic pointer>) at src/mongo/transport/service_state_machine.cpp:588
#95 mongo::ClientStrand::run<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda(mongo::Status)>::<lambda(mongo::Status)>::<lambda()> > (
    task=..., this=<optimized out>) at src/mongo/db/client_strand.h:165
#96 mongo::transport::ServiceStateMachine::Impl::<lambda(mongo::Status)>::<lambda(mongo::Status)>::operator() (__closure=<optimized out>, execStatus=...)
    at src/mongo/transport/service_state_machine.cpp:588
#97 mongo::unique_function<void(mongo::Status)>::callRegularVoid<mongo::transport::ServiceStateMachine::Impl::startNewLoop(const mongo::Status&)::<lambda(mongo::Status)>::<lambda(mongo::Status)> > (args#0=..., f=..., isVoid=...) at src/mongo/util/functional.h:145
#98 mongo::unique_function<void(mongo::Status)>::SpecificImpl::call(mongo::Status &&) (this=<optimized out>, args#0=...) at src/mongo/util/functional.h:159
#99 0x00005555592c9065 in mongo::unique_function<void (mongo::Status)>::operator()(mongo::Status) const (args#0=..., this=<optimized out>) at src/mongo/util/invariant.h:66
#100 mongo::transport::ServiceExecutorSynchronous::<lambda(mongo::Status)>::operator() (status=..., __closure=<optimized out>)
    at src/mongo/transport/service_executor_synchronous.cpp:163
#101 mongo::unique_function<void(mongo::Status)>::callRegularVoid<mongo::transport::ServiceExecutorSynchronous::runOnDataAvailable(const SessionHandle&, mongo::OutOfLineExecutor::Task)::<lambda(mongo::Status)> > (args#0=..., f=..., isVoid=...) at src/mongo/util/functional.h:145
#102 mongo::unique_function<void(mongo::Status)>::SpecificImpl::call(mongo::Status &&) (this=<optimized out>, args#0=...) at src/mongo/util/functional.h:159
#103 0x000055555741b9d8 in mongo::unique_function<void (mongo::Status)>::operator()(mongo::Status) const (args#0=..., this=<optimized out>) at src/mongo/util/invariant.h:66
#104 mongo::transport::ServiceExecutor::schedule(mongo::unique_function<void (mongo::Status)>)::{lambda()#1}::operator()() (__closure=<optimized out>)
    at src/mongo/transport/service_executor.h:111
#105 mongo::unique_function<void ()>::callRegularVoid<mongo::transport::ServiceExecutor::schedule(mongo::unique_function<void (mongo::Status)>)::{lambda()#1}>(std::integral_constant<bool, true>, mongo::transport::ServiceExecutor::schedule(mongo::unique_function<void (mongo::Status)>)::{lambda()#1}&) (f=..., isVoid=...) at src/mongo/util/functional.h:145
#106 mongo::unique_function<void ()>::makeImpl<mongo::transport::ServiceExecutor::schedule(mongo::unique_function<void (mongo::Status)>)::{lambda()#1}>(mongo::transport::ServiceExecutor::schedule(mongo::unique_function<void (mongo::Status)>)::{lambda()#1}&&)::SpecificImpl::call() (this=<optimized out>) at src/mongo/util/functional.h:159
#107 0x00005555592c923f in mongo::unique_function<void ()>::operator()() const (this=<optimized out>) at src/mongo/util/invariant.h:66
#108 mongo::transport::ServiceExecutorSynchronous::<lambda()>::operator() (__closure=0x55556037a1a8) at src/mongo/transport/service_executor_synchronous.cpp:131
#109 mongo::unique_function<void()>::callRegularVoid<mongo::transport::ServiceExecutorSynchronous::scheduleTask(mongo::transport::ServiceExecutor::Task, mongo::transport::ServiceExec--Type <RET> for more, q to quit, c to continue without paging--
utor::ScheduleFlags)::<lambda()> > (f=..., isVoid=...) at src/mongo/util/functional.h:145
#110 mongo::unique_function<void()>::SpecificImpl::call(void) (this=0x55556037a1a0) at src/mongo/util/functional.h:159
#111 0x00005555592cdc28 in mongo::unique_function<void ()>::operator()() const (this=0x555560b58f58) at src/mongo/util/invariant.h:66
#112 mongo::<lambda()>::operator() (__closure=0x555560b58f48) at src/mongo/transport/service_executor_utils.cpp:111
#113 mongo::unique_function<void()>::callRegularVoid<mongo::launchServiceWorkerThread(mongo::unique_function<void()>)::<lambda()> > (f=..., isVoid=...)
    at src/mongo/util/functional.h:145
#114 mongo::unique_function<void()>::SpecificImpl::call(void) (this=0x555560b58f40) at src/mongo/util/functional.h:159
#115 0x00005555592cdca1 in mongo::unique_function<void ()>::operator()() const (this=0x55555c01a4b8) at src/mongo/util/invariant.h:66
#116 mongo::(anonymous namespace)::runFunc (ctx=0x55555c01a4b8) at src/mongo/transport/service_executor_utils.cpp:64
#117 0x00007ffff7b8a609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#118 0x00007ffff777f293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

霍尔逻辑_从快排开始

May 24, 2021 · One min read

什么是霍尔逻辑: 霍尔逻辑由三个部分组成:
ϕ被称为前置条件，
P是程序片段，
ψ称为后置条件

堆栈

May 24, 2021 · One min read

在x86_64中,调用栈是从高地址到低地址增长的, %rbp寄存器有两个核心的内容:

0(%rbp)也就是%rbp寄存器指向的寄存器内容,这个指针指向的地址也存着上一个堆栈的%rbp堆栈的地址
8(%rbp)也就是%rbp寄存器存着另外一个存的是返回地址,什么是返回地址?就是指令段的地址

也就是rbp通过寄存器我们可以得到

8(%rbp):上一个堆栈的代码段开始
(%rbp): 上一个堆栈的开始

redis

5 HA

failover 错误转移

分片

一致性

缓存穿透雪崩

限流

Welcome

redis 主从切换和高可用

MDX Blog Post

mysql 5.7 in 的优化引起的bug

起因

问题

排查

解决

事后扒代码

tcp_nodelay

tcp_nodealy

相关阅读

skiplist

跳表 skiplist

相关阅读

mongoinsert

相关阅读

霍尔逻辑_从快排开始

相关阅读

堆栈

相关阅读

5 HA​

failover 错误转移​

分片​

一致性​

缓存穿透 雪崩​

限流​

起因​

问题​

排查​

解决​

事后扒代码​

tcp_nodealy​

相关阅读​

跳表 skiplist​

相关阅读​

相关阅读​

相关阅读​

相关阅读​

5 HA

failover 错误转移

分片

一致性

缓存穿透雪崩

限流

起因

问题

排查

解决

事后扒代码

tcp_nodealy

相关阅读

跳表 skiplist

相关阅读

相关阅读

相关阅读

相关阅读