(转)测试备库应用主库日志时有无using current logfile选项的区别 [复制链接]

原文 http://www.itpub.net/thread-1810379-1-1.html

测试备库应用主库日志时,alter database recover managed standby database语句中,有无using current logfile选项的区别


一、配置信息
库版本:11.2.0.1
DG保护模式:最大性能
DG配置方式:物理备库 LGWR ASYNC

详细如下:
主库配置信息:
[oracle@db u01]$ sqlplus / as sysdba
–库版本11.2.0.1
SQL*Plus: Release 11.2.0.1.0 Production on Sat Aug 17 13:31:33 2013
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

–主库状态是open
SQL> select status from v$instance;
STATUS
————
OPEN

–主库配置了standby redo
SQL> select group#,thread#,sequence#,status from v$standby_log;
    GROUP#    THREAD#  SEQUENCE# STATUS
———- ———- ———- ———-
         4          0          0 UNASSIGNED
         5          0          0 UNASSIGNED
         6          0          0 UNASSIGNED
         7          0          0 UNASSIGNED

–主库的配置信息
SQL> set lines 200
SQL> col name for a20
SQL> col value for a100
SQL> select name,value from v$parameter where name in (‘log_archive_dest_1′,’log_archive_dest_2’);
NAME                 VALUE
——————– —————————————————————————————————-
log_archive_dest_1   location=/u01/arclog/ valid_for=(all_logfiles,all_roles) db_unique_name=orcl
log_archive_dest_2   service=db2 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=db2

–主库的保护模式及open模式
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE
——————– —————- ——————– ——————–
MAXIMUM PERFORMANCE  PRIMARY          MAXIMUM PERFORMANCE  READ WRITE


备库配置信息:
[oracle@db2 ~]$ sqlplus / as sysdba
–库版本11.2.0.1
SQL*Plus: Release 11.2.0.1.0 Production on Sat Aug 17 13:36:13 2013
Copyright (c) 1982, 2009, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

–备库状态也是open,11g DG的备库是可以open的
SQL> select status from v$instance;
STATUS
————
OPEN

–备库配置了standby redo
SQL> select group#,thread#,sequence#,status from v$standby_log;
    GROUP#    THREAD#  SEQUENCE# STATUS
———- ———- ———- ———-
         4          1         47 ACTIVE
         5          0          0 UNASSIGNED
         6          0          0 UNASSIGNED
         7          0          0 UNASSIGNED

–备库的配置信息
SQL> set lines 200
SQL> col name for a20
SQL> col value for a100
SQL> select name,value from v$parameter where name in (‘log_archive_dest_1′,’log_archive_dest_2’);
NAME                 VALUE
——————– —————————————————————————————————-
log_archive_dest_1   location=/u01/arclog/  valid_for=(all_logfiles,all_roles)  db_unique_name=db2
log_archive_dest_2   service=orcl lgwr async valid_for=(online_logfiles,primary_role)  db_unique_name=orcl

–备库的保护模式及open模式
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE      DATABASE_ROLE    PROTECTION_LEVEL     OPEN_MODE
——————– —————- ——————– ——————–
MAXIMUM PERFORMANCE  PHYSICAL STANDBY MAXIMUM PERFORMANCE  READ ONLY




二、测试备库应用redo时有无using current logfile的区别
1.无using current logfile
备库执行:
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> col name for a50
SQL> col value for a50
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 13:57:07
apply lag                                          +00 00:40:55                                       08/17/2013 13:57:07
apply finish time                                  +00 00:00:05.000
estimated startup time                             22
–查出备库跟主库间有40分钟的应用延迟(我在主库执行alter database recover managed standby database cancel;后,去吃饭了)

主库切换一下redo
SQL> alter system archive log current;
System altered.
再查备库与主库的延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:01:14
apply lag                                          +00 00:00:21                                       08/17/2013 14:01:14
apply finish time                                  +00 00:00:00.001
estimated startup time                             22
–这次apply lag 是21秒了,我觉得主库切换redo后,备库才会应用日志。我们不切换主库redo,等一小会儿,再查备库与主库的应用延迟
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:03:45
apply lag                                          +00 00:02:52                                       08/17/2013 14:03:45
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
–这次成了2份52秒了。
主库切换一下redo,备库马上查看跟主库的应用延迟:
SQL> alter system archive log current;
System altered.
以下备库连查了三次:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:04:53
apply lag                                          +00 00:03:59                                       08/17/2013 14:04:53
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:04:56
apply lag                                          +00 00:04:01                                       08/17/2013 14:04:56
apply finish time                                  +00 00:00:01.000
estimated startup time                             22
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:05:03
apply lag                                          +00 00:00:00                                       08/17/2013 14:05:03
apply finish time                                  +00 00:00:00.000
estimated startup time                             22
在主库切换redo后,备库跟主库的延迟没有立即归零,而是在继续增大,这充分证明了在主库切换归档后(此时备库也产生新归档),备库才会开始应用日志。
如果主库一直不切换redo,备库跟主库的差距会越来越大。

也许视图不能说明什么,我们进行DML操作,模拟下实际应用.
主库建张表:
SQL> create table t (id number);
Table created.
主库切日志:
SQL> alter system archive log current;         
System altered.

主库切日志后,备库能查到新建的表:
SQL> select * from t;
        ID
———-
         0
主库插入数据,并提交
SQL> insert into t values (1);
1 row created.
SQL> commit;
Commit complete.

备库能查数据:
SQL> select * from t;
        ID
———-
         0
SQL> select * from t;
        ID
———-
         0
主库提交后,备库查询若干次,都查不到数据!

再查备库与主库的应用延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:23:59
apply lag                                          +00 00:02:50                                       08/17/2013 14:23:59
apply finish time                                  +00 00:00:00.001
estimated startup time                             22
备库被主库拉开了2分50秒。

主库再切日志:
SQL> alter system archive log current;         
System altered.
备库能查到了:
SQL> select * from t;   
        ID
———-
         1
呵呵,无using current logfile感觉很像是ARCH ASYNC。


2.有using current logfile
备库先退出应用主库日志:
SQL> alter database recover managed standby database cancel;
Database altered.


备库使用using current logfile方式应用主库日志:
SQL> alter database recover managed standby database using current logfile disconnect from session;
Database altered.


检查备库与主库的应用延迟:
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:34:54
apply lag                                          +00 00:00:00                                       08/17/2013 14:34:54
apply finish time                                  +00 00:00:00.000
estimated startup time                             22
没用apply lag,而且一直是没有延迟。
SQL> select name,value,datum_time from v$dataguard_stats;
NAME                                               VALUE                                              DATUM_TIME
————————————————– ————————————————– ——————————
transport lag                                      +00 00:00:00                                       08/17/2013 14:35:00
apply lag                                          +00 00:00:00                                       08/17/2013 14:35:00
apply finish time                                  +00 00:00:00.000
estimated startup time                             22

主库插入数据测试:
SQL> insert into t values (2);
1 row created.
SQL> commit;
Commit complete.

无须等主库切换归档,备库很快就就能查到:
SQL> select * from t;
        ID
———-
         1
         2



三、参考官方文档
关于USING CURRENT LOGFILE官方文档有如下解释:
Specify USING BACKUP CONTROLFILE if you want to use a backup control file instead of the current control file.
–备库的控制文件确实是从主库备份来的。
USING CURRENT LOGFILE Clause Specify USING CURRENT LOGFILE to invoke real-time apply, which recovers redo from the standby redo log files as soon as they are written, without requiring them to be archived first at the physical standby database.
–这句写得很明白,大体意思是:指定USING CURRENT LOGFILE会调用实施应用,它从standby redo中还原信息并尽快写到数据文件中,不需要在备库上先归档。
另外在官方文档上还看到了这句话:
FINISH  Specify FINISH to complete applying all available redo data in preparation for a failover.
所以,在failover时,执行alter database recover managed standby database finish;是有必要的。




四、总结
无using current logfile感觉像下面这张图,主库切换日志后,备库才从归档文件挖掘出变化,然后应用到库文件中。


而using current logfile感觉像下面这张图,备库根据接收到的redo信息,实时应用到备库上,即便是最大性能。



测试应用日志usingcurrent

(转)oracle11g dataguard 备库数据同步的检查方法


本文链接:https://blog.csdn.net/ydwheel/article/details/70124908
概述:

一、环境
     主库:
      ip地址:192.168.122.203
      oracle根目录:/data/db/oracle
      SID:qyq
      数据文件路径/data/db/oracle/oradata/qyq
      归档文件路径:/data/db/oracle/archive’

     备库:
      ip地址:192.168.122.204
      oracle根目录:/data/app/oracle
      SID:qyq
      数据文件路径/data/app/oracle/oradata/qyq
      归档文件路径:/data/app/oracle/archive’

二、备库不同步的问题检查方法

1、检查主备两边的序号
select max(sequence#) from v$log;   —检查发现一致

2、备库执行,查看是否有数据未应用
select name,SEQUENCE#,APPLIED from v$archived_log order by sequence#;

select SEQUENCE#,FIRST_TIME,NEXT_TIME ,APPLIED from v$archived_log order by 1;

3、检查备库是否开启实时应用
select recovery_mode from v$archive_dest_status where dest_id=2;

4、检查备库状态
select switchover_status from v$database; –发现状态not allowed 

3、看看进程MRP是否存在
 ps aux|grep mrp      –发现进程不存在

4、如果不存在执行以下:
alter database recover managed standby database using current logfile disconnect;

alter database recover managed standby database disconnect from session;  –后台执行

alter database recover managed standby database –前台执行,执行这个可以看到报错的情况

如果有报错,查看alert日志和log.xml日志 

5、验证是否正常
select process,status from v$managed_standby;
select process,status,sequence# from v$managed_standby;

如果看到mrp0正常

6、以上步骤处理好后,如果数据还不正常,接着处理

关闭备库,接着处理:
把主库上 undotbs01.dbf 文件,物理的重拷到备库机上以前undotbs01.dbf 所在目录下;

$scp /data/oracle/oradata/voip/undotbs01.dbf   192.168.122.204:/data/oracle/oradata/voip

再在主库上重新生成一个standby control file ,拷到备库机上相应目录下,

alter database create standby controlfile as ‘/data/oracle/oradata/voip/qyqdg01.ctl’

$scp /data/oracle/oradata/voip/qyqdg01.ctl   192.168.122.204:/data/oracle/oradata/voip
$ mv qyqdg01.ctl  control01.ctl
$ cp control01.ctl /data/oracle/flash_recovery_area/qyq/
$cd /data/oracle/flash_recovery_area/qyq/
$ mv control01.ctl  control02.ctl

接着
STARTUP NOMOUNT;
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


session恢复完成后,重启打开备库;

alter database open read only;
————————————————
版权声明:本文为CSDN博主「dingding_2017」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/ydwheel/article/details/70124908

(转)物理standby database的日常维护

1.停止Standby

select process, status from v$managed_standby; –查看备库是否在应用日志进行恢复

alter database recover managed standby database cancel;
shutdown immediate; 

2.切换到只读模式

—-由shutdown模式切换到只读模式-

——startup nomount;
alter database mount standby database;
alter database open read only;-

—-由应用日志模式切换到只读模式——-alter database recover managed standby database cancel; —

取消日志应用
alter database open read only;

 3.切换回管理恢复模式

startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session; — 启动日志应用alter database recover managed standby database using current logfile disconnect from session; 

4.主库和备库之间角色切换

4.1 主库切换为备库
alter database commit to switchover to physical standby;alter database commit to switchover to physical standby with session shutdown;– 主库有会话连接的时候
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session; 

4.2 从库切换为主库alter database commit to switchover to primary;
shutdown immediate;
startup
alter system switch logfile; 

5.备库自动使用主库传过来的日志进行恢复

alter database recover automatic standby database; 

6.更改保护模式

alter database set standby database to maximize protection;
alter database set standby database to maximize availability;
alter database set standby database to maximize performancen;

 7.取消自动恢复模式

alter database recover managed standby database cancel;
alter database recover managed standby database finish;
alter database recover managed standby database finish force;

JAVA 代码分析

package com.mingheinfo.common.utils;

import java.io.IOException;
import java.net.ConnectException;
import java.net.InetSocketAddress;
import java.net.SocketAddress;
import java.net.SocketTimeoutException;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.SocketChannel;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import java.util.Scanner;

import org.apache.commons.lang3.StringUtils;

import com.alibaba.fastjson.JSONObject;
import com.mingheinfo.common.json.ApiJson;

public class NIOClient {
private static final int SIZE = 1024;
private String ip = “127.0.0.1”;
private int port = 9501;
private SocketChannel channel=null;
private Selector selector = null;

String encoding = System.getProperty("file.encoding");
Charset charset = Charset.forName(encoding);

public NIOClient() {

}

public NIOClient(String ip,int port) {
    this.ip = ip;
    this.port = port;
}

public boolean connect() throws IOException{
    selector = Selector.open();

    try
    {
        channel = SocketChannel.open();
        InetSocketAddress remote = new InetSocketAddress(this.ip, this.port);

        channel.socket().connect(remote, 3000);
        //channel.connect(remote);


        while(!channel.finishConnect() ){
            System.out.print(".");
        }
    }
    catch(ConnectException e)
    {
        return false;
    }
    catch(SocketTimeoutException e)
    {
        return false;
    }

    System.out.println("connect success!");
    // 设置该sc以非阻塞的方式工作
    channel.configureBlocking(false);

    // 将SocketChannel对象注册到指定的Selector
    // SelectionKey.OP_READ | SelectionKey.OP_WRITE | SelectionKey.OP_CONNECT
    synchronized (selector) {
        channel.register(selector, SelectionKey.OP_READ);//这里注册的是read读,即从服务端读数据过来
    }
    return true;
}   


public boolean connect(String ip,int port) throws IOException{
    selector = Selector.open();

    try
    {
        this.ip  = ip;
        this.port = port;

        channel = SocketChannel.open();
        InetSocketAddress remote = new InetSocketAddress(ip, port);
        channel.connect(remote);
        while(!channel.finishConnect() ){
            System.out.print(".");
        }
    }
    catch(ConnectException e)
    {
        e.printStackTrace();
        return false;
    }

    System.out.println("connect success!");
    // 设置该sc以非阻塞的方式工作
    channel.configureBlocking(false);

    // 将SocketChannel对象注册到指定的Selector
    // SelectionKey.OP_READ | SelectionKey.OP_WRITE | SelectionKey.OP_CONNECT
    channel.register(selector, SelectionKey.OP_READ);//这里注册的是read读,即从服务端读数据过来

    return true;
}

public void reconnect()
{
    try {
        connect();
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

public void close() throws IOException
{
    selector.close();
    channel.close();
}

public boolean isConnected()
{
    if(channel==null)
        return false;

    return channel.isConnected();
}

public boolean isOpen()
{
    return channel.isOpen();
}

public static int length(String value) {
    int valueLength = 0;
    String chinese = "[\u0391-\uFFE5]";
    /* 获取字段值的长度,如果含中文字符,则每个中文字符长度为2,否则为1 */
    for (int i = 0; i < value.length(); i++) {
        /* 获取一个字符 */
        String temp = value.substring(i, i + 1);
        /* 判断是否为中文字符 */
        if (temp.matches(chinese)) {
            /* 中文字符长度为2 */
            valueLength += 2;
        } else {
            /* 其他字符长度为1 */
            valueLength += 1;
        }
    }
    return valueLength;
}

/**
 * 客户端发送数据
 * 
 * @param channel
 * @param bytes
 * @throws Exception
 */
protected void sendLen(byte[] bytes) throws IOException {
    ByteBuffer buffer = ByteBuffer.wrap(bytes);
    channel.write(buffer);
}   

protected void sendMsg(byte[] bytes) throws IOException {
    ByteBuffer newBuffer = ByteBuffer.wrap(bytes);

    /*
    CharBuffer cb = Charset.forName("UTF-8").decode(buffer);

    Charset cs = Charset.forName("GB2312");
    ByteBuffer newBuffer = cs.encode(cb);*/

    channel.write(newBuffer);

}

protected synchronized void send(String data) throws IOException {
    int len = length(data);

    System.out.println("Len="+len+" =="+data);
    byte[] size = ByteUtils.int2Bytes(len);
    this.sendLen(size);
    this.sendMsg(data.getBytes("gb2312"));
}

public synchronized String receive(int timeout)
{
    ByteBuffer buffer=ByteBuffer.allocate(200000);//分配缓冲区大小
    StringBuilder result = new StringBuilder();

    int dataLen = 0;
    int recLen = 0;

    try {
            while(selector.select(timeout)>0){//select()方法只能使用一次,用了之后就会自动删除,每个连接到服务器的选择器都是独立的

                //遍历每个有可用IO操作Channel对应的SelectionKey
                for(SelectionKey sk:selector.selectedKeys()){
                    //如果该SelectionKey对应的Channel中有可读的数据
                    if(sk.isReadable()){
                        //使用NIO读取Channel中的数据
                        SocketChannel sc=(SocketChannel)sk.channel();//获取通道信息

                        int ret = sc.read(buffer);//读取通道里面的数据

                        //服务端以断开
                        if(ret==-1)
                        {
                            this.connect();
                            System.out.println("服务器已断开");
                        }

                        buffer.flip();//调用此方法为一系列通道写入或获取操作做好准备 
                        // 将字节转化为为UTF-8的字符串  
                        //String receivedString=Charset.forName("UTF-8").newDecoder().decode(buffer).toString();
                        // 控制台打印出来  
                        //System.out.println("接收到来自服务器" + sc.socket().getRemoteSocketAddress() + "的信息:"  + receivedString);  
                        // 为下一次读取作准备  
                        System.out.println("有数据==============");
                        if(result.length()==0)
                        {
                            dataLen = buffer.getInt(0);

                            if(dataLen>1)
                            {
                                //System.out.println("");
                                System.out.println(dataLen+"===="+buffer.limit());
                                buffer.position(4);
                                recLen=buffer.limit();

                                if(recLen>dataLen)
                                {
                                    buffer.limit(4+dataLen);
                                }

                                result.append(getString(buffer));
                                System.out.println("有数据1=============="+result.toString());
                            }
                            else if(dataLen<1)
                            {

                                System.out.println("有数据x=============="+dataLen);
                                //无数据
                                sk.interestOps(SelectionKey.OP_READ);
                                selector.selectedKeys().remove(sk);
                                ApiJson json=new ApiJson();
                                json.setCode("99");
                                return JSONObject.toJSONString(json);                                   

                            }

                        }
                        else
                        {
                            recLen+=buffer.limit();
                            result.append(getString(buffer));
                            System.out.println("有数据2=============="+result.toString());
                        }

                        buffer.clear();
                        sk.interestOps(SelectionKey.OP_READ);
                    }
                     //删除正在处理的SelectionKey
                    selector.selectedKeys().remove(sk);
                }

                if(dataLen==-1)
                {
                    System.out.println("有数据4=============="+result.toString());
                    break;
                }

                if(recLen>dataLen)
                {
                    buffer.clear();
                    System.out.println("有数据3=============="+result.toString());
                    return result.toString();
                }                   
            }
        } catch (IOException e) {
            e.printStackTrace();
        }

    if(StringUtils.isEmpty(result.toString()))
    {
        ApiJson json=new ApiJson();
        json.setError("-1", "数据接收异常");

        return JSONObject.toJSONString(json);
    }
    return result.toString();       
}

public synchronized void clearBuffer()
{
    ByteBuffer buffer=ByteBuffer.allocate(20000);//分配缓冲区大小

    try {
            while(selector.select(2000)>0){

                //遍历每个有可用IO操作Channel对应的SelectionKey
                for(SelectionKey sk:selector.selectedKeys()){
                    //如果该SelectionKey对应的Channel中有可读的数据
                    if(sk.isReadable()){
                        //使用NIO读取Channel中的数据
                        SocketChannel sc=(SocketChannel)sk.channel();//获取通道信息

                        int ret = sc.read(buffer);//读取通道里面的数据

                        buffer.flip();//调用此方法为一系列通道写入或获取操作做好准备 

                        buffer.clear();
                        sk.interestOps(SelectionKey.OP_READ);

                        System.out.println("=========================有缓存数据=========================");
                    }
                     //删除正在处理的SelectionKey
                    selector.selectedKeys().remove(sk);
                }

            }
        } catch (IOException e) {
            e.printStackTrace();
        }

}

public String getIp() {
    return ip;
}

public void setIp(String ip) {
    this.ip = ip;
}

public int getPort() {
    return port;
}

public void setPort(int port) {
    this.port = port;
}

public static String getString(ByteBuffer buffer)  
{  
    Charset charset = null;  
    CharsetDecoder decoder = null;  
    CharBuffer charBuffer = null;  
    try  
    {  
        charset = Charset.forName("GB2312");  
        //decoder = charset.newDecoder();  
        //charBuffer = decoder.decode(buffer);//用这个的话,只能输出来一次结果,第二次显示为空  

        ByteBuffer dd = buffer.asReadOnlyBuffer();
        charBuffer = charset.decode(dd);  

        return charBuffer.toString();  
    }  
    catch (Exception ex)  
    {  
        ex.printStackTrace();  
        return "";  
    }  
}  

protected void finalize(){
    try {
        channel.close();
    } catch (IOException e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}

public static void main(String[] args) throws Exception
{
    NIOClient client = new NIOClient();
    try {
        client.connect("10.10.10.199",9501);

        String userName = "admin";
        String password = CryptoUtils.MD5(CryptoUtils.MD5("123456"));
        String msg = String.format("login User=\"%s\" Password=\"%s\"", userName,"6698d0c2522ccc0401d9fada0a57318f");

        System.out.println(msg);

        client.send(msg);
        //String data = client.receiveData();
        //System.out.println("login1="+data);


    } catch (IOException e) {
        e.printStackTrace();
    }


}

}

(转)七种网卡绑定模式详解

版权声明:本文为
PrudentWoo 原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/wuweilong/article/details/39720571
概览:

目前网卡绑定mode共有七种(0~6)bond0、bond1、bond2、bond3、bond4、bond5、bond6

常用的有三种:

mode=0:平衡负载模式,有自动备援,但需要”Switch”支援及设定。

mode=1:自动备援模式,其中一条线若断线,其他线路将会自动备援。

mode=6:平衡负载模式,有自动备援,不必”Switch”支援及设定。

说明:

    需要说明的是如果想做成mode 0的负载均衡,仅仅设置这里optionsbond0 miimon=100 mode=0是不够的,与网卡相连的交换机必须做特殊配置(这两个端口应该采取聚合方式),因为做bonding的这两块网卡是使用同一个MAC地址.从原理分析一下(bond运行在mode0下):

       mode 0下bond所绑定的网卡的IP都被修改成相同的mac地址,如果这些网卡都被接在同一个交换机,那么交换机的arp表里这个mac地址对应的端口就有多 个,那么交换机接受到发往这个mac地址的包应该往哪个端口转发呢?正常情况下mac地址是全球唯一的,一个mac地址对应多个端口肯定使交换机迷惑了。所以 mode0下的bond如果连接到交换机,交换机这几个端口应该采取聚合方式(cisco称为 ethernetchannel,foundry称为portgroup),因为交换机做了聚合后,聚合下的几个端口也被捆绑成一个mac地址.我们的解 决办法是,两个网卡接入不同的交换机即可。

       mode6模式下无需配置交换机,因为做bonding的这两块网卡是使用不同的MAC地址。

七种bond模式说明:

第一种模式:mod=0 ,即:(balance-rr)Round-robin policy(平衡抡循环策略)

特点:传输数据包顺序是依次传输(即:第1个包走eth0,下一个包就走eth1….一直循环下去,直到最后一个传输完毕),此模式提供负载平衡和容错能力;但是我们知道如果一个连接或者会话的数据包从不同的接口发出的话,中途再经过不同的链路,在客户端很有可能会出现数据包无序到达的问题,而无序到达的数据包需要重新要求被发送,这样网络的吞吐量就会下降

第二种模式:mod=1,即: (active-backup)Active-backup policy(主-备份策略)

特点:只有一个设备处于活动状态,当一个宕掉另一个马上由备份转换为主设备。mac地址是外部可见得,从外面看来,bond的MAC地址是唯一的,以避免switch(交换机)发生混乱。此模式只提供了容错能力;由此可见此算法的优点是可以提供高网络连接的可用性,但是它的资源利用率较低,只有一个接口处于工作状态,在有 N 个网络接口的情况下,资源利用率为1/N

第三种模式:mod=2,即:(balance-xor)XOR policy(平衡策略)

特点:基于指定的传输HASH策略传输数据包。缺省的策略是:(源MAC地址 XOR 目标MAC地址)% slave数量。其他的传输策略可以通过xmit_hash_policy选项指定,此模式提供负载平衡和容错能力

第四种模式:mod=3,即:broadcast(广播策略)

特点:在每个slave接口上传输每个数据包,此模式提供了容错能力

第五种模式:mod=4,即:(802.3ad)IEEE 802.3ad Dynamic link aggregation(IEEE802.3ad 动态链接聚合)

特点:创建一个聚合组,它们共享同样的速率和双工设定。根据802.3ad规范将多个slave工作在同一个激活的聚合体下。外出流量的slave选举是基于传输hash策略,该策略可以通过xmit_hash_policy选项从缺省的XOR策略改变到其他策略。需要注意的 是,并不是所有的传输策略都是802.3ad适应的,尤其考虑到在802.3ad标准43.2.4章节提及的包乱序问题。不同的实现可能会有不同的适应 性。

必要条件:

条件1:ethtool支持获取每个slave的速率和双工设定

条件2:switch(交换机)支持IEEE802.3ad Dynamic link aggregation

条件3:大多数switch(交换机)需要经过特定配置才能支持802.3ad模式

第六种模式:mod=5,即:(balance-tlb)Adaptive transmit load balancing(适配器传输负载均衡)

特点:不需要任何特别的switch(交换机)支持的通道bonding。在每个slave上根据当前的负载(根据速度计算)分配外出流量。如果正在接受数据的slave出故障了,另一个slave接管失败的slave的MAC地址。

该模式的必要条件:ethtool支持获取每个slave的速率

第七种模式:mod=6,即:(balance-alb)Adaptive load balancing(适配器适应性负载均衡)

特点:该模式包含了balance-tlb模式,同时加上针对IPV4流量的接收负载均衡(receiveload balance, rlb),而且不需要任何switch(交换机)的支持。接收负载均衡是通过ARP协商实现的。bonding驱动截获本机发送的ARP应答,并把源硬件地址改写为bond中某个slave的唯一硬件地址,从而使得不同的对端使用不同的硬件地址进行通信。

来自服务器端的接收流量也会被均衡。当本机发送ARP请求时,bonding驱动把对端的IP信息从ARP包中复制并保存下来。当ARP应答从对端到达时,bonding驱动把它的硬件地址提取出来,并发起一个ARP应答给bond中的某个slave。使用ARP协商进行负载均衡的一个问题是:每次广播 ARP请求时都会使用bond的硬件地址,因此对端学习到这个硬件地址后,接收流量将会全部流向当前的slave。这个问题可以通过给所有的对端发送更新(ARP应答)来解决,应答中包含他们独一无二的硬件地址,从而导致流量重新分布。当新的slave加入到bond中时,或者某个未激活的slave重新 激活时,接收流量也要重新分布。接收的负载被顺序地分布(roundrobin)在bond中最高速的slave上当某个链路被重新接上,或者一个新的slave加入到bond中,接收流量在所有当前激活的slave中全部重新分配,通过使用指定的MAC地址给每个 client发起ARP应答。下面介绍的updelay参数必须被设置为某个大于等于switch(交换机)转发延时的值,从而保证发往对端的ARP应答 不会被switch(交换机)阻截。

必要条件:

条件1:ethtool支持获取每个slave的速率;

条件2:底层驱动支持设置某个设备的硬件地址,从而使得总是有个slave(curr_active_slave)使用bond的硬件地址,同时保证每个 bond 中的slave都有一个唯一的硬件地址。如果curr_active_slave出故障,它的硬件地址将会被新选出来的 curr_active_slave接管其实mod=6与mod=0的区别:mod=6,先把eth0流量占满,再占eth1,….ethX;而mod=0的话,会发现2个口的流量都很稳定,基本一样的带宽。而mod=6,会发现第一个口流量很高,第2个口只占了小部分流量

Linux网口绑定:

通过网口绑定(bond)技术,可以很容易实现网口冗余,负载均衡,从而达到高可用高可靠的目的。前提约定:

2个物理网口分别是:eth0,eth1

绑定后的虚拟口是:bond0

服务器IP是:10.10.10.1

第一步,配置设定文件:

[root@woo ~]

# vi /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
IPADDR=10.10.10.1
NETMASK=255.255.255.0
NETWORK=192.168.0.0

[root@woo ~]

# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
MASTER=bond0
SLAVE=yes

[root@woo ~]

# vi /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=none
MASTER=bond0
SLAVE=yes
第二步,修改modprobe相关设定文件,并加载bonding模块:

1.在这里,我们直接创建一个加载bonding的专属设定文件/etc/modprobe.d/bonding.conf

[root@woo ~]

# vi /etc/modprobe.d/bonding.conf
alias bond0 bonding
options bonding mode=0 miimon=200

2.加载模块(重启系统后就不用手动再加载了)

[root@woo ~]

# modprobe bonding

3.确认模块是否加载成功:

[root@woo ~]

# lsmod | grep bonding
bonding 100065 0
第三步,重启一下网络,然后确认一下状况:

[root@db01 ~]

# service network restart
Shutting down interface bond0: [ OK ]
Shutting down loopback interface: [ OK ]
Bringing up loopback interface: [ OK ]
Bringing up interface bond0: [ OK ]

[root@db01 ~]

# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.4.0-1 (October 7, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 40:f2:e9:db:c9:c2

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 40:f2:e9:db:c9:c3

[root@db01 ~]

# ifconfig | grep HWaddr
bond0 Link encap:Ethernet HWaddr 40:F2:E9:DB:C9:C2
eth0 Link encap:Ethernet HWaddr 40:F2:E9:DB:C9:C2
eth1 Link encap:Ethernet HWaddr 40:F2:E9:DB:C9:C2
从上面的确认信息中,我们可以看到3个重要信息:

1.现在的bonding模式是active-backup

2.现在Active状态的网口是eth0

3.bond0,eth1的物理地址和处于active状态下的eth0的物理地址相同,这样是为了避免上位交换机发生混乱。

任意拔掉一根网线,然后再访问你的服务器,看网络是否还是通的。

第四步,系统启动自动绑定、增加默认网关:

[root@woo ~]

# vi /etc/rc.d/rc.local

追加

ifenslave bond0 eth0 eth1
route add default gw 10.10.10.1

如可上网就不用增加路由,0.1地址按环境修改.


留心:前面只是2个网口绑定成一个bond0的情况,如果我们要设置多个bond口,比如物理网口eth0和eth1组成bond0,eth2和eth3组成bond1,

多网口绑定:

那么网口设置文件的设置方法和上面第1步讲的方法相同,只是/etc/modprobe.d/bonding.conf的设定就不能像下面这样简单的叠加了:

alias bond0 bonding

options bonding mode=1 miimon=200

alias bond1 bonding

options bonding mode=1 miimon=200

正确的设置方法有2种:

第一种,你可以看到,这种方式的话,多个bond口的模式就只能设成相同的了:

alias bond0 bonding alias bond1 bonding options bonding max_bonds=2 miimon=200 mode=1
第二种,这种方式,不同的bond口的mode可以设成不一样:

alias bond0 bonding options bond0 miimon=100 mode=1 install bond1 /sbin/modprobe bonding -o bond1 miimon=200 mode=0
 

仔细看看上面这2种设置方法,现在如果是要设置3个,4个,甚至更多的bond口,你应该也会了吧!

后记:

简单的介绍一下上面在加载bonding模块的时候,options里的一些参数的含义:

miimon 监视网络链接的频度,单位是毫秒,我们设置的是200毫秒。

max_bonds 配置的bond口个数

mode bond模式,主要有以下几种,在一般的实际应用中,0和1用的比较多。
————————————————
版权声明:本文为CSDN博主「PrudentWoo」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/wuweilong/article/details/39720571