Perguntas[sharding](dba)

Eu tenho uma coleção de fragmentos em que a chave de fragmento é um campo chamado "uuid". O valor deste campo é do tipo string e representa valores hexadecimais, ou seja, uma string hexadecimal. Para cada documento este campo "uuid" é único.

Os dados são divididos em pedaços automaticamente pelo MongoDB. Não consigo descobrir como o MongoDB está dividindo essa string hexadecimal em intervalos contíguos. Não há documentos que expliquem como o Mongo forma essas faixas

Você pode me ajudar a entender como esses intervalos são formados?

Para uma amostra, inseri 3025357 documentos com os referidos valores hexadecimais. Os pedaços e os intervalos associados a eles são,

{    
    "_id" : "database.sha_shard-uuid_MinKey",
    "lastmod" : Timestamp(2, 0),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : { "$minKey" : 1 }
    },
    "max" : {
        "uuid" : "000043c071f23fc889275f77f950c649faac92e0"
    },
    "shard" : "shardRpSet2",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577632842, 37),
            "shard" : "shardRpSet2"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"5b935a89d91977490d04f740a86bccc2b3cc2bfb\"",
    "lastmod" : Timestamp(3, 5),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "5b935a89d91977490d04f740a86bccc2b3cc2bfb"
    },
    "max" : {
        "uuid" : "7a25fa7aa3a86ed259f646d7890db370e8b43ae7"
    },
    "shard" : "shardRpSet1",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577632856, 21509),
            "shard" : "shardRpSet1"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"7a25fa7aa3a86ed259f646d7890db370e8b43ae7\"",
    "lastmod" : Timestamp(3, 6),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "7a25fa7aa3a86ed259f646d7890db370e8b43ae7"
    },
    "max" : {
        "uuid" : "810b573464d4894fc40b428ec82ec54d9a681bf6"
    },
    "shard" : "shardRpSet1",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577632856, 21509),
            "shard" : "shardRpSet1"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"000043c071f23fc889275f77f950c649faac92e0\"",
    "lastmod" : Timestamp(4, 0),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "000043c071f23fc889275f77f950c649faac92e0"
    },
    "max" : {
        "uuid" : "1e8421c5d4f3eb45a82c2785bccc81fa7abfbfc7"
    },
    "shard" : "shardRpSet2",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577635896, 15268),
            "shard" : "shardRpSet2"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"1e8421c5d4f3eb45a82c2785bccc81fa7abfbfc7\"",
    "lastmod" : Timestamp(5, 0),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "1e8421c5d4f3eb45a82c2785bccc81fa7abfbfc7"
    },
    "max" : {
        "uuid" : "3d165990d2969bbaf79b6b0d790080b46ca5f056"
    },
    "shard" : "shardRpSet",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577635906, 26457),
            "shard" : "shardRpSet"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"3d165990d2969bbaf79b6b0d790080b46ca5f056\"",
    "lastmod" : Timestamp(5, 1),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "3d165990d2969bbaf79b6b0d790080b46ca5f056"
    },
    "max" : {
        "uuid" : "5b935a89d91977490d04f740a86bccc2b3cc2bfb"
    },
    "shard" : "shardRpSet1",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577632856, 21509),
            "shard" : "shardRpSet1"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"c1788722a31a5a5a5caa00816ad85aeeda26e581\"",
    "lastmod" : Timestamp(5, 2),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "c1788722a31a5a5a5caa00816ad85aeeda26e581"
    },
    "max" : {
        "uuid" : "dcbd245e03d425aa14a85b51befde274856fc5f3"
    },
    "shard" : "shardRpSet",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577630416, 3),
            "shard" : "shardRpSet"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"dcbd245e03d425aa14a85b51befde274856fc5f3\"",
    "lastmod" : Timestamp(5, 3),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "dcbd245e03d425aa14a85b51befde274856fc5f3"
    },
    "max" : {
        "uuid" : "fffff8c5e160711fb48f0d38ce01a98880e869e2"
    },
    "shard" : "shardRpSet",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577630416, 3),
            "shard" : "shardRpSet"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"fffff8c5e160711fb48f0d38ce01a98880e869e2\"",
    "lastmod" : Timestamp(6, 0),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "fffff8c5e160711fb48f0d38ce01a98880e869e2"
    },
    "max" : {
        "uuid" : { "$maxKey" : 1 }
    },
    "shard" : "shardRpSet2",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577636268, 67),
            "shard" : "shardRpSet2"
        }
    ]
},{
    "_id" : "database.sha_shard-uuid_\"810b573464d4894fc40b428ec82ec54d9a681bf6\"",
    "lastmod" : Timestamp(6, 1),
    "lastmodEpoch" : ObjectId("5e08bad0b5e6b931087f0871"),
    "ns" : "database.sha_shard",
    "min" : {
        "uuid" : "810b573464d4894fc40b428ec82ec54d9a681bf6"
    },
    "max" : {
        "uuid" : "c1788722a31a5a5a5caa00816ad85aeeda26e581"
    },
    "shard" : "shardRpSet",
    "history" : [ 
        {
            "validAfter" : Timestamp(1577630416, 3),
            "shard" : "shardRpSet"
        }
    ]
}

Eu preciso criar uma sequência e preciso usar a sequência para id de incremento automático para mais de 2 bancos de dados em 2 servidores separados. Estou me referindo abaixo do doc para isso (para fins de teste): https://paquier.xyz/postgresql-2/global-sequences-with-postgres_fdw-and-postgres-core/

Eu segui os passos abaixo:

    Server 1: 
CREATE DATABASE
postgres=# \c a1
You are now connected to database "a1" as user "postgres".
a1=# CREATE SEQUENCE seq;
CREATE SEQUENCE
a1=# CREATE VIEW seq_view AS SELECT nextval('seq') as a;
CREATE VIEW
a1=# \c postgres
You are now connected to database "postgres" as user "postgres".

postgres=# create database a2;
 CREATE DATABASE
 postgres=# \c a2;
You are now connected to database "a2" as user "postgres".
a2=# CREATE EXTENSION postgres_fdw;
CREATE EXTENSION
a2=# CREATE SERVER postgres_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS
a2-# (host '192.168.xx.xxx', port '5432', dbname 'a1');
CREATE SERVER
a2=# CREATE USER MAPPING FOR PUBLIC SERVER postgres_server OPTIONS (password 
'');
CREATE USER MAPPING
a2=# CREATE FOREIGN TABLE foreign_seq_table (a bigint) SERVER
a2-# postgres_server
a2-# OPTIONS (table_name 'seq_view');
CREATE FOREIGN TABLE
a2=# select * from foreign_seq_table;
 a
---
 1
(1 row)

a2=# select * from foreign_seq_table;
a
---
2
(1 row)

Como pode ser visto no exemplo acima, está funcionando corretamente para 2 bancos de dados no mesmo servidor. No entanto, quando prossigo com outro servidor, fiz as etapas abaixo:

    postgres=# create database kbc;
CREATE DATABASE
 postgres=# \c kbc
You are now connected to database "kbc" as user "postgres".
kbc=#  CREATE EXTENSION postgres_fdw;
CREATE EXTENSION
kbc=# CREATE SERVER postgres_server FOREIGN DATA WRAPPER postgres_fdw 
OPTIONS
kbc-# (host '192.168.xx.xxx', port '5432', dbname 'a1');
CREATE SERVER
kbc=# CREATE USER MAPPING FOR PUBLIC SERVER postgres_server OPTIONS 
(password '');
CREATE USER MAPPING
kbc=#
kbc=# CREATE FOREIGN TABLE foreign_seq_table (a bigint) SERVER 
postgres_server OPTIONS (table_name 'seq_view');
  CREATE FOREIGN TABLE
 kbc=# select * from foreign_seq_table;
  ERROR:  could not connect to server "postgres_server"
    DETAIL:  fe_sendauth: no password supplied

O erro finalmente estou recebendo. Existe alguma coisa/qualquer passo que estou perdendo aqui. Posso facilmente fazer ping no servidor antigo (onde criei a sequência) do novo servidor (onde quero usar essa sequência). configurações do arquivo pg_hba.conf em ambos os servidores -> as entradas são md5 ou trust only. Qualquer outra entrada que eu preciso adicionar no arquivo de configuração? Qualquer documento sugerido para fdw em diferentes servidores também será útil.

Desde já, obrigado!

Observação: não posso usar o UUID devido a alguns requisitos do aplicativo. É por isso que precisamos de uma coluna numérica de incremento automático. Ele escolhe o valor de id mais alto.

Eu estava lendo recentemente um artigo sobre como o Instgram costumava fragmentar seus IDs e eles usam uma função exclusiva para gerar IDs em seus servidores https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

Mas fiquei curioso para saber se você poderia atribuir um fragmento a um usuário específico em vez de cada item e qual seria o desempenho. Especialmente em um site de grande escala.

Então, uma função semelhante à seguinte seria uma abordagem válida.

Assumindo uma tabela de usuários em um banco de dados dedicado exclusivamente para usuários.

Usuário - UID - nome - shardId

Onde shardId é calculado por meio de uma função que começa em 1 e para cada nova inserção seria incrementada - até um máximo de n (digamos 2048) para este exemplo. Em seguida, redefina para 1. Quase agindo como um round robin para distribuir os dados dos usuários entre os shards.

Haveria sérias implicações de desempenho para tal função, especialmente durante alta carga? Como colunas seriais, basta selecionar um nextval de uma sequência, não é? É apenas uma etapa extra de redefinir uma sequência quando ela atinge n. Ou estou latindo para a árvore errada?

Vamos imaginar que eu tenho duas coleções de fragmentos do mongodb: curtidas e comentários.

Ambas as coleções são fragmentadas, ambas as coleções têm userId como uma chave fragmentada.

Vamos imaginar que a coleção de curtidas é enorme e a coleção de comentários é pequena. Eu tenho 10 fragmentos no total, vamos nomeá-los de fragmento A para fragmento G.

Posso supor que, se as curtidas de algum usuário específico estiverem no fragmento A, seus comentários também estarão no fragmento A?

Então, o que eu quero alcançar é ter os dados de qualquer usuário específico no mesmo shard. As curtidas de outros usuários podem estar no fragmento C, então seus comentários também devem estar no fragmento C.

É possível configurar o MongoDB? (ou é a maneira como está funcionando por padrão?)

Isso pode ser mais um conselho do que qualquer outra coisa, mas estou projetando um aplicativo que armazena em uma tabela objetos que possuem um índice 2dsphere e também possuem uma data (+hora), ambos fazendo parte de consultas que estou fazendo para recuperar alguns desses objetos.

Este banco de dados terá que ser fragmentado, então fragmentar de acordo com a chave espacial parece o primeiro passo. É basicamente um dado que esse índice fará parte da chave fragmentada. A outra chave deve ser o tempo, e tenho certeza de que o hash do tempo não será adequado, pois as consultas estão procurando o intervalo de datas para os objetos. Então, o hash forçará o acesso a todos os pedaços (com as restrições espaciais apropriadas), o que eu não quero.

Então, minha pergunta é saber se isso é viável e também se o mongodb será inteligente o suficiente para não dividir de acordo com a chave espacial, a menos que eu peça manualmente?

Configurei um servidor PostgreSQL FDW com a seguinte tabela, fragmentada por user_idmais de quatro servidores:

CREATE TABLE my_big_table
(
    user_id bigint NOT NULL,
    serial bigint NOT NULL,         -- external, incrementing only
    some_object_id bigint NOT NULL,
    timestamp_ns bigint NOT NULL,
    object_type smallint NOT NULL,
    other_type smallint NOT NULL,
    data bytea
) PARTITION BY HASH (user_id) ;

CREATE SERVER shardA
    FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host '192.168.200.11', port '5432', dbname 'postgres', fetch_size '10000');
 .
 .
 .
CREATE SERVER shardD
    FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host '192.168.200.14', port '5432', dbname 'postgres', fetch_size '10000');

create foreign table my_big_table_mod4_s0 partition of my_big_table
    FOR VALUES WITH (MODULUS 4, REMAINDER 0) server shardA
    OPTIONS (table_name 'my_big_table_mod4_s0');
 .
 .
 .
create foreign table my_big_table_mod4_s3 partition of my_big_table
    FOR VALUES WITH (MODULUS 4, REMAINDER 3) server shardD
    OPTIONS (table_name 'my_big_table_mod4_s3');

Nos servidores de back-end, configurei uma tabela com vários índices, seus dados agrupados (user_id, serial)em várias partições. No entanto, não acho que esses detalhes sejam muito relevantes para minha pergunta real.

A consulta comum no meu cluster está no padrão de:

SELECT * from my_big_table
WHERE
  user_id = 12345     -- only 1 user, always! --> single foreign server.
ORDER BY serial DESC  -- get 'newest' 90% of the time, 10% ASC
LIMIT 1000;           -- max limit 1000, sometimes less

Para usuários com < 1000 registros: tudo bem, sem problemas.

Para usuários com > 100.000 registros, vejo o problema que leva a um desempenho ruim: explainmostra LIMIT e a classificação acontece no FDW, não é pressionado. Por quê?

 Limit  (cost=927393.08..927395.58 rows=1000 width=32)
   Output: my_big_table_mod4_s0.serial, my_big_table_mod4_s0.some_object_id, my_big_table_mod4_s0.timestamp_ns, my_big_table_mod4_s0.object_type, my_big_table_mod4_s0.other_type, (length(my_big_table_mod4_s0.data))
   ->  Sort  (cost=927393.08..931177.06 rows=1513592 width=32)
         Output: my_big_table_mod4_s0.serial, my_big_table_mod4_s0.some_object_id, my_big_table_mod4_s0.timestamp_ns, my_big_table_mod4_s0.object_type, my_big_table_mod4_s0.other_type, (length(my_big_table_mod4_s0.data))
         Sort Key: my_big_table_mod4_s0.serial DESC
         ->  Foreign Scan on public.my_big_table_mod4_s0  (cost=5318.35..844404.46 rows=1513592 width=32)
               Output: my_big_table_mod4_s0.serial, my_big_table_mod4_s0.some_object_id, my_big_table_mod4_s0.timestamp_ns, my_big_table_mod4_s0.object_type, my_big_table_mod4_s0.other_type, length(my_big_table_mod4_s0.data)
               Remote SQL: SELECT serial, some_object_id, timestamp_ns, object_type, other_type, data FROM public.my_big_table_mod4_s0 WHERE ((user_id = 4560084))
 JIT:
   Functions: 3
   Options: Inlining true, Optimization true, Expressions true, Deforming true

O takeaway do acima é:

• Servidor de back-end único selecionado: OK! (resolvido com isso )
• Remote SQL: SELECT [...]indica que não há ORDER BY, nem LIMIT. Problema.

Executado no servidor back-end mostra isso diretamente:

 Limit  (cost=1.74..821.42 rows=1000 width=32)
   Output: my_big_table_mod4_s0_part123.serial, my_big_table_mod4_s0_part123.some_object_id, my_big_table_mod4_s0_part123.timestamp_ns, my_big_table_mod4_s0_part123.object_type, my_big_table_mod4_s0_part123.other_type, (length(my_big_table_mod4_s0_part123.data))
   ->  Append  (cost=1.74..1240669.45 rows=1513592 width=32)
         ->  Index Scan Backward using my_big_table_mod4_s0_part123_pkey on public.my_big_table_mod4_s0_part123  (cost=0.43..290535.67 rows=355620 width=32)
               Output: my_big_table_mod4_s0_part123.serial, my_big_table_mod4_s0_part123.some_object_id, my_big_table_mod4_s0_part123.timestamp_ns, my_big_table_mod4_s0_part123.object_type, my_big_table_mod4_s0_part123.other_type, length(my_big_table_mod4_s0_part123.data)
               Index Cond: (my_big_table_mod4_s0_part123.user_id = 4560084)
         ->  Index Scan Backward using [... other partitions ...]

O que eu tentei:

• Como o FDW ainda está ativo em desenvolvimento, tentei usar uma versão mais recente: 11.4 e 12-beta2 tanto para FDW quanto para servidores backend. Nenhuma diferença observada.
• Executando ANALYZE na tabela externa (na instância FDW). Leva muito tempo; parece que está cheio de tabelas digitalizando a tabela remota? Nenhuma diferença no planejamento de consultas.
• Alterando o valor de fetch_sizeno objeto SERVER remoto. Nenhuma diferença.
• Definido use_remote_estimate=trueno objeto SERVER remoto. Nenhuma diferença.
• Definido fdw_tuple_cost=100no objeto SERVER remoto. A classificação agora acontece no servidor remoto, mas LIMIT ainda não foi pressionado.

• Procurando online por outras pessoas vendo isso, mostrando apenas este post relacionado: Missed LIMIT cláusula pushdown na API FDW

  Mas este tópico menciona commits corrigindo isso em 9.7 e outros enfeites, mas estou usando 11.4 e 12-beta2. Ou eu entendo isso errado?

  E post: Estimativa de custo estranho para tabelas estrangeiras mostra um bom exemplo de ajuste de FDW, mas infelizmente não cobre meu problema com LIMITs.

• Dando uma rápida olhada no código fonte do PostgreSQL, notei esta declaração, talvez relevante para FDW, talvez não ( source ).

  Não podemos enviar subseleções contendo LIMIT/OFFSET para os trabalhadores, pois não há garantia de que a ordem das linhas seja totalmente determinística, e a aplicação de LIMIT/OFFSET levará a resultados inconsistentes no nível superior. (Em alguns casos, onde o resultado é ordenado, podemos relaxar essa restrição. Mas atualmente não parece valer a pena gastar um esforço extra para fazê-lo.)

• Dando outra olhada no código-fonte, encontrei este commit promissor ( d50d172e51 ):

  Isso fornece a capacidade do postgres_fdw de lidar com comandos SELECT para que 1) pule a etapa LockRows (se houver) (observe que isso é seguro, pois executa o bloqueio antecipado) e 2) reduz as restrições LIMIT e/ou OFFSET (se houver) ) para o lado remoto. Isso não lida com os casos INSERT/UPDATE/DELETE.

  Ele adiciona um caso de teste de unidade exatamente para o meu caso!

  -- and both ORDER BY and LIMIT can be shipped
  EXPLAIN (VERBOSE, COSTS OFF)
    SELECT * FROM ft1 t1 WHERE t1.c1 === t1.c2 order by t1.c2 limit 1;
                                                                          QUERY PLAN                                                                         
  ------------------------------------------------------------------------------------------------------------------------------------------------------------
  Foreign Scan on public.ft1 t1
    Output: c1, c2, c3, c4, c5, c6, c7, c8
    Remote SQL: SELECT "C 1", c2, c3, c4, c5, c6, c7, c8 FROM "S 1"."T 1" WHERE (("C 1" OPERATOR(public.===) c2)) ORDER BY c2 ASC NULLS LAST LIMIT 1::bigint
  

  que deve fazer parte do 12-beta2, que já estou rodando...

^{Percebi que deveria usar índices na ordem DESC aqui, mas isso não é tão relevante agora.}

Eu configurei o cluster fragmentado mongodb com a seguinte topologia

• 3 x 3 fragmentos (cada um com 2 conjuntos de réplicas)
• cluster de réplica do servidor de configuração 1x3
• 2 roteadores mongos

Eu quero desligar todo o cluster temporariamente, mantendo a integridade dos dados intacta. Eu posso usar essa configuração mais tarde, então não quero descartar toda a configuração.

Quaisquer sugestões seriam apreciadas.

Estou escrevendo minha primeira publicação sobre MongoDB e clusters MongoDB Sharded mais específicos. Na documentação, descobri que a chave de fragmentação no caso de fragmentação à distância deve ser "Chaves de fragmentação que não mudam monotonicamente".

Alguém pode explicar isso para mim? Exemplo seria apreciado.

Obrigado.

Adicionei um shard a um cluster existente e, quando faço db.printShardingStatus(), vejo uma distribuição:

mongos> db.printShardingStatus()
--- Sharding Status --- 
  sharding version: {
    "_id" : 1,
    "minCompatibleVersion" : 5,
    "currentVersion" : 6,
    "clusterId" : ObjectId("5c84149e75f51a74e9796add")
  }
  shards:
        {  "_id" : "shard0000",  "host" : "127.0.0.1:27023",  "state" : 1 }
        {  "_id" : "shard0001",  "host" : "127.0.0.1:27024",  "state" : 1 }
        {  "_id" : "shard0002",  "host" : "localhost:27025",  "state" : 1 }
  active mongoses:
        "4.0.6" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  3
        Last reported error:  Error connecting to localhost:27025 (127.0.0.1:27025) :: caused by :: Connection refused
        Time of Reported error:  Sat Mar 09 2019 20:55:55 GMT+0000 (UTC)
        Migration Results for the last 24 hours: 
                8 : Success
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
                config.system.sessions
                        shard key: { "_id" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                shard0000   1
                        { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1, 0) 
        {  "_id" : "testdb",  "primary" : "shard0001",  "partitioned" : true,  "version" : {  "uuid" : UUID("68b7f8fe-17f6-4049-87ce-6c616c7746b7"),  "lastMod" : 1 } }
                testdb.testcollection
                        shard key: { "testkey" : 1 }
                        unique: false
                        balancing: true
                        chunks:
                                shard0000   3
                                shard0001   3
                                shard0002   1
                        { "testkey" : { "$minKey" : 1 } } -->> { "testkey" : "key0" } on : shard0002 Timestamp(9, 0) 
                        { "testkey" : "key0" } -->> { "testkey" : "key20968" } on : shard0000 Timestamp(7, 1) 
                        { "testkey" : "key20968" } -->> { "testkey" : "key4265" } on : shard0000 Timestamp(4, 0) 
                        { "testkey" : "key4265" } -->> { "testkey" : "key53621" } on : shard0000 Timestamp(6, 0) 
                        { "testkey" : "key53621" } -->> { "testkey" : "key64595" } on : shard0001 Timestamp(5, 1) 
                        { "testkey" : "key64595" } -->> { "testkey" : "key8552" } on : shard0001 Timestamp(9, 1) 
                        { "testkey" : "key8552" } -->> { "testkey" : { "$maxKey" : 1 } } on : shard0001 Timestamp(4, 1) 

Mas quando eu acesso o shard recém adicionado (shard0002), a coleção está vazia? Alguem sabe por quê?

Estou tentando fragmentar minha coleção. quando executo o comando:

sh.enableSharding("testdb")

Eu recebo:

{
    "ok" : 1,
    "operationTime" : Timestamp(1552083125, 2),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1552083125, 2),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

Agora, quando tento fragmentar minha coleção com o comando: "sh.shardCollection("testdb.testcollection", {testkey:1})"

Eu recebo o erro:

{
    "ok" : 0,
    "errmsg" : "Cannot accept sharding commands if not started with --shardsvr",
    "code" : 193,
    "codeName" : "NoShardingEnabled",
    "operationTime" : Timestamp(1552083136, 4),
    "$clusterTime" : {
        "clusterTime" : Timestamp(1552083136, 4),
        "signature" : {
            "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
            "keyId" : NumberLong(0)
        }
    }
}

Verifiquei o status do estilhaço e parece que foi bem-sucedido:

sh.status()
--- Sharding Status --- 
  sharding version: {
    "_id" : 1,
    "minCompatibleVersion" : 5,
    "currentVersion" : 6,
    "clusterId" : ObjectId("5c82df7b7a98360e9dd3c5da")
  }
  shards:
        {  "_id" : "shard0000",  "host" : "127.0.0.1:27023",  "state" : 1 }
        {  "_id" : "shard0001",  "host" : "127.0.0.1:27024",  "state" : 1 }
  active mongoses:
        "4.0.6" : 1
  autosplit:
        Currently enabled: yes
  balancer:
        Currently enabled:  yes
        Currently running:  no
        Failed balancer rounds in last 5 attempts:  0
        Migration Results for the last 24 hours: 
                No recent migrations
  databases:
        {  "_id" : "config",  "primary" : "config",  "partitioned" : true }
        {  "_id" : "testdb",  "primary" : "shard0000",  "partitioned" : true,  "version" : {  "uuid" : UUID("ed327ab3-1de9-4a0a-89f5-8d0bf81015fc"),  "lastMod" : 1 } }

Então, por que recebo esse erro quando tento shardCollection? Estou executando tudo isso na instância do mongos