2019年6月17日月曜日

MySQLグループレプリケーション

そのため、MySQLのグループレプリケーションはMySQL 5.7で生まれました。 人々がそれについてもっと質問し始めている間今それは少し出ています。
以下は、これを設定する方法の例と、それをつついたときのいくつかの問題点の例です。
3種類のサーバーを使用しています

サーバーCENTOSA

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.02 sec)

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.17:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> SET SQL_LOG_BIN=0;
mysql> CREATE USER repl@'%' IDENTIFIED BY 'replpassword';
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
mysql> FLUSH PRIVILEGES;
mysql> SET SQL_LOG_BIN=1;


CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';


mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)


mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.11 sec)


mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)


mysql> SELECT * FROM performance_schema.replication_group_members \G

*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15
だから今私たちはもっとサーバーを追加することができます。
サーバーCENTOSB

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=2
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE

log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE


transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.89:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
MASTER_USER='repl',
MASTER_PASSWORD='replpassword'
FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (4.03 sec)

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | RECOVERING | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)


サーバーCENTOSC

vi my.cnf
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
server_id=3
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction_write_set_extraction=XXHASH64
group_replication_group_name="90d8b7c8-5ce1-490e-a448-9c8d176b54a8"
group_replication_start_on_boot=off
group_replication_local_address= "192.168.111.124:33061"
group_replication_group_seeds= "192.168.111.17:33061,192.168.111.89:33061,192.168.111.124:33061"
group_replication_bootstrap_group=off

mysql> CHANGE MASTER TO
-> MASTER_USER='repl',
-> MASTER_PASSWORD='replpassword'
-> FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;
Query OK, 0 rows affected (0.02 sec)

mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.58 sec)
mysql> SELECT * FROM performance_schema.replication_group_members \G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 1ab30239-5ef6-11e9-9b4a-08002712f4b1
MEMBER_HOST: centosa
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.15

*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: 572ca2fa-5eff-11e9-8df9-08002712f4b1
MEMBER_HOST: centosb
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15

*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
MEMBER_ID: c5f3d1d2-8dd8-11e9-858d-08002773d1b6
MEMBER_HOST: centosc
MEMBER_PORT: 3306
MEMBER_STATE: ONLINE
MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.15
3 rows in set (0.00 sec)


だからこれはすべて素晴らしいですが、それは常に彼らがオンラインになることを意味するわけではなく、彼らはしばしば回復モードで座ることができます。
私はこれまでのところMySQLがクラッシュして失敗するのを見てきましたので、安定性を保証する必要があります。
mysql> create database testcentosb;<br> ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement<br>
これらの要因のいくつかに対処するためのサイドノート -
mysql> START GROUP_REPLICATION;
ERROR 3094 (HY000): The START GROUP_REPLICATION command failed as the applier module failed to start.

mysql> reset slave all;
Query OK, 0 rows affected (0.03 sec)
- それからChange masterコマンドからやり直す
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.

[ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Error on opening a connection to 192.168.111.17:33061 on local port: 33061.'
[ERROR] [MY-011526] [Repl] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: c5f3d1d2-8dd8-11e9-858d-08002773d1b6:1-4 >
[ERROR] [MY-011522] [Repl] Plugin group_replication reported: 'The member contains transactions not present in the group. The member will now exit the group.'

https://ronniethedba.wordpress.com/2017/04/22/this-member-has-more-executed-transactions-than-those-present-in-the-group/


[ERROR] [MY-011620] [Repl] Plugin group_replication reported: 'Fatal error during the recovery process of Group Replication. The server will leave the group.'
[ERROR] [MY-013173] [Repl] Plugin group_replication reported: 'The plugin encountered a critical error and will abort: Fatal error during execution of Group Replication'

SELECT * FROM performance_schema.replication_connection_status\G


私の考え...
グループレプリケーションはシングルプライマリモードまたはマルチノードで設定できることに注意してください。
mysql> select @@group_replication_single_primary_mode\G
*************************** 1. row ***************************
@@group_replication_single_primary_mode: 1

mysql> create database testcentosb;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
プライマリノードに何も書き込まないと、もちろんエラーになります。


group-replication-single-primary-mode = off < - cnfファイルに追加されました。
mysql> SELECT * FROM performance_schema.replication_group_members;
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| CHANNEL_NAME               | メンバーID                             | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | セントーサ     |         3306 | 回復   | 一次     | 8.0.15         |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb     |         3306 | オンライン       | 一次     | 8.0.15         |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc     |         3306 | 回復   | 一次     | 8.0.15         |
+ --------------------------- + --------------------- ----------------- + ------------- + ------------- + ---- ---------- + ------------- + ---------------- +

3行セット(0.00秒)


ただし、フェイルオーバーの場合に自動的にロールオーバーするようにトラフィックを処理するために、Keepalived、MySQLルーター、ProxySQLなどを使用しているのが今です。 私がプライマリを停止したときに、すぐ下からフェイルオーバーしているのがわかります。

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)

[root@centosa]# systemctl stop mysqld

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
2 rows in set (0.00 sec)

[root@centosa]# systemctl start mysqld
[root@centosa]# mysql
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.34 sec)

mysql> SELECT * FROM performance_schema.replication_group_members ;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | RECOVERING | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


回復はまだ問題になっていました。単純に参加し直すことはできないからです。 すべてのアカウントと手順をもう一度確認する必要がありましたが、最終的には元に戻しました。

mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 1ab30239-5ef6-11e9-9b4a-08002712f4b1 | centosa | 3306 | ONLINE | SECONDARY | 8.0.15 |
| group_replication_applier | 572ca2fa-5eff-11e9-8df9-08002712f4b1 | centosb | 3306 | ONLINE | PRIMARY | 8.0.15 |
| group_replication_applier | c5f3d1d2-8dd8-11e9-858d-08002773d1b6 | centosc | 3306 | ONLINE | SECONDARY | 8.0.15 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)


私はまだ100%売れていないので、これをもっと試してみる必要があります。私はまだGaleraの複製に傾いているのでこれを必要としています。

興味のあるURL


  • https://dev.mysql.com/doc/refman/8.0/en/group-replication.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-deploys-in-single-primary-mode.html
  • http://datacharmer.blogspot.com/2017/01/mysql-group-replication-vs-multi-source.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-launching.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-configuring-instances.html
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-adding-instances.html
  • https://ronniethedba.wordpress.com/2017/04/22/how-to-setup-mysql-group-replication/
  • https://www.digitalocean.com/community/tutorials/how-to-configure-mysql-group-replication-on-ubuntu-16-04
  • https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html#sysvar_group_replication_group_seeds
  • https://bugs.mysql.com/bug.php?id=90534
  • https://www.percona.com/blog/2017/02/24/battle-for-synchronous-replication-in-mysql-galera-vs-group-replication/
  • https://lefred.be/content/mysql-group-replication-is-sweet-but-can-be-sour-if-you-misunderstand-it/
  • https://www.youtube.com/watch?v=IfZK-Up03Mw
  • https://mysqlhighavailability.com/mysql-group-replication-a-quick-start-guide/

  • 2019年6月4日火曜日

    最大接続数214 4.15.0-46-ジェネリック#49-Ubuntu

    そのため、max_connectionsがmy.cnfファイルで設定されている値から214に低下するという問題は、Ubuntuでしばらくの間発生しています。

    例として、それは2015年に戻ってここで指摘されました



    私は最近これに再び遭遇し、次のステップで解決しました。


    # cp /lib/systemd/system/mysql.service /etc/systemd/system/
    # cd /etc/systemd/system/
    # vi mysql.service

    LimitNOFILE=infinity
    LimitMEMLOCK=infinity

    # systemctl daemon-reload
    # systemctl restart mysql


    これらのステップが完了すると、MySQL接続はmy.cnfファイル内の指定されたパラメータで安定しました。

    2019年4月15日月曜日

    簡易キープアライブの設定

    キープアライブはしばらく前から存在していましたが、それでも多くの人にとって謎です。
    したがって、これはkeepalivedがMySQLでどのように機能するかを示す非常に単純な例です。 うまくいけば、これは質問がある人を助けることができます。

    Simple master to slaveをセットアップします。 意味..あるイベントで2番目にフェイルオーバーしない限り、1つに書き込みます。

    1日 - インストールkeepalived


    #yum検索キープアライブ
    keepalived .x86_64:ロードバランサと高可用性サービス

      名前と要約の一致のみ 。すべてを "search all"で検索してください。
    #yum -y install keepalived

    これで設定ファイルができました

    #ls -ltr /etc/keepalived/keepalived.conf  

    あなたがいつもバックアップしているようにオリジナルを保存してください..正しい....
    #cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.orig

    だからあなたはあなたの仮想IPアドレスに使用できるIPアドレスを把握する必要があります。 この例では192.168.0.123を選びました。

    次に、新しい設定ファイルに使用するスクリプトを設定します。

    ここで私がしたことがいくつかあります。
    keepalived用の.cnfファイルと/ etc / keepalived内のログをすべて残しました。
    これは例のためにそれを簡単にする従ってあなたがこれをするかまたはあなた自身のcnfファイルを使用することができる。

    スクリプト:

    cat /etc/keepalived/keepalived_check.sh  
    #!/ bin / bash

    #MySQLの状態を監視する

    #このノードmysqlが停止している場合

    #そしてその奴隷は生きている、それからそのキープアライブを止めなさい。 もう一方のノードがIPをバインドします。



    export MYSQL_HOME = / etc / keepalived /

    export PATH = $ MYSQL_HOME / bin:$ PATH



    mysql = "/ usr / bin / mysql"

    mysqladmin = "/ usr / bin / mysqladmin"

    delay_file = "$ MYSQL_HOME / slave_delay_second.log"

    slave_host = $ 1





    ALIVE = $($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.localhost.cnf   ping | 生きてる wc -l);

    REMOTEALIVE = $($ mysqladmin --defaults-file = $ MYSQL_HOME / .my.remotehost.cnf   ping | 生きてる wc -l);



    if [[$ ALIVE -ne 1]]

    それから

    #echo「MySQLがダウンしています」

            if [[$ REMOTEALIVE -eq 1]]

            それから

            エコー「シャットダウンキープアライブ」

                systemctl stopキープアライブ  

          エコー「keepalived stop」

            fi

    #その他

    #echo「MySQLは稼働しています」

    #日付

    fi



    終了0#すべて終了

    新しい設定ファイル

    cat /etc/keepalived/keepalived.conf
    global_defs {



          notification_email {

            anothermysqldba@gmail.com  

          }



          notification_email_from anothermysqldba@gmail.com  

          smtp_server localhost

          smtp_connect_timeout 30



          }







    vrrp_script check_mysql {

       スクリプト "/etc/keepalived/keepalived_check.sh"

       間隔2

       重さ2

    }







    vrrp_instance VI_1 {



          州マスター

          インタフェースenp0s8   #<---インターフェース名があなたの本当のIP / sbin / ifconfigを保持するもの

            #ip link showで見つかった

          virtual_router_id 51

          優先度101

          advert_int 1

          いらない   #優先順位の高いノードでのみ必要

          認証{

            auth_type PASS

            auth_pass 1111

          }





          track_script {

            check_mysql

          }



          virtual_ipaddress {

            192.168.0.123  

          }




    }



    これはすべて素晴らしいことですが、うまくいきますか。

    2人のホストがいます

    [root @ centosa keepalived]#ホスト名

    セントーサ

    [root @ centosb keepalived]#ホスト名
    centosb

    キープアライブを開始

    [root @ centosa keepalived]#systemctl statusキープアライブ
    ●keepalived.service - LVSおよびVRRPハイアベイラビリティモニタ
       ロード済み:ロード済み(/usr/lib/systemd/system/keepalived.service;無効、ベンダーのプリセット:無効)
       アクティブ:非アクティブ(デッド)
    [root @ centosa keepalived]#systemctl restartキープアライブ
    [root @ centosa keepalived]#systemctl statusキープアライブ
    keepalived.service - LVSおよびVRRPハイアベイラビリティモニタ
       ロード済み:ロード済み(/usr/lib/systemd/system/keepalived.service;無効、ベンダーのプリセット:無効)
        アクティブ: アクティブ(実行中)

    [root @ centosa keepalived]#ssh 192.168.0.123 'hostname'
    root@192.168.0.123のパスワード:  

    セントーサ

    接続が既に機能していることを証明する

    [root @ centosa keepalived]#mysql - デフォルトファイル= .my.remotehost.cnf --host = 192.168.0.101   -e "select @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +
    [root @ centosa keepalived]#mysql - デフォルトファイル= .my.remotehost.cnf --host = 192.168.0.102   -e "select @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | セントーサ     |
    + ------------ +

    実行されていることを再確認してください。

    [root @ centosa keepalived]#systemctl statusキープアライブ| grep active
        アクティブ: アクティブ  

    [root @ centosb keepalived]#systemctl statusキープアライブ| grep active
        アクティブ: アクティブ  

    現在のVIPをテストします。mysqlを停止し、同じVIPがホストを変更するのを見ます...

    [root @ centosa keepalived]#mysql - デフォルトのファイル= .my.remotehost.cnf --host = 192.168.0.123   -e "select @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | セントーサ     |
    + ------------ +
    [root @ centosa keepalived]#systemctl stop mysqld  
    [root @ centosa keepalived]#mysql - デフォルトのファイル= .my.remotehost.cnf --host = 192.168.0.123   -e "select @@ hostname"
    + ------------ +
    | @@ hostname |
    + ------------ +
    | centosb     |
    + ------------ +

    2019年4月10日水曜日

    時々遅いデータベースはデータベースではありません...

    だから私は最近更新されたMySQL 5、6がなぜ古い5.5より遅いのかを調べるように依頼されました。

    それで私は標準変数やキャッシュなどを見回すことから始めました。

    テストケースは、5.5よりも5.6で実行するのに約2倍の時間がかかる単純なルーチンでした。

    ミックスに追加するために、5.6バージョンはInnodb_buffer_pool_sizeの2倍、そしてもちろん全体的にもっと多くのramを持っていました。

    だから私はMySQLslapでいくつかのテストを始めました...

    Mysqlslapテストでは5.6では遅くなります

    5.6:
    mysqlslap --defaults-file =。/。my.cnf --concurrency = 150 --iterations = 130 -query = / test.sql --create-schema = applicationdata --verbose
    基準
    すべてのクエリを実行するための平均秒数:0.028秒
    すべてのクエリを実行するための最小秒数:0.019秒
    すべてのクエリを実行する最大秒数:0.071秒
    クエリを実行しているクライアントの数:150
    1クライアントあたりの平均クエリ数:1

    5.5:
    mysqlslap --defaults-file =。/。my.cnf --concurrency = 150 --iterations = 130 --query = / test.sql --create-schema = applicationdata --verbose
    基準
    すべてのクエリを実行するための平均秒数:0.015秒
    すべてのクエリを実行するための最小秒数:0.011秒
    すべてのクエリを実行する最大秒数:0.024秒
    クエリを実行しているクライアントの数:150
    1クライアントあたりの平均クエリ数:1


    これはすべて公開ベンチマークに反する
    http://dimitrik.free.fr/blog/archives/2013/02/mysql-performance-mysql-56-ga-vs-mysql-55-32cores.html

    だから私はディスクレベルをチェックしました -

    5.6:
    #dd if = / dev / zero of =テストbs = 1048576 count = 2048
    2048 + 0レコード
    2048 + 0レコード
    2147483648バイト(2.1 GB)コピー、25.7401秒、83.4 MB /秒

    #dd if =テスト= / dev / null bs = 1048576
    2048 + 0レコード
    2048 + 0レコード
    2147483648バイト(2.1 GB)コピー、29.1527秒、73.7 MB /秒

    5.5:
    #dd if = / dev / zero of =テストbs = 1048576 count = 2048
    2048 + 0レコード
    2048 + 0レコード
    2147483648バイト(2.1 GB)コピー、19.9214秒、108 MB /秒

    #dd if =テスト= / dev / null bs = 1048576
    2048 + 0レコード
    2048 + 0レコード
    2147483648バイト(2.1 GB)コピー、20.0243秒、107 MB /秒



    ここで5.5のディスクはMySQLに関係なく遅くなります。 だからこの場合....ディスクの速度を固定するために見て.. MySQLは正常に動作しています。

    2018年5月24日木曜日

    プロキシMySQL :: HAproxy || ProxySQLとKeepAlived


    だからあなたのMySQLトラフィックをルーティングする場合、いくつかのオプションが存在します。 

    今私はHAproxyがクライアントとより頻繁に使用されるのを見てきましたが、設定するのはかなり簡単です。 Perconaには興味のある人の例があります:

    個人的に私はProxySQLが好きです。 Perconaにもこれに関するブログはほとんどありません
    PerconaにもProxySQLバージョンがあります

    私はいくつかの例を書いてみることを考えていましたが、ペルコナ全体がそれをとてもうまく説明しました。 私はそれらの投稿から何かを取り除きたくない、代わりにそれらのURLを介して多くの良い情報が利用可能であることを指摘する。 だからすでに書かれたものを書き換えるのではなく、私は興味のある人のための情報のコレクションを作成します。

    最初に自分が必要と望むものを比較して決定します。 以下のリンクはもちろん、ProxySQLに偏っていますが、全体的な検討範囲が与えられます。
    クラスタやマスターをマスタリングしていて、どのサーバーに接続していても、書き込みと読み取りがどちらになるかは気にしません。 HAproxyはシンプルな設定が可能です。

    ProxySQLの特典は、トラフィックを簡単に重み付けして並べ替えることができます。 したがって、書き込みをノード1に行って、ノード2とノード3からプルを選択することができます。これに関するドキュメントは、次の場所にあります。
    はい、HAproxyで実行できますが、それに応じてアプリケーションに指示する必要があります。
    これは、クエリルールに基づいてProxySQLで処理されます。

    今ここで明らかな質問:はい、どのようにProxySQLを単一障害点にしないようにしますか?

    あなたは堅牢なロードバランサやetcなどを投資することができます。ハードウェアを投げてください....または自分で簡単にしてオープンソースをサポートし、 KeepAliveを使用してください。 これは設定が非常に簡単で、そのすべてがここでもうまく文書化されています:
    あなたがluaとmysql-proxyを扱ったことがあるならば、ProxySQLとKeepalivedは非常に簡単です。 それでも何らかの理由でそれが必要な場合: https : //launchpad.net/mysql-proxy

    HAproxy、ProxySQL、または別のソリューションを選択した場合でも、単一障害点を別の障害点に置き換えないようにする必要があります。 あなたがプロキシを使用している場合、これをしない理由はほとんどありません。

    ProxySQLについてもう少し詳しく説明します。

    http://anothermysqldba.blogspot.com/2018/05/proxy-mysql-haproxy-proxysql-keepalived.html

    2018年3月20日火曜日

    MySQL 8.0.4rc

    MySQL 8.0.4rcは、「 一般公開前のドラフト:2018-03-19 」としてリリースされました 。 

    私は素早く覗いて、ここに私の印象を書き留めることにしました。 このリリースはしばらく話されていたので、これはいくつかの古いニュースですが、とにかく私の考えを追加しました。

    私が気づいた最初のことは、更新されたmysqlクライアントを使うという簡単な問題でした。 私の古いバージョンはまだ私の道に残っていた

    ERROR 2059 (HY000): Authentication plugin 'caching_sha2_password' cannot be loaded
    簡単な修正と有効な最新のmysqlクライアントを使用していることを確認してください。 もちろん、認証プラグインをmysql_native_passwordに戻して変更するなど、他のオプションも存在しましたが、なぜセキュリティメソッドを使用するのか気にしないでください。 これはセキュリティの非常に優れた拡張です。このより安全な方法を使用して接続を取得しているときに接続の問題がある場合は、驚かないでください。


    Welcome to the MySQL monitor. Commands end with ; or \g.
    Your MySQL connection id is 36
    Server version: 8.0.4-rc-log

    Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

    だから最初の非常にクールな強化...

    mysql> show create table user\G
    *************************** 1. row ***************************
    テーブル:ユーザー
    テーブルの作成:CREATE TABLE `user`(
    `Host` char(60)COLLATE utf8_bin NOT NULL DEFAULT ''、
    `User` char(32)COLLATE utf8_bin NOT NULL DEFAULT ''、
    `Select_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Insert_priv` enum( 'N'、 'Y')CHARACTER SET utf8 NOT NULL DEFAULT 'N'、
    `Update_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Delete_priv`列挙型( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Create_priv`列挙型( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Drop_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Reload_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Shutdown_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Process_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `File_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Grant_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `References_priv` enum( 'N'、 'Y')CHARACTER SET utf8 NOT NULL DEFAULT 'N'、
    `Index_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Alter_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Show_db_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Super_priv` enum( 'N'、 'Y')CHARACTER SET utf8 NOT NULL DEFAULT 'N'、
    `Create_tmp_table_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Lock_tables_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Execute_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Repl_slave_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Repl_client_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Create_view_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Show_view_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Create_routine_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Alter_routine_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Create_user_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Event_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Trigger_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Create_tablespace_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `ssl_type` enum( ''、 'ANY'、 'X509'、 'SPECIFIED')キャラクタセットutf8 NOT NULL DEFAULT ''、
    `ssl_cipher` blobはNULLではありませんが、
    `x509_issuer`ブロブはNULLではない、
    `x509_subject` blob NOT NULL、
    `max_questions` int(11)unsigned NOT NULL DEFAULT '0'、
    `max_updates` int(11)unsigned NOT NULL DEFAULT '0'、
    `max_connections` int(11)unsigned NOT NULL DEFAULT '0'、
    `max_user_connections` int(11)unsigned NOT NULL DEFAULT '0'、
    `plugin` char(64)COLLATE utf8_bin NOT NULL DEFAULT 'caching_sha2_password'、
    `authentication_string`テキストCOLLATE utf8_bin、
    `password_expired` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `password_last_changed`タイムスタンプNULL DEFAULT NULL、
    `password_lifetime` smallint(5)符号なしDEFAULT NULL、
    `account_locked`列挙型( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Create_role_priv` enum( 'N'、 'Y')キャラクタセットutf8 NOT NULL DEFAULT 'N'、
    `Drop_role_priv` enum( 'N'、 'Y')文字セットutf8 NOT NULL DEFAULT 'N'、
    `Password_reuse_history` smallint(5)unsigned DEFAULT NULL、
    `Password_reuse_time` smallint(5)unsigned DEFAULT NULL、
    PRIMARY KEY( `Host`、` User`)
    )/ *!50100 TABLESPACE `mysql` * / ENGINE = InnoDB DEFAULT CHARSET = utf8 COLLATE = utf8_bin STATS_PERSISTENT = 0 COMMENT = 'ユーザーとグローバル特権'
    1行セット(0.00秒)

    YEPのユーザーテーブルはInnoDBであり、独自のTableSpaceを持っています。

    新しいデータディクショナリを追加すると、Information_schemaの変更が通知されます。
    したがって、単純な例として、Columnsテーブルは歴史的にビューではありませんでしたが、現在は変更されています。


    mysql> show create table COLUMNS \G
    *************************** 1. row ***************************
    表示:列
    ビューの作成:CREATE ALGORITHM = UNDEFINED DEFINER = `mysql.infoschema` @` localhost`

    これは、information_schemaでのパフォーマンスを助けるために行われるように見えますが、クエリごとの一時テーブルの作成を削除してinformation_schemaにします。

    ドキュメントの第14章でこれについて深く掘り下げて説明します。詳細は以下のURLを参照してください。
    また、前述のデータディクショナリは、アトミックデータ定義言語(DDL)文またはアトミックDDLを持つことができます。


    新しいMySQL 8.0インスタンスへのレプリケーションを設定する前にクエリを確認しないと、これはいくつかのトランザクションを呼び起こす可能性があります。 テーブルメンテナンスの取り扱いにどのような影響が及ぶかという理由で、私はそれを言います。 "If Exists"というクリーンなクエリを書くと、大きな問題にはなりません。 全体的に、データとロールバックのオプションを保護する、より多くのトランザクションベースの機能です。


    リソース管理は非常に興味深く見えます.MySQL 8.0の新機能であるため、これに重点を置くためにはもっと時間をかけなければなりません。 全体的にグループを割り当て、クエリの優先度を設定する必要はなく、クエリの振る舞いやリソースの割り当て方法をグループ化することができます。

    mysql> select @@version;
    +------------+
    | @@バージョン|
    + ------------ +
    | 5.7.16-log |
    + ------------ +
    1行セット(0.00秒)

    mysql> desc INFORMATION_SCHEMA.RESOURCE_GROUPS;
    ERROR 1109(42S02):information_schemaの 'RESOURCE_GROUPS'テーブルが不明です

    mysql> select @@ version;
    + -------------- +
    | @@バージョン|
    + -------------- +
    | 8.0.4-rc-log |
    + -------------- +
    1行セット(0.00秒)

    mysql> desc INFORMATION_SCHEMA.RESOURCE_GROUPS;
    + ------------------------ + ----------------------- + ------ + ----- + --------- + ------- +
    | フィールド| タイプ| Null | キー| デフォルト| 余分な|
    + ------------------------ + ----------------------- + ------ + ----- + --------- + ------- +
    | RESOURCE_GROUP_NAME | varchar(64)| NO | | NULL | |
    | RESOURCE_GROUP_TYPE | 列挙型( 'SYSTEM'、 'USER')| NO | | NULL | |
    | RESOURCE_GROUP_ENABLED | tinyint(1)| NO | | NULL | |
    | VCPU_IDS | ブロブ| はい | NULL | |
    | THREAD_PRIORITY | int(11)| NO | | NULL | |
    + ------------------------ + ----------------------- + ------ + ----- + --------- + ------- +
    5行セット(0.00秒)


    InnoDBバッファプールのキャッシュに関する詳細は、現在使用可能なインデックスに関するものです。

    mysql> desc INFORMATION_SCHEMA.INNODB_CACHED_INDEXES ;
    +----------------+---------------------+------+-----+---------+-------+
    | フィールド| タイプ| Null | キー| デフォルト| 余分な|
    + ---------------- + --------------------- + ------ + --- - + --------- + ------- +
    | SPACE_ID | int(11)unsigned | NO | | | |
    | INDEX_ID | bigint(21)署名なし| NO | | | |
    | N_CACHED_PAGES | bigint(21)署名なし| NO | | | |
    + ---------------- + --------------------- + ------ + --- - + --------- + ------- +
    3行セット(0.01秒)


    InnoDBバッファプールを設定する方法が不明な場合は、log_sizesまたはflushメソッドを使用して、使用可能なメモリに基づいてMySQLを設定します。

    innodb_dedicated_server

    [mysqld]
    innodb-dedicated-server=1

    mysql> select @@ innodb_dedicated_server;
    + --------------------------- +
    | | @ innodb_dedicated_server |
    + --------------------------- +
    | 1 |
    + --------------------------- +

    この単純なテストでは、innodb_buffer_pool_sizeを6GBに設定しています(デフォルトは128MBです)。

    数多くのJSONの追加と、正規表現の変更が行われました。 どちらも有望です。

    このリリース自体のレプリケーションの強化は、コンパクトバイナリ形式を使用したJSONドキュメントの部分的な更新のバイナリログをサポートするようになりました。

    しかし、全体的に多くの機能が利用できます( ここではそのすべてを読むことができます )。そのうちの1つ(クライアントが明日持っていたがっています)は、チャネルごとの複製ファイルです。
    私のテストインスタンスはすでにバイナリログを有効にしていましたが、デフォルトではTABLEとファイルベースのマスター&スレーブ情報がデフォルトでオンになっています。

    全体的に、これはこのリリースでの最初の一見とそれに対する非常に高いレベルの考えであり、他にも多くの変更が存在することに留意してください。 このリリースに関する他のブログ投稿や、 マニュアルリリースノートを見ることも役立ちます。 管理、セキュリティ、レプリケーションの観点から非常に有望であるように見えるので、確かにダウンロードしてレビューしてください。