# Procedura per ridimensionare un nodo validatore I nodi di una chain hanno il problema che il database contentente lo stato e le transazioni continuerà a crescere. Per questo è necessario e possibile, a seconda delle esigenze, procedere a un ridimensionamento del nodo. Nel caso di nodi validatori è possibile procedere alla creazione di un nuovo nodo eseguendo una sincronizzazione utilizzando il meccanismo dello statesync. Di seguito i passaggi salienti, descritti poi più in dettaglio 1. Creare un nuovo nodo (semplice, non validatore) utilizzando il meccanismo dello statesync 2. Attendere che il nodo si allinei alla rete. 3. Spegnere il nodo validatore attuale. Togliere autostart dei servizi ed eventualmente la chiave privata del validatore se presente come file all'interno del nodo. Se si fa uso di un **kms** fare in modo che il quest'ultimo non si connetta più al nodo validatore. 4. Attendere un minuto per essere sicuri che il nuovo nodo sia ad un'altezza più elevata del precedente validatore. A questo punto spegnere il servizio della chain sul nuovo nodo. 5. Spostare la chiave privata del validatore sul nuovo nodo e sostituirla con quelle presente. Nel caso di **kms** far puntare quest'ultimo al nuovo nodo. 6. Far ripartire il servizio del nodo. Il validatore dovrebbe ritornare quasi immediatamente on-line. Il database dovrebbe quindi occupare poco spazio, consentendo un certo periodo di esercizio senza problemi. 7. La procedura può essere poi ripetuta quando il nodo sarà nuovamente saturo. ## Dettaglio ### Creazione nuovo nodo con state sync Seguire le istruzioni riportate su https://docs.commercio.network/nodes/full-node-installation.html Fermarsi prima del punto [5. Sync node](https://docs.commercio.network/nodes/full-node-installation.html#_5-sync-node) Applicare la seguente procedura: eseguire i seguenti comandi ```bash TRUST_RPC1="rpc-mainnet.commercio.network:80" TRUST_RPC2="rpc2-mainnet.commercio.network:80" CURR_HEIGHT=$(curl -s "http://$TRUST_RPC1/block" | jq -r '.result.block.header.height') TRUST_HEIGHT=$((CURR_HEIGHT-(CURR_HEIGHT%10000))) TRUST_HASH=$(curl -s "http://$TRUST_RPC1/block?height=$TRUST_HEIGHT" | jq -r '.result.block_id.hash') # CONFIG OUTPUT printf "\n\nenable = true\nrpc_servers = \"$TRUST_RPC1,$TRUST_RPC2\"\ntrust_height = $TRUST_HEIGHT\ntrust_hash = \"$TRUST_HASH\"\ntrust_period = \"168h0m0s\"\n\n" ``` L'output dovrà essere inserito nel file `config.toml` nella sezione [statesync]. La configurazione del file dovrebbe risultare qualcosa di **simile** (non uguale perché i dati di altezza e hash continuano a variare nel tempo) al seguente ```toml [statesync] enable = true rpc_servers = "rpc-mainnet.commercio.network:80,rpc2-mainnet.commercio.network:80" trust_height = 6240000 trust_hash = "FCA27CBCAC3EECAEEBC3FFBB5B5433A421EF4EA873EB2A573719B0AA5093EF4C" trust_period = "168h0m0s" # # Time to spend discovering snapshots before initiating a restore. discovery_time = "15s" ``` A questo punto si può procedere avviando il servizio e verificando che il nodo si allinei alla chain. **NB**: Si consiglia sempre di installare il nodo utilizzando [Cosmovisor](https://docs.commercio.network/nodes/full-node-installation.html#install-and-config-cosmovisor) ### Gestione nodo validatore `SENZA KMS` Sul nodo validatore attuale fermate il servizio ```bash systemctl stop commercionetworkd ``` Assicuratevi che il servizio sia completamente fermo ```bash journalctl -u commercionetworkd -f ``` A questo salvate la chiave privata del vostro validatore che si dovrebbe trovare in ```bash $HOME/.commercionetwork/config/priv_validator_key.json ``` **NB: la posizione della chiave dipende dal vostro ambiente. Generalmente si trova nella posizione indicata, ma potrebbe essere in altre posizioni.** La chiave dovrebbe già essere stata salvata precedentemente, ma assicuratevi comunque di averla. Fate in modo che il validatore non abbia più accesso alla chiave ```bash mv \ $HOME/.commercionetwork/config/priv_validator_key.json \ $HOME/.commercionetwork/config/priv_validator_key.json.ko ``` Disabilitare inoltre il servizio in modo che non ci sia il pericolo che riparta in automatico per un riavvio imprevisto del server e verificate che sia appunto disabilitato ```bash systemctl disable commercionetworkd systemctl is-enabled commercionetworkd ``` ### Gestione nodo validatore `CON KMS` Sul nodo validatore attuale fermate il servizio ```bash systemctl stop commercionetworkd ``` Assicuratevi che il servizio sia completamente fermo ```bash journalctl -u commercionetworkd -f ``` Accedete al vostro **kms** e fermate il servizio **tmkms**. Assicuratevi che il servizio **tmkms** sia disabilitato. ```bash systemctl stop tmkms systemctl disable tmkms systemctl is-enabled tmkms ``` **NB: Il nome sel servizio e i suoi file di configurazione dipendono dal vostro ambiente.** Disabilitare il servizio sul nodo validatore in modo che non ci sia il pericolo che riparta in automatico per un riavvio imprevisto del server e verificate che sia appunto disabilitato ```bash systemctl disable commercionetworkd systemctl is-enabled commercionetworkd ``` ### Spostamento nodo validatore su nuovo nodo `SENZA KMS` Sul nuovo nodo allineato fermate il servizio della chain ```bash systemctl stop commercionetworkd ``` Assicuratevi che il servizio sia completamente fermo ```bash journalctl -u commercionetworkd -f ``` Sostituite la chiave private con la chiave privata del validatore ```bash cp \ ~/priv_validator_key.json.saved \ $HOME/.commercionetwork/config/priv_validator_key.json ``` **`priv_validator_key.json.saved` è la chiave che avete salvato del precedente validatore. Il trasferimento sul nuovo nodo può essere fatto in qualsiasi maniera riteniate opportuna e quindi potete anche editare il file `$HOME/.commercionetwork/config/priv_validator_key.json` copiando e incollando il contenuto della chiave** Specifichiamo in questa fase che non possiamo arrivare al punto di scrivere cosa dovete fare per spostare un file da un vostro server a un altro vostro server. Questo dovrebbe essere una conoscenza già acquisita. A questo punto potete avviare il servizio sul nuovo nodo, che adesso dovrebbe essere diventato il vostro validatore ```bash systemctl start commercionetworkd systemctl enable commercionetworkd ``` Controllate sull'explorer se il nodo validatore ha ricominciato a validare. ### Spostamento nodo validatore su nuovo nodo `CON KMS` Sul nuovo nodo allineato fermate il servizio della chain ```bash systemctl stop commercionetworkd ``` Assicuratevi che il servizio sia completamente fermo ```bash journalctl -u commercionetworkd -f ``` Nella configurazione `$HOME/.commercionetwork/config/config.toml` cambiate la configurazione come segue ```toml priv_validator_laddr = "tcp://IP_VALIDATOR:26658" ``` Dove `IP_VALIDATOR` è **l'ip del validatore** a cui ha accesso il **kms*. Se il **kms** contatta il validatore attraverso VPN allora `IP_VALIDATOR` sarà l'ip del validatore sulla VPN. Generalmente sono ip del tipo 10.x.x.x, ossia di una subnet LAN. Sul **kms** modificate le configurazioni del servizio **tmkms** nella sezione `[[validator]]` in questa maniera ```toml [[validator]] addr = "tcp://IP_VALIDATOR:26658" #ip del Validator Node ``` La posizione del file di configurazione dipende sempre dal vostro ambiente. `IP_VALIDATOR` è **l'ip del validatore** a cui ha accesso il **kms**. Lo stesso utilizzato sul nodo validatore. A questo punto avviate il servizio **tmkms** e abilitatelo. Inizialmente dai logs dovrebbe risultare una irraggiungibilità del nodo validatore, ma questo è corretto dato che il servizio del nodo in questo momento è spento. ```bash systemctl start tmkms systemctl enable tmkms journalctl -u tmkms -f ``` Sul nuovo nodo attivate il servizio della chain e abilitatelo ```bash systemctl start commercionetworkd systemctl enable commercionetworkd ``` Controllate sull'explorer se il nodo validatore ha ricominciato a validare. Il nuovo nodo è diventato validatore. ### Post mortem e verifiche Quando il nuovo nodo è attivo e sta validando eliminate il validatore precedente, cancellando qualsiasi traccia della chiave privata su di esso e il server stesso. Nel caso qualcosa non funzionasse provate a rifare la procedura di installazione del nodo e a installare nuovamente le chiavi. Se ancora le cose non funzionano chiedete nella community aiuto. Generalmente questi sono i principali problemi che potreste avere 1. La chiave del validatore che avete trasportato non è quella del validatore: a volte le persone confondono chiave del proprio wallet con quella del validatore (non so come sia possibile). 2. La chiave trasportata viene messa su una posizione sbagliata: come scritto gli ambienti di installazione non sono tutti uguali, quindi dovete essere ben consapevoli di dove siano collocati configurazioni e file 3. Nel caso di **kms** alcuni pensano di dover mettere nel validatore l'ip del kms e sul kms l'ip del validatore o viceversa. **NO**: in entrambe le macchine va messo l'ip del validatore. 4. Il **kms** non raggiunge il validatore: controllate le vostre configurazioni di rete. Può esserci un firewall o la vpn non è configurata correttamente. Naturalmente tutto il setup di una vpn tra kms e nodo viene omessa, perché non riguarda questa procedura, ma piuttosto il setup della vostra configurazione di rete, di cui questa guida **non deve e non può trattare**. ### Se vi piace il rischio e siete "bravi" Potete eseguire la procedura anche sul nodo stesso: 1. Fermate il nodo 2. Resettate tutto 3. Create nuove chiavi e le sostituite a quelle del validatore sul nodo o togliete il servizio che è in ascolto del **kms** 4. Fate partire il nodo con lo statesync 5. Aspettate che si allinei 6. Fermate il servizio del nodo e rimettete le chiavi del validatore o riabilitate il servizio per il **kms** 7. Fate partire il servizio 8. Il validaotore dovrebbe tornare on-line Naturalmente questa è una procedura che può essere fatta solo se sapete cosa state facendo, e potrebbe anche portare, se non state attenti, al double sign del vostro nodo. ### L'altra faccia della medaglia Il "prezzo" da pagare eseguendo questa procedura è che il nodo non "ricorderà" nessuna transazione precedente al momento in cui avete eseguito lo statesync e nessuno stato. Quindi se il vostro nodo è utilizzato per essere interrogato per le transazioni dovete considerare che questa procedura non è adatta.