Skip to main content

how to change Vertica DB node IP to use different subnet

let's say for example that you have 3 Vertica nodes and the inteconnect communication subnet was 10.0.0.X
now for some reason you want to change the internal communication between the nodes to use another interface using this subnet:  192.168.1.X

please follow these step by step guide in order to accomplish this target:

-----------------------------------------------------------------


first change network from to use point-to-point mode

1.
select set_control_mode('pt2pt');
select reload_spread(true);

Check in the catalog directory if spread.conf got modified to broadcast mode.

2. Edit admintools.conf  controlmode

controlmode = pt2pt

3. Use admintools to distribute database configuration and metadata to all cluster nodes

4. In order to make spread adjust new configuration you need to restart Vertica DB


for each Vertica node run these steps to change IP used by interconnect

1. Stop Vertica on node

2.  Change hostname through vsql :

alter node <node_name> is hostname '<New IP address>' control hostname '<new IP address of spread> ' broadcast '<broadcast address of spread>';
select reload_spread(true);

alter node v_db_node0001 is hostname '192.168.1.5' control hostname '192.168.1.5 ' broadcast '192.168.1.255';
select reload_spread('true');

3. replace old IP address with new IP address in admintools.conf

4. Use admintools to distribute database configuration and metadata to all cluster nodes

5. On the node that is down run:
/opt/vertica/spread/bin/spmonitor -c spread.conf
select 'r' to reload the spread config
this action will reload the spread config


6. Restart Vertica on the node.

7. Once the node joins the cluster move to the next node


Comments

Popular posts from this blog

ORA-27104: system-defined limits for shared memory was misconfigured

I faced this error while trying to restore & recover of a PDB (pluggable database) part of the log file and the solution is described here below: log: initialization parameters used for automatic instance: db_name=CDB db_unique_name=gbux_pitr_PDB1_CDB compatible=12.1.0.2.0 db_block_size=8192 db_files=200 diagnostic_dest=/oracle/app/oracle _system_trig_enabled=FALSE sga_target=1888M processes=200 db_create_file_dest=/oracle/auxilary log_archive_dest_1='location=/oracle/auxilary' enable_pluggable_database=true _clone_one_pdb_recovery=true #No auxiliary parameter file used starting up automatic instance CDB RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 07/31/2016 16:22:20 RMAN-04014: startup failed: ORA-27104: system-defined limits for shared...

ora-65035 while create pluggable database from another one

or : ORA-21000: error number argument to raise_application_error of -65035 is out of range Cause: this error caused because of an unrecoverable transaction in the source DB. Solution: 1. either stop and start your pluggable source DB 2. identify the open transaction and kill it if you can. use this query to do so: select * from v$transaction t,v$session  s where t.ses_addr = s.saddr;

KUP-04074: no write access to directory when trying to query EXTERNAL table

Hi All, You may think that in order to query external table you should have only read permission on the Directory Object which sounds very reasonable.... but in some external table the definition include this part of code: ACCESS PARAMETERS         ( records delimited by newline           LOGFILE   "EXTERNAL_FILES" : 'faults.txt'       FIELDS TERMINATED BY ';'             missing FIELD values are null this definition force a write permission on the directory object.  else you will run into this error: ORA-29913: error in executing ODCIEXTTABLEOPEN callout ORA-29400: data cartridge error KUP-04074: no write access to directory object EXTERNAL_FILES 29913. 00000 -  "error in executing %s callout" *Cause:    The execution of the specified callout caused an error. *Acti...