July 2007 Archive

LifeKeeperを利用してMySQLの可用性を向上させる構成をまとめる。

可用性向上（MySQL Serverを落としたく無い）には、MySQL Clusterよりも共有ディスク型のHAクラスタリングソフトを使った方が汎用性が高い。

可用性だけで無く、合わせて参照系の負荷を分散したいのであれば、レプリケーションを組み合わせる。

更新系の負荷も分散させるのであれば、アプリケーションレベルで分割するか、データの容量次第では、MySQL Clusterも検討に値する。


基本的な構成はLifeKeeper/Veritas Cluster Server(VCS)/ClusterProともに変わらないが、それぞれのHCLを参照してサポートしているHWを選択すること。
ClusterProは実質的にHWに制限を設けていないので、頼もしい。

LifeKeeperを使う場合は、HPだとMSA1000（周辺機器一式で定価500万弱）がストレージパスを二重化できる最小構成で、IBMだとDS4300（周辺機器一式で定価450万弱）とか。



障害検知のタイミング（Linux版のデフォルト値）

ハートビート
5秒に一回、3回失敗すると障害と認識する

MySQL ARKによるMySQLリソースのチェック
mysqladminを使って生死を確認する
120秒ごとにチェックして、3回失敗すると、起動を試みて、失敗するとフェールオーバーする

サーバ
5秒ごとにチェックして3回失敗すると障害と判断する

リソース
120秒ごとにチェックする

参考：SIOS SteelEye [LifeKeeper User Site] - LifeKeeper FAQ - ARKの機能について - [Linux]MySQLARKの提供する機能（処理動作概要）を知りたいのですが



設定ファイル（my.cnf）のサンプル

[client]
# Connection
port = 3306
socket=/shared_storage/mysql/mysql.sock

# For LifeKeeper
user=mysql
password=<password>

[mysqld]
datadir=/shared_storage/mysql
log-error=/shared_storage/mysql/<virtual host name>.err
pid-file=/shared_storage/mysql/mysql.pid

# Connection
port = 3306
user=mysql
socket=/shared_storage/mysql/mysql.sock

log-bin=/shared_storage/mysql/<virtual host name>-bin

Triggerは該当のテーブルが存在しなくても作成できて、実行時に、こんな間際らしいエラーが

[world]>insert into dotriggers values(1), (2), (3), (4), (5), (6);
ERROR 1100 (HY000): Table 'audit_triggers' was not locked with LOCK TABLES

おまけに、（PROCEDURE/FUNCTIONには存在する、）SHOW TRIGGER STATUS;のようなコマンドは存在しない。

ストアドプロシージャやストアドファンクション内で使う変数は、次の手順で使う。

宣言
DECLARE

• デフォルト値やデータ型を定義できる
• DECLARE var1 INT;

値の設定

1. SELECT ... INTO ...
• SELECTした結果をそのまま使える
• SELECT SUM(population) FROM Country into @WorldPop;
  
2. SET
• スタティックな値を入れる場合などに
• SET var1=10;
  

ストアドプロシージャやストアドファンクション内では、エラーハンドリングにコンディションとハンドラーを使うことができる。

コンディションとハンドラーのサンプル

[(none)]> use test;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
[test]>
[test]> create table d_table(s1 int, primary key(s1));
Query OK, 0 rows affected (0.03 sec)

[test]>
[test]> delimiter //
[test]> create procedure dohandler()
    ->
    -> begin
    -> declare dup_keys condition
    -> for sqlstate '23000';
    -> declare continue handler for
    -> dup_keys set @garbage=1;
    -> set @x=1;
    -> insert into test.d_table values(1);
    -> set @x=2;
    -> insert into test.d_table values(1);
    -> set @x=3;
    -> end//
Query OK, 0 rows affected (0.00 sec)

[test]> delimiter ;
[test]>
[test]> call dohandler();
Query OK, 0 rows affected (0.00 sec)

[test]>
[test]> select @x;
+------+
| @x   |
+------+
| 3    |
+------+
1 row in set (0.00 sec)

[test]>
[test]> select @garbage;
+----------+
| @garbage |
+----------+
| 1        |
+----------+
1 row in set (0.00 sec)

コンディションで指定できるSQLSTATEとMySQLエラーコードの一覧は、MySQL AB :: MySQL 5.0 Reference Manual :: 23.4.4.7 Mapping MySQL Error Numbers to SQLStatesやMySQL AB :: MySQL 5.0 Reference Manual :: B.2 Server Error Codes and Messagesに載っている。

コンディションの宣言で、SQLSTATE 23000にdup_keyという名前を指定している。SQLSTATE 23000は、PKへ一意でない値をINSERTした場合などに発生する。

    -> declare dup_keys condition
    -> for sqlstate '23000';

ハンドラーの宣言ではdup_keyが発生した場合に、そのまま処理を続けて、なおかつユーザー変数@garbageに1を設定している。

    -> declare continue handler for
    -> dup_keys set @garbage=1;

MySQLではStored ProcedureとStored Functionを、まとめてStored Routineと呼んでいる。

• ストアドプロシージャ
1. CALLで呼び出し
2. OUTPUT変数で値のやりとりができる
   
• ストアドファンクション
1. SELECTで呼び出し
2. 必ず値を返す

ストアドプロシージャ
これから作成するストアドプロシージャがすでにある場合は削除

use test;
drop procedure param_proc_one if exists param_proc_one;

ストアドプロシージャの作成

create procedure param_proc_one(in param1 int, out param2 int, inout param3 int)
select param1, param2, param3;

パラメータの設定

set @value1=10, @value2=200, @value3=300;

ストアドプロシージャの呼び出し

call param_proc_one(@value1, @value2, @value3);

これから作成するストアドプロシージャがすでにある場合は削除

drop procedure param_proc_two if exists param_proc_two;

ストアドプロシージャの作成

create procedure param_proc_two(in param1 int, out param2 int, inout param3 int)
set param1=1, param2=2, param3=3;

ストアドプロシージャの呼び出し

call param_proc_two(@value1, @value2, @value3);

パラメータの変化を確認

select @value1, @value2, @value3;

ストアドファンクション
これから作成するストアドファンクションがすでにある場合は削除

drop function hello1 if exists hello1;

ストアドファンクションの作成

create function hello1(input char(20)) returns char(50) return concat('Hello, ', input, '!');

ストアドファンクションの呼び出し

select hello1('tttttttttttt');

Xcodeユーザーガイド: 任意のアプリケーションをデバッグする

ブレークポイントを設定
実行可能ファイルー「mysqldを実行」ー「接続」

「デバッグ」では、デバッグウィンドウがうまく開かなかったので、「実行」してから「接続」した

特にXcodeでビルドしていなくてもOK


Xcode便利すぎ！

MySQL Bugs: #10783: SHOW TABLES FROM INFORMATION_SCHEMA gives error
このバグについて。

MySQL Lists: internals: bk commit into 5.0 tree (gluh:1.1929) BUG#10018
このページを参考に。

原因は、「大文字、小文字を区別したまま文字列比較していた」ということらしい。

make_db_listまで

#0  make_db_list (thd=0x402c218, files=0xb0499b84, idx_field_vals=0xb0499b94, with_i_schema=0xb0499b93, is_wild_value=false) at sql_show.cc:2031
#1  0x0018736d in get_all_tables (thd=0x402c218, tables=0x4055350, cond=0x0) at sql_show.cc:2198
#2  0x0018ecc1 in get_schema_tables_result (join=0x4055878, executed_place=PROCESSED_BY_JOIN_EXEC) at sql_show.cc:4032
#3  0x000f9b25 in JOIN::exec (this=0x4055878) at sql_select.cc:1658
#4  0x000fb0fd in mysql_select (thd=0x402c218, rref_pointer_array=0x402d1f0, tables=0x4055350, wild_num=0, fields=@0x402d160, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2693024256, result=0x4055868, unit=0x402ce94, select_lex=0x402d0cc) at sql_select.cc:2231
#5  0x000fb3cd in handle_select (thd=0x402c218, lex=0x402ce30, result=0x4055868, setup_tables_done_option=0) at sql_select.cc:255
#6  0x0009e1cb in mysql_execute_command (thd=0x402c218) at sql_parse.cc:2651
#7  0x000a5ded in mysql_parse (thd=0x402c218, inBuf=0x4055028 "show tables from INFORMATION_SCHEMA", length=35) at sql_parse.cc:6019
#8  0x000a688e in dispatch_command (command=COM_QUERY, thd=0x402c218, packet=0x2d78019 "show tables from INFORMATION_SCHEMA", packet_length=36) at sql_parse.cc:1802
#9  0x000a7db9 in do_command (thd=0x402c218) at sql_parse.cc:1581
#10 0x000a82b1 in handle_one_connection (arg=0x402c218) at sql_parse.cc:1193
#11 0x90024227 in _pthread_body ()

その後

(gdb) s
2032      *with_i_schema= 0;
(gdb)
2033      get_index_field_values(lex, idx_field_vals);
(gdb)
get_index_field_values (lex=0x402ce30, index_field_values=0xb0499b94) at sql_show.cc:1868
1868      const char *wild= lex->wild ? lex->wild->ptr() : NullS;
(gdb)
1869      switch (lex->orig_sql_command) {
(gdb)
1876        index_field_values->db_value= lex->select_lex.db;
(gdb)
1877        index_field_values->table_value= wild;
(gdb)
1878        break;
(gdb)
1884    }
(gdb)
make_db_list (thd=0x402c218, files=0xb0499b84, idx_field_vals=0xb0499b94, with_i_schema=0xb0499b93, is_wild_value=false) at sql_show.cc:2034
2034      if (is_wild_value)
(gdb)
2060      if (lex->orig_sql_command != SQLCOM_END)
(gdb)
2062        if (!my_strcasecmp(system_charset_info, INFORMATION_SCHEMA_NAME.str,
(gdb)
my_strcasecmp_utf8 (cs=0x5577a0, s=0x3a7624 "information_schema", t=0x4055098 "information_schema") at ctype-utf8.c:2471
2471      MY_UNICASE_INFO **uni_plane= cs->caseinfo;

make_db_listの中で、my_strcasecmpが呼ばれている。

if (!my_strcasecmp(system_charset_info, INFORMATION_SCHEMA_NAME.str,
                       idx_field_vals->db_value))

idx_field_vals->db_valueにはshow tables from ...で指定したinformation_schema,またはINFORMATION_SCHEMAという文字列が入っている。

/include/m_ctype.h

#define my_strcasecmp(s, a, b)        ((s)->coll->strcasecmp((s), (a), (b)))

((s)->coll->strcasecmp((s), (a), (b)))がよく分からない！！！
→単純に、sオブジェクトのメンバcoll、そのまたメンバのstrcasecmpへ値を入れているらしい

collはMY_COLLATION_HANDLERのポインター?（/include/m_ctype.h）
使っているCharacter Setに応じて、my_strcasecmp_xxxが呼ばれるらしい。
→ここがよく分からない！！！

my_strcasecmp_utf8では比較する文字列を全て小文字に変換している
/strings/ctype-utf8.c

int my_strcasecmp_utf8(CHARSET_INFO *cs, const char *s, const char *t)
{
  MY_UNICASE_INFO **uni_plane= cs->caseinfo;
  while (s[0] && t[0])
  {
    my_wc_t s_wc,t_wc;

    if ((uchar) s[0] < 128)
    {
     /*      s[0] is between 0 and 127.   
             It represents a single byte character.                           
             Convert it into weight according to collation.
     */
      s_wc= plane00[(uchar) s[0]].tolower;
      s++;
    }
.....

ということで、最近のバージョンでは無事になおっているらしい。

[test]> show global status like '%lock%';
+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| Com_lock_tables               | 0     |
| Com_unlock_tables             | 0     |
| Innodb_row_lock_current_waits | 0     |
| Innodb_row_lock_time          | 0     |
| Innodb_row_lock_time_avg      | 0     |
| Innodb_row_lock_time_max      | 0     |
| Innodb_row_lock_waits         | 0     |
| Key_blocks_not_flushed        | 0     |
| Key_blocks_unused             | 7243  |
| Key_blocks_used               | 7248  |
| Qcache_free_blocks            | 0     |
| Qcache_total_blocks           | 0     |
| Table_locks_immediate         | 17    |
| Table_locks_waited            | 0     |
+-------------------------------+-------+
14 rows in set (0.00 sec)

[test]> desc t2;
+-------+---------+------+-----+---------+----------------+
| Field | Type    | Null | Key | Default | Extra          |
+-------+---------+------+-----+---------+----------------+
| a     | int(11) | NO   | PRI | NULL    | auto_increment |
| b     | int(11) | YES  |     | NULL    |                |
+-------+---------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

[test]> select max(a) from t2;
+----------+
| max(a)   |
+----------+
| 16979416 |
+----------+
1 row in set (0.09 sec)

現在の状態

[test]> alter table t2 auto_increment=20000000;
Query OK, 16979416 rows affected (1 min 26.51 sec)
Records: 16979416  Duplicates: 0  Warnings: 0

AUTO_INCREMENTで開始したい値を設定する（若干時間がかかった）

[test]> show create table t2;
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                             |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| t2    | CREATE TABLE `t2` (
  `a` int(11) NOT NULL auto_increment,
  `b` int(11) default NULL,
  PRIMARY KEY  (`a`)
) ENGINE=MyISAM AUTO_INCREMENT=20000000 DEFAULT CHARSET=utf8 |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

設定されたAUTO_INCREMENT値を確認する

[test]> select max(a) from t2;
+----------+
| max(a)   |
+----------+
| 16979416 |
+----------+
1 row in set (0.00 sec)

この状態ではMAX値は変わっていない

[test]> insert into t2(a) values(null);
Query OK, 1 row affected (0.29 sec)

一行挿入

[test]> select max(a) from t2;
+----------+
| max(a)   |
+----------+
| 20000000 |
+----------+
1 row in set (0.00 sec)

MAX値も新しい値となった

[test]> show create table t2;
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                                                                                             |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| t2    | CREATE TABLE `t2` (
  `a` int(11) NOT NULL auto_increment,
  `b` int(11) default NULL,
  PRIMARY KEY  (`a`)
) ENGINE=MyISAM AUTO_INCREMENT=20000001 DEFAULT CHARSET=utf8 |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

設定したAUTO_INCREMENT値の確認

• サーバー変数
• グローバル・サーバー変数
• セッション・サーバー変数
• ユーザー変数(User-Defined Variables)

サーバー変数は
@@<変数名>
で
ユーザー変数は
@<変数名>

mysql> select @@sql_mode;
+------------+
| @@sql_mode |
+------------+
| |
+------------+
1 row in set (0.00 sec)

mysql> set session sql_mode='strict_trans_tables';
Query OK, 0 rows affected (0.00 sec)

mysql> select @@sql_mode;
+---------------------+
| @@sql_mode |
+---------------------+
| STRICT_TRANS_TABLES |
+---------------------+
1 row in set (0.00 sec)

mysql> set @sql_mode=10;
Query OK, 0 rows affected (0.04 sec)

mysql> select @@sql_mode;
+---------------------+
| @@sql_mode |
+---------------------+
| STRICT_TRANS_TABLES |
+---------------------+
1 row in set (0.00 sec)

mysql> select @sql_mode;
+-----------+
| @sql_mode |
+-----------+
| 10 |
+-----------+
1 row in set (0.00 sec)

(gdb) bt
#0  make_db_list (thd=0x4055018, files=0xb0468be0, idx_field_vals=0xb0468bec, with_i_schema=0xb0468bdf, is_wild_value=true) at sql_show.cc:2031
#1  0x00187db0 in fill_schema_shemata (thd=0x4055018, tables=0x4056b68, cond=0x0) at sql_show.cc:2398
#2  0x0018ecc1 in get_schema_tables_result (join=0x4057150, executed_place=PROCESSED_BY_JOIN_EXEC) at sql_show.cc:4032
#3  0x000f9b25 in JOIN::exec (this=0x4057150) at sql_select.cc:1658
#4  0x000fb0fd in mysql_select (thd=0x4055018, rref_pointer_array=0x4055ff0, tables=0x4056b68, wild_num=0, fields=@0x4055f60, conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2693024256, result=0x4057140, unit=0x4055c94, select_lex=0x4055ecc) at sql_select.cc:2231
#5  0x000fb3cd in handle_select (thd=0x4055018, lex=0x4055c30, result=0x4057140, setup_tables_done_option=0) at sql_select.cc:255
#6  0x0009e1cb in mysql_execute_command (thd=0x4055018) at sql_parse.cc:2651
#7  0x000a5ded in mysql_parse (thd=0x4055018, inBuf=0x4056a28 "show databases", length=14) at sql_parse.cc:6019
#8  0x000a688e in dispatch_command (command=COM_QUERY, thd=0x4055018, packet=0x2d78019 "show databases", packet_length=15) at sql_parse.cc:1802
#9  0x000a7db9 in do_command (thd=0x4055018) at sql_parse.cc:1581
#10 0x000a82b1 in handle_one_connection (arg=0x4055018) at sql_parse.cc:1193
#11 0x90024227 in _pthread_body ()

/sql/sql_parse.cc

bool dispatch_command(enum enum_server_command command, THD *thd, char* packet, uint packet_length)
{
switch (command) {
case COM_INIT_DB: ...
case COM_REGISTER_SLAVE: ...
case COM_TABLE_DUMP: ...
case COM_CHANGE_USER: ...
case COM_EXECUTE:
mysql_stmt_execute(thd,packet);
case COM_LONG_DATA: ...
case COM_PREPARE:
mysql_stmt_prepare(thd, packet, packet_length); // !
/* and so on for 18 other cases */
default:
send_error(thd, ER_UNKNOWN_COM_ERROR);
break;

   }

MySQLのレプリケーションは非同期型であるため、バイナリログの伝送遅延とSQLの実行遅延の二つの遅延が発生する。

１．伝送遅延

 マスター側で更新クエリが実行され、バイナリログへも出力されているが、スレーブのリレーログへは出力されていないクエリが存在する場合、この差分を「伝送遅延」と呼ぶ。

伝送遅延の確認方法は次の通りとなる。

 

1. マスター側でSHOW MASTER STATUSを実行する

mysql> show master status\G

*************************** 1. row ***************************

            File: OC210515012-bin.000005

        Position: 98

    Binlog_Do_DB:

Binlog_Ignore_DB:

1 row in set (0.00 sec)

SHOW MASTER STATUS結果

 

2. スレーブ側でSHOW SLAVE STATUSを実行する

mysql> show slave status\G

*************************** 1. row ***************************

             Slave_IO_State: Waiting for master to send event

                Master_Host: localhost

                Master_User: rep

                Master_Port: 3306

              Connect_Retry: 60

            Master_Log_File: OC210515012-bin.000005

        Read_Master_Log_Pos: 98

             Relay_Log_File: OC210515012-relay-bin.000037

              Relay_Log_Pos: 241

      Relay_Master_Log_File: OC210515012-bin.000005

           Slave_IO_Running: Yes

          Slave_SQL_Running: Yes

            Replicate_Do_DB:

        Replicate_Ignore_DB:

         Replicate_Do_Table:

     Replicate_Ignore_Table:

    Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

                 Last_Errno: 0

                 Last_Error:

               Skip_Counter: 0

        Exec_Master_Log_Pos: 98

            Relay_Log_Space: 241

            Until_Condition: None

             Until_Log_File:

              Until_Log_Pos: 0

         Master_SSL_Allowed: No

         Master_SSL_CA_File:

         Master_SSL_CA_Path:

            Master_SSL_Cert:

          Master_SSL_Cipher:

             Master_SSL_Key:

      Seconds_Behind_Master: 0

1 row in set (0.01 sec)

SHOW SLAVE STATUS結果

 

3. ファイル名とポジションを比較する。

 

表の各ファイル名と各ポジションを確認する。ファイル名が同一で、ポジションが同じ数値であれば、伝送遅延はゼロということになる。

 

伝送遅延の確認

２．実行遅延 

スレーブ側のリレーログへは伝送されているが、未だSQLスレッドが実行していない更新クエリが存在する場合、その差分を「実行遅延」と呼ぶ。

実行遅延の確認は次の通りとなる。

 

1. スレーブ側でSHOW SLAVE STATUSを実行する。

 

mysql> show slave status\G

*************************** 1. row ***************************

             Slave_IO_State: Waiting for master to send event

                Master_Host: localhost

                Master_User: rep

                Master_Port: 3306

              Connect_Retry: 60

            Master_Log_File: OC210515012-bin.000005

        Read_Master_Log_Pos: 98

             Relay_Log_File: OC210515012-relay-bin.000037

              Relay_Log_Pos: 241

      Relay_Master_Log_File: OC210515012-bin.000005

           Slave_IO_Running: Yes

          Slave_SQL_Running: Yes

            Replicate_Do_DB:

        Replicate_Ignore_DB:

         Replicate_Do_Table:

     Replicate_Ignore_Table:

    Replicate_Wild_Do_Table:

Replicate_Wild_Ignore_Table:

                 Last_Errno: 0

                 Last_Error:

               Skip_Counter: 0

        Exec_Master_Log_Pos: 98

            Relay_Log_Space: 241

            Until_Condition: None

             Until_Log_File:

              Until_Log_Pos: 0

         Master_SSL_Allowed: No

         Master_SSL_CA_File:

         Master_SSL_CA_Path:

            Master_SSL_Cert:

          Master_SSL_Cipher:

             Master_SSL_Key:

      Seconds_Behind_Master: 0

1 row in set (0.01 sec)

SHOW SLAVE STATUS結果

 

2. ファイル名とポジションを確認する。

 

図の各ファイル名と各ポジションを確認する。ファイル名が同一で、ポジションが同じ数値であれば、伝送遅延はゼロということになる。

 

実行遅延の確認

MEDIUMTEXTで定義しているカラムを、例えばMEDIUMBLOB型へ変更すると、英文大文字小文字を判別するようになるので、ソート順が変わる可能性がある。
http://dev.mysql.com/doc/refman/5.0/en/blob.html

• 非バイナリ系

データタイプ    消費ストレージ    最大長
CHAR(M)    M characters    255 文字
VARCHAR(M)    L characters plus 1 or 2 bytes    65,535 文字 (subject to limitations)
TINYTEXT    L characters + 1 byte    255 バイト
TEXT    L characters + 2 bytes    65,535 バイト
MEDIUMTEXT    L characters + 3 bytes    16,777,215 バイト
LONGTEXT    L characters + 4 bytes    4,294,967,295 バイト

• バイナリ系

データタイプ    消費ストレージ    最大長
BINARY(M)    M bytes    255 バイト
VARBINARY(M)    L bytes plus 1 or 2 bytes    65,535 バイト (subject to limitations)
TINYBLOB    L + 1 bytes    255 バイト
BLOB    L + 2 bytes    65,535 バイト
MEDIUMBLOB    L + 3 bytes    16,777,215 バイト
LONGBLOB    L + 4 bytes    4,294,967,295 バイト

c:\\my.ini

[mysql]
prompt=[\d]\_>\_
user=root
password=root

[mysqld]
log
log-bin
log-slow-queries

default-character-set=utf8

c:\\data\my50.txt

!include c:/my.ini

[mysqld]

server-id=1

port=3306

basedir="C:/Program Files/MySQL/MySQL Server 5.0/"

datadir="C:/Program Files/MySQL/MySQL Server 5.0/Data/"

c:\\data\my51.txt

!include c:/my.ini

[mysqld]

server-id=2

port=3307

basedir="C:/Program Files/MySQL/MySQL Server 5.1/"

datadir="C:/Program Files/MySQL/MySQL Server 5.1/Data/"

[root@h1 ~]# rpm -ivh drbd-8.0.3-3.x86_64.rpm
Preparing...                ########################################### [100%]
   1:drbd                   警告: /etc/drbd.conf created as /etc/drbd.conf.rpmnew
########################################### [100%]
[root@h1 ~]# rpm -ivh drbd-
drbd-8.0.3/
drbd-8.0.3-3.x86_64.rpm
drbd-km-2.6.9_42.ELsmp-8.0.3-3.x86_64.rpm
[root@h1 ~]# rpm -ivh drbd-km-2.6.9_42.ELsmp-8.0.3-3.x86_64.rpm
Preparing...                ########################################### [100%]
   1:drbd-km-2.6.9_42.ELsmp ########################################### [100%]

DRBD本体で展開されたファイル

[root@h1 ~]# rpm -ql drbd-8.0.3-3
/etc/drbd.conf
/etc/ha.d/resource.d/drbddisk
/etc/rc.d/init.d/drbd
/sbin/drbdadm
/sbin/drbdmeta
/sbin/drbdsetup
/usr/lib/drbd/outdate-peer.sh
/usr/share/doc/drbd-8.0.3
/usr/share/doc/drbd-8.0.3/COPYING
/usr/share/doc/drbd-8.0.3/README
/usr/share/doc/drbd-8.0.3/drbd.conf
/usr/share/doc/drbd-8.0.3/file.list
/usr/share/man/man5/drbd.conf.5.gz
/usr/share/man/man8/drbd.8.gz
/usr/share/man/man8/drbdadm.8.gz
/usr/share/man/man8/drbddisk.8.gz
/usr/share/man/man8/drbdmeta.8.gz
/usr/share/man/man8/drbdsetup.8.gz

カーネルモジュールで展開されるファイル

[root@h1 ~]# rpm -ql drbd-km-2.6.9_42.ELsmp-8.0.3-3
/lib/modules/2.6.9-42.ELsmp
/lib/modules/2.6.9-42.ELsmp/kernel
/lib/modules/2.6.9-42.ELsmp/kernel/drivers
/lib/modules/2.6.9-42.ELsmp/kernel/drivers/block
/lib/modules/2.6.9-42.ELsmp/kernel/drivers/block/drbd.ko
/usr/share/doc/drbd-km-2.6.9_42.ELsmp-8.0.3
/usr/share/doc/drbd-km-2.6.9_42.ELsmp-8.0.3/k-config-2.6.9-42.ELsmp.gz

検証サーバを別ネットワークに移動したら、SSHでログイン時にパスワードを入れた後の応答が異様に遅くなった。。。

[root@h2 ~]# vi /etc/ssh/sshd_config

#UseDNS yes

をコメントアウトして、変更

UseDNS no

再起動

[root@h2 ~]# ps -ef|grep sshd
root      3130     1  0 Jun15 ?        00:00:00 /usr/sbin/sshd
root      3378  3130  0 14:08 ?        00:00:00 sshd: root@pts/3
root      3418  3380  0 14:10 pts/3    00:00:00 grep sshd
[root@h2 ~]# kill -HUP 3130

あるいはこちらで再起動

[root@h1 run]# kill -HUP `cat /var/run/sshd.pid`

1. 共通設定項目
1. ディレクトリ
• basedir: MySQLサーバをインストールした