IBM DB2 LUW DBA Tutorial -- HADR Setup
/**
声明：此随笔为在youtube上学习‘ IBM DB2 LUW/UDB DBA Tutorial for Beginners' 课程笔记.
YouTube视频连接：https://www.youtube.com/watch?v=Pjvwm4rC5Ok&list=PLCNIKwM6iuv7g1hDWDcNkc66vZuVJmvZg
**/
What is High availability
A high availability solution must:
- Shield user application from the failure w/o appreciable performance degradation, so the user applications are not aware of the failure.
- Respond to the failure to contain its effect. For example: If a m/c fails in a cluster.
- Recover from the failure to return the system to normal operations. For example, if a standby database takes over database operations for a failed primary database, the failed database might restart, recover, and take over once again as the primary database.
High availability (vs) continuous availability
In continuous availability, system is available continuously.
PureScale feature from DB2 10.1
Various things in high available solution:
Redundancy
System monitoring
Load balancing
Failover
Maximizing performance
Minimizing impact on performance
Clustering
Database logging
What is Disaster Recover
Term that refers to activities that need to be done to restore a database in the event of a fire, earthquake, vandalism, or other atastrophic events that lead to a destruction of the complete database server
A plan for disaster recover can include:
A remote site to be used in case of an emergency
A different machine on which to recover the database
Offsite storage of either database backups, table space backups, or both, and archived logs
High availability solutions with DB2
HADR (High availability disaster recovery)
High availability feature (Clustering)
High availability through disk mirroring
High availability through log shipping
Disaster recovery solutions with DB2
Backup and recovery
HADR
Replication (SQL, Q)
Infosphere Change Data Capture(CDC)
Remote disk mirroring
HADR setup
1. Pre requisiters: same db2level output on two database.
2. To give IP address inside VMWARE:
vi /etc/hosts #Add address and name on hosts file, then you can ping it on name
vi /etc/services
3. On primary:
cd /mnt/storage/hadr #same on secondary
mkdir dbpath storage alogs backups #same on secondary
chown dbuser:dbgroup storage backups alogs dbpath #same on secondary
su - dbuser
db2 "create database htest on '/mnt/storage/hadr/storage' DBPATH on '/mnt/storage/hadr/dbpath' "
db2 update db cfg for htest using LOGARCHMETH1 "DISK:/mnt/storage/hadr/alogs"
db2 connect to htest --check if the htest database is under the backup pending state
db2 backup database htest to /dev/null
db2 update db cfg for HTEST using XX_XX_XX xxxxxx #Change configuration on local and remote [Please find the details from screen shot below]
db2 terminate
db2stop; db2start
cd /mnt/storage/hadr/backups
db2 backup database HTEST to /mnt/storage/hadr/backups
scp * db2user@ip:/mnt/storage/hadr/backups
4. On secondary
db2 restore databse htest from /mnt/storage/hadr/backups at back_files
db2 get db cfg for htest | grep -i pending
db2 get db cfg for htest | grep -i hadr
db2 update db cfg for HTEST using XX_XX_XX xxxxxx #Change configuration on local and remote [Please find the details from screen shot below]
db2 terminate
db2stop; db2start
db2 connect to htest -- Check database status
db2 start hadr on database HTEST as standby
db2pd -db htest -hadr
5. Status on both side:
primary:
db2 start hadr on database HTEST as primary
db2pd -db HTEST -dadr
secondary:
db2 connect to HTEST
