Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

GBase8s HAC cluster configuration method

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

Highly available cluster configuration method for GBase8s disaster preparedness in the same city

Tips:

There can be at most one intra-city disaster recovery node in a highly available GBase8s intra-city disaster recovery cluster. The replication technology between nodes is based on logical logs, so the database needs to turn on log mode.

The following prerequisites need to be met to build a cluster:

The database version of each node server is exactly the same

The hardware and operating system versions of each node server are basically the same.

All replicated databases must be log enabled

L the installation path of the instance remains consistent

Suggestion: the hardware platform and operating system of each node server are exactly the same.

two。

3.

1. Database parameter configuration

one

two

three

3.1

1) modify the sqlhosts file so that the master-slave sqlhost file contains the connection information of the master-slave instance, respectively.

[master:]

[root@redhat25 hac _ 54] # cat etc/sqlhosts.ol_ hac _ pri

Ol_ hac onsoctcp 192.168.152.26 23697

Ol_ hac _ pri onsoctcp 192.168.152.25 15723

Dr_ hac _ pri drsoctcp redhat25 dr_ hac _ pri

Lo_ hac _ pri onsoctcp 127.0.0.1 lo_ hac _ pri

[auxiliary:]

[root@redhat26 hac _ 54] # cat etc/sqlhosts.ol_ hac

Ol_ hac _ pri onsoctcp 192.168.152.25 15723

Ol_ hac onsoctcp 192.168.152.26 23697

Dr_ hac drsoctcp redhat26 dr_ hac

Lo_ hac onsoctcp 127.0.0.1 lo_ hac

2) the parameters of the two servers for R OOT D BS pace must be the same

ROOTNAME rootdbs

ROOTPATH / home/ hac _ 54/storage/rootdbs

ROOTOFFSET 0

ROOTSIZE 1024000

3) physical / logical log configuration parameters must be the same

PHYSFILE 189440

PLOG_OVERFLOW_PATH $GBASEDBT DIR/tmp

PHYSBUFF 512

LOGFILES 1 8

LOGSIZE 6144

DYNAMIC_LOGS 2

LOGBUFF 256

4) the relevant parameters of hac must be the same

DRAUTO 3 uses CM to manage hac

DRINTERVAL-1 / / synchronous updates

DRTIMEOUT 30 / / this parameter specifies the length of response time for each of the two database server ping processes in the hac pair to wait for each other's TCP/IP transmission. And finally confirmed the communication networks of both sides and all failed, which led to hac.

The maximum waiting time for failure is WAIT_TIME=DRTIMEOUT*4

UPDATABLE_SECONDARY 1 / / disaster recovery node server writable in the same city

5) different parameters

[master:]

SERVERNUM 100

DBSERVERNAME ol_ hac _ pri

[auxiliary:]

SERVERNUM 1 71

DBSERVERNAME ol_ hac

two。 Configure hac

1) when the node is in online state, execute onmode-d primary ol_ hac

This action makes it the host, and after successful execution, check that the current state of the node is On-Line.

2) complete level 0 on the node: ontape-s-L 0, and remotely transfer the folder under the backup path to the backup path of the disaster recovery node in the same city. Folder name: HOSTNAME_SERVERNUM_L0 (redhat25_1 00 _ L0)

3) under the backup path of the disaster recovery node in the same city, modify the folder name to native hostname and instance num:

[root@redhat26 hac _ 54] # mv backups/redhat25_1 00 _ L0 backups/redhat26_ 171 _ L0

[root@redhat26 hac _ 54] # chown gbasedbt:gbasedbt backups/redhat26_ 171 _ L0

[root@redhat26 hac _ 54] # chmod 660 backups/redhat26_ 171 _ L0

4) disable the disaster recovery node service in the same city: onmode-ky

5) perform ontape-p for physical recovery. At the end of the trip, the secondary node status is Fast Recovery

6) execute onmode-d secondary ol_ hac _ pri on the disaster recovery node in the same city

The state of the auxiliary machine changes to Fast Recovery (Sec). Wait a moment, the state of the auxiliary machine changes to Updatable (Sec).

Note: if the node configuration parameter UPDATABLE_SECONDARY is 1, the disaster recovery node in the same city is in Updatable (Sec) status; if UPDATABLE_SECONDARY is 0, the node is in READ-ONLY (Sec) status

7) execute onstat-g dri on the node to check its status On-Line, and you can also see the information of disaster recovery nodes in the same city in Server information:

3. Testing and monitoring

1) Test:

Create a database hac with log on the node, create table hac _ 1 and insert data, and view it on the disaster recovery node in the same city, you can successfully view the table data.

2) Monitoring, execute onstat-g h dr verbose on the main and auxiliary machines respectively, and monitor its running status

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report