{"id":412,"date":"2019-04-19T15:42:14","date_gmt":"2019-04-19T13:42:14","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=412"},"modified":"2021-03-17T12:34:27","modified_gmt":"2021-03-17T11:34:27","slug":"come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/","title":{"rendered":"Come creare un ReplicaSet  di MongoDB con Self-Healing usando i servizi di AWS"},"content":{"rendered":"<p><span style=\"font-weight: 300;\"><strong>MongoDB<\/strong> \u00e8 un database NOSQL documentale immediato da configurare e da utilizzare e sta avendo una grandissima diffusione nei nuovi progetti di sviluppo. In questo articolo vedremo come sia possibile creare un sistema di <strong>self healing<\/strong> per i cluster di Mongo creati su AWS in modo da prevenire un possibile downtime.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">MongoDB consente di creare un <strong>cluster distribuito in alta affidabilit\u00e0<\/strong> tramite i Replica Sets e lo Sharding:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>I Replica Sets<\/strong> sono insiemi di nodi identici su cui vengono replicati i documenti JSON inseriti nel database. <\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>Lo Sharding<\/strong> consente di scrivere ogni insieme di documenti JSON (Collections) su un server \u00a0differente, garantendo quindi un miglior throughput sia in lettura che in scrittura. <\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 300;\">La configurazione in Sharding non \u00e8 tollerante ad alcun fallimento, infatti in caso di down di una macchina le Collection presenti sulla stessa diventano inaccessibili. Per ovviare a questo problema si opta per una <strong>configurazione mista basata su Sharding e Replication<\/strong> dove ogni nodo dello sharding \u00e8 in realt\u00e0 un Replica Set.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Ogni Replica Set \u00e8 composto da un Master che si occupa di eseguire le operazioni di scrittura e lettura e da almeno due Repliche che non accettano direttamente scritture ma vengono tenute sincronizzate con i dati presenti nel Master e possono eseguire solo operazioni in lettura. Ogni nodo comunica agli altri continuamente (ogni 2 secondi) il proprio stato tramite un sistema di heartbeats e in caso di fallimento del master i nodi secondari eseguono una votazione con cui viene eletto il nuovo Master. <\/span><\/p>\n<p><span style=\"font-weight: 300;\">Affinch\u00e9 la votazione avvenga correttamente tuttavia devono partecipare alla votazione <strong>pi\u00f9 del 50% dei nodi che compongono il cluster. <\/strong><\/span><\/p>\n<p><span style=\"font-weight: 300;\">Nel caso di un deploy su AWS \u00e8 pertanto consigliabile <strong>distribuire equamente le EC2 su almeno tre Availability Zones<\/strong> (AZ) se si desidera che il Replica Set resti funzionante anche in caso di down di una AZ.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Per database di dimensioni contenute e non <\/span><i><span style=\"font-weight: 300;\">read intensive,<\/span><\/i><span style=\"font-weight: 300;\"> oppure per database con Sharding, molto spesso si usa una configurazione con tre nodi per il Replica Set. In questa configurazione in caso di fallimento di un nodo ne rimangono sempre disponibili altri due per la votazione, uno dei quali verr\u00e0 promosso a master.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Tuttavia, soprattutto in condizioni di traffico intenso, il fallimento di un nodo deve essere trattato come un emergenza e risolto il prima possibile in quanto qualunque ulteriore fallimento comporterebbe una interruzione del servizio. <\/span><\/p>\n<p><span style=\"font-weight: 300;\">Per risolvere in modo automatico questo tipo di situazione e consentire a chi si occupa di gestire il db di portare a termine l\u2019analisi post mortem dell&#8217;istanza mongodb fallita abbiamo implementato un <strong>sistema di self-healing per mongodb<\/strong> in grado di ricreare automaticamente un istanza identica a quella non pi\u00f9 raggiungibile e riconfigurare il replica set per usare la nuova EC2 al posto di quella corrotta.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Gli strumenti di AWS utilizzati per implementare \u00a0questa soluzione sono i seguenti:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>Autoscaling group:<\/strong> un servizio di AWS per gestire e scalare gruppi di istanze; \u00e8 possibile definire il tipo di istanza da utilizzare e il numero di istanze desiderate e AWS si occuper\u00e0 di lanciarle, monitorare lo status e se necessario terminarle e lanciarne di nuove.<\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>Route 53:<\/strong> il servizio DNS di AWS<\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>Lambda Functions:<\/strong> Funzioni serverless che possono essere lanciate su AWS come risposta \u00a0all\u2019attivazione di un trigger oppure con una cadenza definita usando AWS CloudWatch<\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>SQS Queues:<\/strong> Code di messaggi in alta affidabilit\u00e0 gestite da AWS. <\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>AWS CodeDeploy:<\/strong> Servizio gestito di AWS per il deploy di codice arbitrario tramite un agent installato sulle macchine, si integra con gli autoscaling group: il deploy viene eseguito nel momento in cui una nuova istanza viene avviata<\/span><\/li>\n<\/ul>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-416 aligncenter\" src=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft.png\" alt=\"\" width=\"3840\" height=\"2160\" srcset=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft.png 3840w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft-400x225.png 400w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft-1024x576.png 1024w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft-768x432.png 768w, https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/cloudcraft-1536x864.png 1536w\" sizes=\"(max-width: 3840px) 100vw, 3840px\" \/><\/p>\n<h2><span style=\"font-weight: 400;\">Creazione del Replica Set<\/span><\/h2>\n<p><span style=\"font-weight: 300;\">Per procedere nella <strong>creazione del Replica set con self healing<\/strong> \u00e8 innanzi tutto necessario creare un AMI di base per le macchine del replica set con tutti i pacchetti necessari installati: \u00a0AWSCLI, Chrony, Ruby e ovviamente MongoDB (master e client) nella <a href=\"https:\/\/docs.mongodb.com\/manual\/installation\/\">versione desiderata<\/a>\u00a0\u00e8 inoltre necessario istallare il <a href=\"https:\/\/docs.aws.amazon.com\/codedeploy\/latest\/userguide\/codedeploy-agent-operations-install.html\"><strong>CodeDeploy agent.<\/strong><\/a><\/span><\/p>\n<p><span style=\"font-weight: 300;\">Per configurare il replica set \u00e8 necessario creare un <strong>keyfile<\/strong> che deve essere presente su tutte le macchine cluster e che mongo utilizza per autenticare le connessioni dell\u2019 heartbeat. Il file deve contenere caratteri alfanumerici generati in modo pseudo-random e pu\u00f2 essere creato col comando <\/span><\/p>\n<pre><span style=\"font-weight: 400;\">openssl rand -base64 756 &gt; &lt;path-to-keyfile&gt;<\/span>\r\n<span style=\"font-weight: 400;\">chmod 400 &lt;path-to-keyfile&gt;<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">Il keyfile \u00e8 una forma minimale di sicurezza ed \u00e8 accettabile solo su una rete sicura (subnet private in VPC), per l\u2019ambiente di produzione \u00e8 comunque preferibile usare un certificato x.509. Il file di configurazione di MongoDB sar\u00e0 simile al seguente:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">storage:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0dbPath: \/mnt\/mongo\/data<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0journal:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0enabled: true<\/span>\r\n\r\n<span style=\"font-weight: 400;\">systemLog:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0destination: file<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0logAppend: true<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0path: &lt;logs-path&gt;<\/span>\r\n\r\n<span style=\"font-weight: 400;\">security:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0keyFile: &lt;keyfile-path&gt;\r\n<\/span>\r\n<span style=\"font-weight: 400;\">replication:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0replSetName: test-rs<\/span>\r\n\r\n<span style=\"font-weight: 400;\">net:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0port: 27017<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0bindIpAll: true<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">La creazione iniziale del cluster MongoDB pu\u00f2 essere completamente automatizzata usando <strong>CloudFormation<\/strong>, oppure pu\u00f2 essere eseguita manualmente utilizzando l\u2019ami appena creata e uno script di configurazione da eseguire sulle singole macchine del cluster.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Una delle macchine va configurata inizialmente per essere il master e inizializzare il Replica Set. Per fare ci\u00f2 \u00e8 necessario prima avviare Mongo senza i campi security e replication nel file di configurazione e poi creare un utente admin col comando:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">db.createUser({user: \"&lt;ADMIN_USER&gt;\", pwd: \"&lt;PWD&gt;\", roles:[{role: \"root\", db: \"admin\"}]});<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">A questo punto Mongo va riavviato col file di configurazione contenente security e replication. <\/span><\/p>\n<p><span style=\"font-weight: 300;\">Dopo aver acceso anche le altre macchine, che inizialmente saranno repliche, \u00e8 necessario creare degli <em>A name<\/em> su una private hosted zone di R53 per tutte le macchine del replica set. Nelle configurazioni della VPC \u00e8 inoltre necessario selezionare le opzioni enableDnsHostnames e enableDnsSupport per attivare la risoluzione dei DNS interni di R53.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Fatto ci\u00f2 \u00e8 finalmente possibile connettersi in SSH al master e tramite la cli di mongo attivare il replica set col comando:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">rs.initiate( {<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0_id : \"test-mongo-rs\",<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0members: [<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0{ _id: 0, host: \"mongodb-1.test.it:27017\" },<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0{ _id: 1, host: \"mongodb-2.test.it:27017\" },<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0{ _id: 2, host: \"mongodb-3.test.it:27017\" }<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0]<\/span>\r\n<span style=\"font-weight: 400;\">});<\/span>\r\n<\/pre>\n<p><span style=\"font-weight: 400;\">Ora\u00a0che il Replica Set \u00e8 configurato e funzionante \u00e8 giunto il momento di occuparci della parte di self healing.<br \/>\n<\/span><\/p>\n<h2><span style=\"font-weight: 400;\">Set up del Self Healing<\/span><\/h2>\n<p><span style=\"font-weight: 300;\">Per configurare il selfhealing \u00e8 innanzitutto necessario <strong>registrare le macchine ad un autoscaling group con healthcheck di tipo EC2 e numero di macchine fisso<\/strong> (Max: 3, Min: 3 e Desired: 3). In questo modo in caso di fallimento di una macchina AWS provveder\u00e0 a creare una nuova istanza partendo da un AMI definita nel Launch template dell\u2019Autoscaling Group. Lo step successivo \u00e8 la creazione di una funzione Lambda che funzioni da \u201chelthcheck\u201d per le macchine del Replica Set. Nel nostro caso si \u00e8 scelto di creare una lambda in python con Pymongo installato come un <a href=\"https:\/\/docs.aws.amazon.com\/lambda\/latest\/dg\/configuration-layers.html\">Lambda Layer<\/a><\/span><span style=\"font-weight: 300;\">. La funzione Lambda si connette al Replica Set tramite <em>pymongo<\/em> e controlla lo status di tutti i nodi tramite il comando <em>replSetGetStatus<\/em> che ritorna un esploso dello stato del Replica Set:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">import boto3<\/span>\r\n<span style=\"font-weight: 400;\">from pymongo import MongoClient<\/span>\r\n<span style=\"font-weight: 400;\">sqs = boto3.client('sqs')<\/span>\r\n<span style=\"font-weight: 400;\">mongoserver_uri = os.environ['MONGO_URI']<\/span>\r\n<span style=\"font-weight: 400;\">hostzone = os.environ['ZONE_ID']<\/span>\r\n<span style=\"font-weight: 400;\">mongo_connection = MongoClient(mongoserver_uri)<\/span>\r\n<span style=\"font-weight: 400;\">dns_aws = boto3.client('route53')<\/span>\r\n<span style=\"font-weight: 400;\">ec2 = boto3.resource('ec2')<\/span>\r\n\r\n<span style=\"font-weight: 400;\">rs_status = mongo_connection.admin.command('replSetGetStatus')<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">Tutti i nodi non funzionanti avranno <strong>\u201chealth\u201d: 0.<\/strong> Per evitare falsi positivi abbiamo configurato il codice in modo da ripetere il controllo varie volte in un intervallo di tempo di un minuto. Se entro questo intervallo il nodo non ritorna healty la Lambda scrive un messaggio su una coda SQS contenente il DNS name della macchina fallita e un timestamp. <\/span><\/p>\n<p><span style=\"font-weight: 300;\">Fatto questo il codice provveder\u00e0 a de-registrare la macchina fallita dall\u2019Autoscaling Group, se questa non \u00e8 gi\u00e0 stata terminata, utilizzando <em>boto3:<\/em><\/span><\/p>\n<pre><span style=\"font-weight: 400;\">autoscaling = boto3.client('autoscaling')<\/span>\r\n\r\n<span style=\"font-weight: 400;\">response = autoscaling.detach_instances(<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0InstanceIds=[<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0'string',<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0],<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0AutoScalingGroupName='mongo-autoscaling',<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0ShouldDecrementDesiredCapacity=False<\/span>\r\n<span style=\"font-weight: 400;\">)<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">Per evitare esecuzioni multiple la lambda \u00e8 configurata per mandare il messaggio su sqs e deregistrare l\u2019istanza solo se la coda SQS \u00e8 vuota (ApproximateNumberOfMessages = 0)<\/span><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Una volta preparata la lambda \u00e8 il momento dell\u2019ultimo passaggio: la <strong>configurazione di CodeDeploy<\/strong> che ha il compito di configurare le nuove istanze al momento dell\u2019accensione da parte dell\u2019 autoscaling group. Iniziamo col creare una nuova applicazione nella dashboard di CodeDeploy e un nuovo deployment group mettendo come target l\u2019autoscaling group appena creato. CodeDeploy esegue sulla macchina una serie operazioni di script configurabili dall\u2019utente, definite in un file chiamato <em>appspec.yml<\/em> che deve essere salvato in un bucket S3 insieme agli script e ai file che devono essere trasferito e\/o eseguiti sulla macchina.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">La struttura del file \u00e8 la seguente:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">version: 0.0<\/span>\r\n<span style=\"font-weight: 400;\">os: linux<\/span>\r\n<span style=\"font-weight: 400;\">files:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0- source: \/content<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0destination: \/home\/ubuntu<\/span>\r\n\r\n<span style=\"font-weight: 400;\">hooks:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0ApplicationStop:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0- location: scripts\/applicationstop.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0timeout: 300<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0runas: root<\/span>\r\n\r\n<span style=\"font-weight: 400;\"> \u00a0BeforeInstall:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0- location: scripts\/beforeinstall.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0timeout: 300<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0runas: root<\/span>\r\n\r\n<span style=\"font-weight: 400;\">  AfterInstall:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0- location: scripts\/afterinstall.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0timeout: 300<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0runas: root\r\n<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0ApplicationStart:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0- location: scripts\/applicationstart.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0timeout: 300<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0runas: root<\/span>\r\n\r\n<span style=\"font-weight: 400;\"> \u00a0ValidateService:<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0- location: scripts\/validateservice.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0timeout: 300<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0\u00a0\u00a0runas: root<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">La struttura della cartella da caricare su s3 \u00e8 la seguente e da utilizzare come input di codedeploy \u00e8 la seguente:<\/span><\/p>\n<pre><span style=\"font-weight: 400;\">content\/<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0mongod.conf<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0mongo-keyfile<\/span>\r\n<span style=\"font-weight: 400;\">scripts\/<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0afterinstall.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0applicationstart.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0applicationstop.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0beforeinstall.sh<\/span>\r\n<span style=\"font-weight: 400;\"> \u00a0\u00a0\u00a0validateservice.sh<\/span><\/pre>\n<p><span style=\"font-weight: 300;\">Nel nostro caso la cartella content contiene il keyfile e il file di configurazione di Mongo mentre la cartella scripts contiene gli script bash che si occupano di configurare la nuova istanza. In particolare gli script devono leggere dalla coda SQS il messaggio contenente il DNS name della macchina fallita, configurare Mongo sulla macchina appena accesa, tramite la CLI di MongoDB riconfigurare il Replica Set per usare il nuovo nodo e quindi avviare il servizio di mongo.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Non appena un&#8217;istanza fallisce (oppure il processo di mongo diventa unresponsive) si innesca dunque la seguente catena di eventi:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>La lambda di helthcheck rileva il nodo come unhealthy<\/strong>, esegue il detach della macchina dall\u2019 autoscaling group e scrive un messaggio su una coda sqs contenente il dns name del nodo fallito.<\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>L\u2019autoscaling group reagisce all\u2019assenza di una macchina<\/strong> avviando una nuova EC2.<\/span><\/li>\n<li style=\"font-weight: 300;\"><span style=\"font-weight: 300;\"><strong>CodeDeploy esegue gli script di configurazione<\/strong> salvati su S3 che configurano la nuova macchina in modo da farle prendere il posto di quella fallita.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 300;\">A questo punto MongoDB inizia a replicare i dati sulla nuova macchina, tuttavia questa operazione per database grandi pu\u00f2 richiedere diverse ore. Per evitare questo problema conviene <strong>configurare MongoDB per salvare i dati su uno specifico EBS<\/strong> e durante la creazione della nuova istanza smontare l\u2019EBS in questione dall\u2019istanza fallita e fare il mount sull\u2019istanza appena creata.<\/span><\/p>\n<p><span style=\"font-weight: 300;\">Una volta concluse tutte questa configurazioni avremo finalmente il nostro <strong>replica set in alta affidabilit\u00e0 e con automatic self-healing!<\/strong><\/span><\/p>\n<p><span style=\"font-weight: 300;\">Volete condividere con noi le vostre osservazioni, i vostri dubbi, i vostri spunti oppure volete una mano per creare una configurazione come questa? \u2026 il nostro team non vede l\u2019ora di approfondire il topic con voi!<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>MongoDB \u00e8 un database NOSQL documentale immediato da configurare e da utilizzare e sta avendo una grandissima diffusione nei nuovi [&hellip;]<\/p>\n","protected":false},"author":9,"featured_media":415,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[481],"tags":[343],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v21.9.1 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS - Proud2beCloud Blog<\/title>\n<meta name=\"description\" content=\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/\" \/>\n<meta property=\"og:locale\" content=\"it_IT\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\" \/>\n<meta property=\"og:description\" content=\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/\" \/>\n<meta property=\"og:site_name\" content=\"Proud2beCloud Blog\" \/>\n<meta property=\"article:published_time\" content=\"2019-04-19T13:42:14+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2021-03-17T11:34:27+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/mongodbblog.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1721\" \/>\n\t<meta property=\"og:image:height\" content=\"1290\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Matteo Moroni\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:title\" content=\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\" \/>\n<meta name=\"twitter:description\" content=\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/mongodbblog.png\" \/>\n<meta name=\"twitter:label1\" content=\"Scritto da\" \/>\n\t<meta name=\"twitter:data1\" content=\"Matteo Moroni\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tempo di lettura stimato\" \/>\n\t<meta name=\"twitter:data2\" content=\"9 minuti\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/\",\"url\":\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/\",\"name\":\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS - Proud2beCloud Blog\",\"isPartOf\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\"},\"datePublished\":\"2019-04-19T13:42:14+00:00\",\"dateModified\":\"2021-03-17T11:34:27+00:00\",\"author\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/0b3e69eb2dcb125d58476b906ec1c7bc\"},\"description\":\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/#breadcrumb\"},\"inLanguage\":\"it-IT\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/blog.besharp.it\/it\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#website\",\"url\":\"https:\/\/blog.besharp.it\/it\/\",\"name\":\"Proud2beCloud Blog\",\"description\":\"il blog di beSharp\",\"alternateName\":\"Proud2beCloud Blog\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.besharp.it\/it\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"it-IT\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/0b3e69eb2dcb125d58476b906ec1c7bc\",\"name\":\"Matteo Moroni\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"it-IT\",\"@id\":\"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/acad790b9bb4c6d62e076ecdc1debb35?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/acad790b9bb4c6d62e076ecdc1debb35?s=96&d=mm&r=g\",\"caption\":\"Matteo Moroni\"},\"description\":\"DevOps e Solution Architect di beSharp, mi occupo di sviluppare soluzioni Saas, Data Analysis, HPC e di progettare architetture non convenzionali a complessit\u00e0 divergente. Appassionato di informatica e fisica, da sempre lavoro nella prima e ho un PhD nella seconda. Parlare di tutto ci\u00f2 che \u00e8 tecnico e nerd mi rende felice!\",\"url\":\"https:\/\/blog.besharp.it\/it\/author\/matteo-moroni\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS - Proud2beCloud Blog","description":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/","og_locale":"it_IT","og_type":"article","og_title":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","og_description":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","og_url":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/","og_site_name":"Proud2beCloud Blog","article_published_time":"2019-04-19T13:42:14+00:00","article_modified_time":"2021-03-17T11:34:27+00:00","og_image":[{"width":1721,"height":1290,"url":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/mongodbblog.png","type":"image\/png"}],"author":"Matteo Moroni","twitter_card":"summary_large_image","twitter_title":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","twitter_description":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","twitter_image":"https:\/\/blog.besharp.it\/wp-content\/uploads\/2019\/04\/mongodbblog.png","twitter_misc":{"Scritto da":"Matteo Moroni","Tempo di lettura stimato":"9 minuti"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/","url":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/","name":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS - Proud2beCloud Blog","isPartOf":{"@id":"https:\/\/blog.besharp.it\/it\/#website"},"datePublished":"2019-04-19T13:42:14+00:00","dateModified":"2021-03-17T11:34:27+00:00","author":{"@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/0b3e69eb2dcb125d58476b906ec1c7bc"},"description":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS","breadcrumb":{"@id":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/#breadcrumb"},"inLanguage":"it-IT","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.besharp.it\/it\/come-creare-un-replicaset-di-mongodb-con-self-healing-usando-i-servizi-di-aws\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/blog.besharp.it\/it\/"},{"@type":"ListItem","position":2,"name":"Come creare un ReplicaSet di MongoDB con Self-Healing usando i servizi di AWS"}]},{"@type":"WebSite","@id":"https:\/\/blog.besharp.it\/it\/#website","url":"https:\/\/blog.besharp.it\/it\/","name":"Proud2beCloud Blog","description":"il blog di beSharp","alternateName":"Proud2beCloud Blog","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.besharp.it\/it\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"it-IT"},{"@type":"Person","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/0b3e69eb2dcb125d58476b906ec1c7bc","name":"Matteo Moroni","image":{"@type":"ImageObject","inLanguage":"it-IT","@id":"https:\/\/blog.besharp.it\/it\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/acad790b9bb4c6d62e076ecdc1debb35?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/acad790b9bb4c6d62e076ecdc1debb35?s=96&d=mm&r=g","caption":"Matteo Moroni"},"description":"DevOps e Solution Architect di beSharp, mi occupo di sviluppare soluzioni Saas, Data Analysis, HPC e di progettare architetture non convenzionali a complessit\u00e0 divergente. Appassionato di informatica e fisica, da sempre lavoro nella prima e ho un PhD nella seconda. Parlare di tutto ci\u00f2 che \u00e8 tecnico e nerd mi rende felice!","url":"https:\/\/blog.besharp.it\/it\/author\/matteo-moroni\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/412"}],"collection":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/comments?post=412"}],"version-history":[{"count":0,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/posts\/412\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media\/415"}],"wp:attachment":[{"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/media?parent=412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/categories?post=412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.besharp.it\/it\/wp-json\/wp\/v2\/tags?post=412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}