Risposta breve / tl;dr
No.
Risposta leggermente più lunga
No, perché ha senso usare la shell.
Risposta
Quando configuri un set di repliche, di solito hai più di un membro. Fino all'inizializzazione del set di repliche, nessuno dei membri mantiene la configurazione necessaria. Il nodo su cui si inizializza la replica impostata diventa primario, memorizzando la configurazione. Ora aggiungi membri utilizzando rs.add comando o utilizzando rs.reconfig . Quello che succede allora è che il principale contatta il membro aggiunto, la configurazione è sincronizzata e alcune altre cose. È buona norma che i membri del set di repliche ordinario siano uguali in modo che di un nodo si guasta, non vi è alcun inconveniente che un altro nodo diventi primario e quindi il nuovo primario possa rimanere primario fino a quando non si interrompe per qualche motivo o per l'altro stesso.
Quindi, se dovessi avviare un membro del set di repliche, da dove dovrebbe ottenere la sua configurazione? Decidere da sé cosa deve fare? Non funzionerebbe bene in un cluster. Come dovrebbe scoprire gli altri membri e la loro configurazione? Tenere presente che i membri del set di repliche possono trovarsi in data center diversi. E se fosse presente un --IamPrimaryDoAsISay opzione, cosa accadrebbe se ci fosse un altro primario attualmente nel cluster? E come dovrebbe essere affrontata una situazione in cui più di un membro è stato avviato con tale opzione? Un passo indietro dell'altro server? Potrebbe essere solo perché hai sostituito un dispositivo di raffreddamento? O l'istanza appena avviata non dovrebbe fare nulla quando c'era già un primario? Che senso avrebbe allora l'opzione in primo luogo?
E tutte queste complicazioni solo per impedire un singolo comando dalla shell?
Nota:se desideri un server singolo, avvia un'istanza autonoma (un mongod senza --replSet opzione).se vuoi esplorare le possibilità di un set di repliche, hai bisogno di più di un membro.
