In some specific cases the bit map of the node_dependencies is not in order as you expect. It was related when nodes were added to the cluster or fault groups, I can remember specific but were very rare cases. Because of that in the latest Vertica version we added the node name reference to the bit maps in the get_node_dependencies function. Like this:
Yes, trust the table. The dependencies values are the same in both output the difference is that in get_node_dependencies the sixth column of the node bit map is not vertica vs_dbname_node0006, it is vertica node 6 but not necessarily the vertica vs_dbname_node0006.
To make more sense, sometimes I used the below function to match the node names with the node order.
If you are using get_node_dependencies(), please note that rightmost bit is not necesarily node0001 but node with lowest oid. Bit's from right to left represent nodes with oid's lowest to highest. Hope this helps .
Hi,
if you have that many nodes, you are an enterprise customer; as this seems to be specific to your use case, it will be better if we work it with a support ticket as we have better forms of communication. Please open a support ticket and we can follow up there.
Arvind,
Can you please check node_type column for these nodes. You have 63 nodes listed above but there are only 60 bits . I think some of your nodes are not permanent .
Comments
Trust the table.
In some specific cases the bit map of the node_dependencies is not in order as you expect. It was related when nodes were added to the cluster or fault groups, I can remember specific but were very rare cases. Because of that in the latest Vertica version we added the node name reference to the bit maps in the get_node_dependencies function. Like this:
emoreno=> select get_node_dependencies();
get_node_dependencies
----------------------------------------------------------------------------------------------------------- Deps:
011 - cnt: 29697
101 - cnt: 29697
110 - cnt: 29697
111 - cnt: 29588
001 - name: v_load_node0001
010 - name: v_load_node0002
100 - name: v_load_node0003
(1 row)
Which version are you using?
Eugenia
Hi Eugenie,
I am using 7.2.3-10.
So we should trust the table?
Could you please share what is difference between output of
1. Function get_node_dependencies and
2. Output of vs_node_dependencies
Yes, trust the table. The dependencies values are the same in both output the difference is that in get_node_dependencies the sixth column of the node bit map is not vertica vs_dbname_node0006, it is vertica node 6 but not necessarily the vertica vs_dbname_node0006.
To make more sense, sometimes I used the below function to match the node names with the node order.
select get_expected_recovery_epoch(); INFO 4544: Recovery Epoch Computation: Node Dependencies: 011 - cnt: 6235 101 - cnt: 6235 110 - cnt: 6235 111 - cnt: 5814 Nodes certainly in the cluster: Node 0(v_vdb_node0001), epoch 3092699 Node 1(v_vdb_node0002), epoch 3092699 Filling more nodes to satisfy node dependencies: Data dependencies fulfilled, remaining nodes LGEs don't matter: Node 2(v_vdb_node0003), epoch 3092699 -- get_expected_recovery_epoch ----------------------------- 3092699 (1 row)If you see in the bottom it has node order and node name, can you share your output ?
Eugenia
If you are using get_node_dependencies(), please note that rightmost bit is not necesarily node0001 but node with lowest oid. Bit's from right to left represent nodes with oid's lowest to highest. Hope this helps .
Hi Shrirang,
Agree with you.
But here in myself case oid is correctly mapped to node name in increasing order so looks something is wrong with get_node_dependencies
Eugenia
Deps:
000000000000000000000000000000000000000000000000000000100001 - cnt: 265
000000000000000000000000000000000000000000000000000001000010 - cnt: 265
000000000000000000000000000000000000000000000000000010000100 - cnt: 265
000000000000000000000000000000000000000000000000000100001000 - cnt: 265
000000000000000000000000000000000000000000000000001000010000 - cnt: 265
000000000000000000000000000000000000000000000000110000000000 - cnt: 265
000000000000000000000000000000000000000000100000000000000010 - cnt: 265
000000000000000000000000000000000000000000100000000000100000 - cnt: 265
000000000000000000000000000000000000000001000000000000000100 - cnt: 265
000000000000000000000000000000000000000001000000000001000000 - cnt: 265
000000000000000000000000000000000000000010000000000000001000 - cnt: 265
000000000000000000000000000000000000000010000000000010000000 - cnt: 265
000000000000000000000000000000000000000100000000000000010000 - cnt: 265
000000000000000000000000000000000000000100000000000100000000 - cnt: 265
000000000000000000000000000000000000001000000000001000000000 - cnt: 265
000000000000000000000000000000000000001000000000100000000000 - cnt: 265
000000000000000000000000000000000000010000000000010000000000 - cnt: 265
000000000000000000000000000000000000010000000001000000000000 - cnt: 265
000000000000000000000000000000000000100000000010000000000000 - cnt: 265
000000000000000000000000000000000001000000000100000000000000 - cnt: 265
000000000000000000000000000000000010000000001000000000000000 - cnt: 265
000000000000000000000000000000000100000000010000000000000000 - cnt: 265
000000000000000000000000000000010000000000000000000000000001 - cnt: 1
000000000000000000000000000000100000000000000001000000000000 - cnt: 265
000000000000000000000000000000100000100000000000000000000000 - cnt: 265
000000000000000000000000000001000000000000000010000000000000 - cnt: 265
000000000000000000000000000001000001000000000000000000000000 - cnt: 265
000000000000000000000000000010000000000000000100000000000000 - cnt: 265
000000000000000000000000000010000010000000000000000000000000 - cnt: 265
000000000000000000000000000100000000000000001000000000000000 - cnt: 265
000000000000000000000000000100000100000000000000000000000000 - cnt: 265
000000000000000000000000001000000000000000010000000000000000 - cnt: 265
000000000000000000000000001000001000000000000000000000000000 - cnt: 265
000000000000000000000000010000010000000000000000000000000000 - cnt: 265
000000000000000000000000100000001000000000000000000000000000 - cnt: 265
000000000000000000000000110000000000000000000000000000000000 - cnt: 265
000000000000000000000001000000010000000000000000000000000000 - cnt: 264
000000000000000000010001000000000000000000000000000000000000 - cnt: 264
000000000000000000100010000000000000000000000000000000000000 - cnt: 264
000000000000000001000100000000000000000000000000000000000000 - cnt: 264
000000000000000010001000000000000000000000000000000000000000 - cnt: 264
000000000000001100000000000000000000000000000000000000000000 - cnt: 264
000000000001010000000000000000000000000000000000000000000000 - cnt: 264
000000000100000000000010000000000000000000000000000000000000 - cnt: 264
000000000100000000010000000000000000000000000000000000000000 - cnt: 264
000000001000000000000100000000000000000000000000000000000000 - cnt: 264
000000001000000000100000000000000000000000000000000000000000 - cnt: 264
000000010000000000001000000000000000000000000000000000000000 - cnt: 264
000000010000000001000000000000000000000000000000000000000000 - cnt: 264
000000100000000010000000000000000000000000000000000000000000 - cnt: 264
000000100000001000000000000000000000000000000000000000000000 - cnt: 264
000001000000000100000000000000000000000000000000000000000000 - cnt: 264
000001000000010000000000000000000000000000000000000000000000 - cnt: 264
000010000000100000000000000000000000000000000000000000000000 - cnt: 264
000010000001000000000000000000000000000000000000000000000000 - cnt: 264
000100000010000000000000000000000000000000000000000000000000 - cnt: 264
001000000000000000000000000000000000000000000000000000000001 - cnt: 264
010000000000100000000000000000000000000000000000000000000000 - cnt: 264
010100000000000000000000000000000000000000000000000000000000 - cnt: 264
100000000010000000000000000000000000000000000000000000000000 - cnt: 264
101000000000000000000000000000000000000000000000000000000000 - cnt: 264
111111111111111111111111111111111111111111111111111111111111 - cnt: 5
(1 row)
dbadmin=> select get_expected_recovery_epoch();
INFO 4544: Recovery Epoch Computation:
Node Dependencies:
000000000000000000000000000000000000000000000000000000100001 - cnt: 265
000000000000000000000000000000000000000000000000000001000010 - cnt: 265
000000000000000000000000000000000000000000000000000010000100 - cnt: 265
000000000000000000000000000000000000000000000000000100001000 - cnt: 265
000000000000000000000000000000000000000000000000001000010000 - cnt: 265
000000000000000000000000000000000000000000000000110000000000 - cnt: 265
000000000000000000000000000000000000000000100000000000000010 - cnt: 265
000000000000000000000000000000000000000000100000000000100000 - cnt: 265
000000000000000000000000000000000000000001000000000000000100 - cnt: 265
000000000000000000000000000000000000000001000000000001000000 - cnt: 265
000000000000000000000000000000000000000010000000000000001000 - cnt: 265
000000000000000000000000000000000000000010000000000010000000 - cnt: 265
000000000000000000000000000000000000000100000000000000010000 - cnt: 265
000000000000000000000000000000000000000100000000000100000000 - cnt: 265
000000000000000000000000000000000000001000000000001000000000 - cnt: 265
000000000000000000000000000000000000001000000000100000000000 - cnt: 265
000000000000000000000000000000000000010000000000010000000000 - cnt: 265
000000000000000000000000000000000000010000000001000000000000 - cnt: 265
000000000000000000000000000000000000100000000010000000000000 - cnt: 265
000000000000000000000000000000000001000000000100000000000000 - cnt: 265
000000000000000000000000000000000010000000001000000000000000 - cnt: 265
000000000000000000000000000000000100000000010000000000000000 - cnt: 265
000000000000000000000000000000010000000000000000000000000001 - cnt: 1
000000000000000000000000000000100000000000000001000000000000 - cnt: 265
000000000000000000000000000000100000100000000000000000000000 - cnt: 265
000000000000000000000000000001000000000000000010000000000000 - cnt: 265
000000000000000000000000000001000001000000000000000000000000 - cnt: 265
0000000000000000000000000000100000000000000001000000000000
get_expected_recovery_epoch
(1 row)
Hi Arvind,
Hi,
if you have that many nodes, you are an enterprise customer; as this seems to be specific to your use case, it will be better if we work it with a support ticket as we have better forms of communication. Please open a support ticket and we can follow up there.
Yes we will open a support case
Arvind , did you open a case wih Vertica support ? Can you please paste output of following query:
select node_name , node_id from nodes order by 2;
-------------------+----------------------
45035996273704980 | node0001
45035996273720704 | node0002
45035996273720708 | node0003
45035996273720712 | node0004
45035996273720716 | node0005
45035996273720720 | node0006
45035996273720724 | node0007
45035996273720728 | node0008
45035996273720732 | node0009
45035996273720736 | node0010
45035996273720740 | node0011
45035996273720744 | node0012
45035996273720748 | node0013
45035996273720752 | node0014
45035996273720756 | node0015
45035996273720760 | node0016
45035996273720764 | node0017
45035996273720768 | node0018
45035996273720772 | node0019
45035996273720776 | node0020
45035996273720780 | node0021
45035996273720784 | node0022
45035996273720788 | node0023
45035996273720792 | node0024
45035996273720796 | node0025
45035996273720800 | node0026
45035996273720804 | node0027
45035996273720808 | node0028
45035996273720812 | node0029
45035996273720816 | node0030
45035996273720820 | node0031
45035996273720824 | node0032
45035996273720828 | node0033
45035996273720832 | node0034
45035996273720836 | node0035
45035996273720840 | node0036
45035996273724596 | node0037
45035996424816626 | node0038
45035996424816630 | node0039
45035996424816634 | node0040
45035996424816638 | node0041
45035996424816642 | node0042
45035996424816646 | node0043
45035996424816650 | node0044
45035996424816654 | node0045
45035996424816658 | node0046
45035996424816662 | node0047
45035996424816666 | node0048
45035996424816670 | node0049
45035996424816674 | node0050
45035996424816678 | node0051
45035996424816682 | node0052
45035996424816686 | node0053
45035996424816690 | node0054
45035996424816694 | node0055
45035996424816698 | node0056
45035996424816702 | node0057
45035996424816706 | node0058
45035996424816710 | node0059
45035996424816714 | node0060
45035996424816718 | node0061
45035996424816722 | node0062
45035996424816726 | node0063
Arvind,
Can you please check node_type column for these nodes. You have 63 nodes listed above but there are only 60 bits . I think some of your nodes are not permanent .
"00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00001 00001"
Please run following query :
select node_name , node_id , node_type from nodes where node_type <> 'PERMANENT';
Arvind ,
Can you please share case number if you opened one for this issue . I am not seeing any info ..