Tianjin ntu general gbase 8 a MPP database architecture introduces more divided since the 86 version, mainly to solve the old version 85 single physical shard, when a host is down, another copy of the host took on a double tasks, performance degradation is too large, according to the project experience, usually equipped with a host two shard optimal, both down a node, will not affect down significantly, also won't because the shard caused storing files too much, increase the management cost, and fragmentation and distribution rule of physical host, through gcChangeInfo. To define the XML file, then through gcadmin distribution command,
If there is such A scenario, A total of 24 host, respectively, in A, B, C, D on the rack, using 2 shard, I hope each subdivision of the shard picture with the main fragmentation is not on A rack, to avoid the failure in the cabinet, will not result in A cluster is not available, how to implement?
Method is as follows: through our gcChangeInfo. XML file, configure the virtual machine frame, the distribution of the host's IP to fill in each rack, the rack can be without and the number of actual frame one-to-one correspondence, but to make every host take number is consistent, the distribution of the number of each rack to maintain consistent, then make sure that each rack or under the IP, not in a physical frame, are as follows:
Physical host distribution
A B C D
192.168.16.1 192.168.17.1 192.168.18.1 192.168.19.1
192.168.16.2 192.168.17.2 192.168.18.2 192.168.19.2
192.168.16.3 192.168.17.3 192.168.18.3 192.168.19.3
192.168.16.4 192.168.17.4 192.168.18.4 192.168.19.4
192.168.16.5 192.168.17.5 192.168.18.5
192.168.16.6 192.168.17.6 192.168.18.6
192.168.16.7 192.168.17.7
Rack distribution:
Rack1 rack2 rack3 rack4 rack5 rack6
192.168.16.1 192.168.17.1 192.168.18.1 192.168.19.1 192.168.16.5 192.168.17.5
192.168.16.2 192.168.17.2 192.168.18.2 192.168.19.2 192.168.16.6 192.168.17.6
192.168.16.3 192.168.17.3 192.168.18.3 192.168.19.3 192.168.16.7 192.168.17.7
192.168.16.4 192.168.17.4 192.168.18.4 192.168.19.4 192.168.18.6 192.168.18.5
Then used gcadmin distribution gcChangeInfo. XML p 2 d 1 db_root_pwd XXXX generate new distribution ID, finally, to rebalance redistribution,
