I performed the fail over process;
Shot the Primary in the head,
run sr_failover on Secondary
Moved Virtual IP to Secondary,
Success.
Moved Primary(Original Primary) to new Virtual Private Cloud AWS(Snap shot, launch instance from snap shot in new VPC; Opened all Ports
Updated version 100
Ran Data Sync from third party resource; to "Catch up" , primary and secondary have same data,
global.ini communication listening .global
Shot Secondary(Current Primary) in the head,
Moved Virtual IP to Primary(Original Primary),
Problems;
Hana studio Administration Console showing no data, only maintains REFRESHing state.
CAN see tables, CAN query data.
No cockpit administration, no xs admin
all services running but something was funny on HDB info
usually
\_ /usr/sap/H2D/HDB00/imdbmasterslave/trace/hdb.sapH2D_HDB00 -d -nw -f /usr/sap
h2dadm 3551 3324 0.2 13022284 1597316 \_ hdbnameserver
h2dadm 3963 3324 0.1 2891192 435968 \_ hdbcompileserver
h2dadm 3967 3324 0.1 2817276 453060 \_ hdbpreprocessor
h2dadm 3991 3324 2.9 55411612 52010500 \_ hdbindexserver
h2dadm 3993 3324 0.2 4318588 1175408 \_ hdbscriptserver
h2dadm 3995 3324 2.4 10413092 7480128 \_ hdbxsengine
h2dadm 4693 3324 0.1 3203748 518232 \_ hdbwebdispatcher
But the server in question had the hdbindexserver branching from hdbcompileserver?
Moved Virtual IP back to Seconday.
Attempted process again with Original primary before the snap shot
no success
Current state:
Secondary(Current Primary)
Primary( Original, after snap shot in AWS VPC)
Success.
////////////////////////
So my question is: Is this probably a networking issue? Hana internal routing holding the original private IP used for internal communication during hana install?
I updated /etc/hosts with proper internal ip.
hostname is also the same.
Updated:
global.ini
system_replication_hostname_resolution
Tried; sr_unregister -force
Tried; sr_disable
ERROR: Host has registered slave
Any ideas would be appreciated,
Thank you for your diligence,
Zachary.