ラベル replication の投稿を表示しています。 すべての投稿を表示
ラベル replication の投稿を表示しています。 すべての投稿を表示

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/

  • 2014年5月15日木曜日

    MySQLは5.7のDMRを見て

    Original post: http://anothermysqldba.blogspot.com/2014/05/a-look-at-mysql-57-dmr.html

    だから私はそれが私は、MySQL 5.7を見頃だった考え出した。 これは、高レベルの概要ですが、私は一言で言えば、ドキュメント内のMySQL 5.7上で探していた。 
    だから私は、新鮮で始めてのFedora 20(Xfceの)インストールしてください。 
    全体的に、私は好奇心とMySQL 5.7と面白い発見いくつかの項目を検討します。 一言で言えばは、レビューその価値は十分な情報をたくさん持っている。 

    私がダウンロードしたのMySQL-5.7.4-M14-1.linux_glibc2.5.x86_64.rpm-bundle.tarを 

    インストールは、次の操作を行う上で計画された 
    # tar -vxf MySQL-5.7.4-m14-1.linux_glibc2.5.x86_64.rpm-bundle.tar 
    # rm -f mysql-community-embedded* 
    ]# ls -a MySQL-*.rpm 
    MySQL-client-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-embedded-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-shared-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-devel-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-server-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    MySQL-test-5.7.4_m14-1.linux_glibc2.5.x86_64.rpm 
    # yum -y install MySQL-*.rpm 
    Complete! 

    それは完全な言っている間、私は、エラーに気づいた。 それは、エラーを見つけた場合は、インストールが終了しますが、[OK]をしていない必要があります.... 
    FATAL ERROR: please install the following Perl modules before executing /usr/bin/mysql_install_db: 
    Data::Dumper 

    このエラーは、確認された.. 
    # /etc/init.d/mysql start 
    Starting MySQL............ ERROR! The server quit without updating PID file 
    # tail /var/lib/mysql/fedora20mysql57.localdomain.err 
    ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.user' doesn't exist 
    # /usr/bin/mysql_install_db 
    FATAL ERROR: please install the following Perl modules before executing /usr/bin/mysql_install_db: 
    Data::Dumper 
    # yum -y install perl-Data-Dumper 
    # /usr/bin/mysql_install_db 
    A RANDOM PASSWORD HAS BEEN SET FOR THE MySQL root USER ! 
    You will find that password in '/root/.mysql_secret'. 

    You must change that password on your first connect, 
    no other statement but 'SET PASSWORD' will be accepted. 
    # chown -R mysql:mysql /var/lib/mysql/mysql/ 
    # cat /root/.mysql_secret 
    # mysql -u root -p 
    mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('somepassword'); 
    Query OK, 0 rows affected (0.01 sec) 

    mysql> select @@version; 
    +-----------+ 
    | @@version | 
    +-----------+ 
    | 5.7.4-m14 | 
    +-----------+ 

    アップグレードやETC用より堅牢なプロセスがここに記載されています: 
    http://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html 
    あなたはGLIBC_2.15を持っているかどうかを確認してください あなたがお使いのOSでこれをインストールする場合。 

    [OKだから今、それがインストールされていることを、私たちは何がありますか。 
    mysql> select User , Host,plugin from mysql.user \G 
    *************************** 1. row *************************** 
    User: root 
    Host: localhost 
    plugin : mysql_native_password 
    mysql> show databases; 
    +--------------------+ 
    | Database | 
    +--------------------+ 
    | information_schema | 
    | mysql | 
    | performance_schema | 
    +--------------------+ 
    mysql> SELECT @@default_password_lifetime \G 
    *************************** 1. row *************************** 
    @@default_password_lifetime: 360 

    これらはすべて、長年の懸案の改善であり、改善のためのあなたのすべてに感謝します。 
    だから今残りの部分を見て、我​​々は、少なくともデータとスキーマのいくつかの種類が欲しい。 だから私は、テストのための世界のデータベースをインストールします。 
    # wget http://downloads.mysql.com/docs/world_innodb.sql.gz 
    # gzip -d world_innodb.sql.gz 
    # mysql -u root -p -e "create database world"; 
    # mysql -u root -p world < world_innodb.sql 
    # mysql -u root -p world 
    mysql> show create table City; 
    CREATE TABLE `City` ( 
    `ID` int(11) NOT NULL AUTO_INCREMENT, 
    `Name` char(35) NOT NULL DEFAULT '', 
    `CountryCode` char(3) NOT NULL DEFAULT '', 
    `District` char(20) NOT NULL DEFAULT '', 
    `Population` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`ID`), 
    KEY ` CountryCode ` (`CountryCode`), 
    CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`) 
    ) ENGINE=InnoDB
     
    mysql> ALTER TABLE City ALGORITHM=INPLACE, RENAME KEY CountryCode TO THECountryCode; 
    Query OK
     
    mysql> show create table City; 
    CREATE TABLE `City` ( 
    `ID` int(11) NOT NULL AUTO_INCREMENT, 
    `Name` char(35) NOT NULL DEFAULT '', 
    `CountryCode` char(3) NOT NULL DEFAULT '', 
    `District` char(20) NOT NULL DEFAULT '', 
    `Population` int(11) NOT NULL DEFAULT '0', 
    PRIMARY KEY (`ID`), 
    KEY ` THECountryCode ` (`CountryCode`), 
    CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`) 
    ) ENGINE=InnoDB 

    mysql> DROP TABLE test.no_such_table; 
    ERROR 1051 (42S02): Unknown table 'test.no_such_table' 
    mysql> GET DIAGNOSTICS CONDITION 1 @p1 = RETURNED_SQLSTATE, @p2 = MESSAGE_TEXT; 
    Query OK, 0 rows affected (0.45 sec) 

    mysql> SELECT @p1, @p2 \G 
    *************************** 1. row *************************** 
    @p1: 42S02 
    @p2: Unknown table 'test.no_such_table' 
    1 row in set (0.01 sec)
    • トリガーの 
      トリガー制限が解除されていますし、複数のトリガが許可されています。 彼らは良い例を与えるとして、ドキュメントを参照してください。 私は、単一のテーブルの上に複数のトリガが可能であることを示すために、いくつかここでそれをデモします。
    mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2)); 
    mysql> CREATE TRIGGER ins_sum BEFORE INSERT ON account FOR EACH ROW SET @sum = @sum + NEW.amount; 
    mysql> SET @sum = 0; 
    mysql> INSERT INTO account VALUES(137,14.98),(141,1937.50),(97,-100.00); 
    SELECT @sum AS 'Total amount inserted'; 
    +-----------------------+ 
    | Total amount inserted | 
    +-----------------------+ 
    | 1852.48 | 
    +-----------------------+
     
    mysql> CREATE TRIGGER ins_transaction BEFORE INSERT ON account 
    -> FOR EACH ROW PRECEDES ins_sum 
    -> SET 
    -> @deposits = @deposits + IF(NEW.amount>0,NEW.amount,0), 
    -> @withdrawals = @withdrawals + IF(NEW.amount<0,-NEW.amount,0);
     
    mysql> SHOW triggers \G 
    *************************** 1. row *************************** 
    Trigger: ins_transaction 
    Event: INSERT 
    Table: account 
    Statement: SET 
    @deposits = @deposits + IF(NEW.amount>0,NEW.amount,0), 
    @withdrawals = @withdrawals + IF(NEW.amount<0,-NEW.amount,0) 
    Timing: BEFORE 
    Created: 2014-05-14 21:23:49.66 
    sql_mode: STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION 
    Definer: root@localhost 
    character_set_client: utf8 
    collation_connection: utf8_general_ci 
    Database Collation: latin1_swedish_ci 
    *************************** 2. row *************************** 
    Trigger: ins_sum 
    Event: INSERT 
    Table: account 
    Statement: SET @sum = @sum + NEW.amount 
    Timing: BEFORE 
    Created: 2014-05-14 21:22:47.91 
    sql_mode: STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION 
    Definer: root@localhost 
    character_set_client: utf8 
    collation_connection: utf8_general_ci 
    Database Collation: latin1_swedish_ci
    mysql> CREATE TABLE t1 
    -> ( c1 CHAR(10) CHARACTER SET latin1 
    -> ) DEFAULT CHARACTER SET gb18030 COLLATE gb18030_chinese_ci ; 
    Query OK 
    mysql> HANDLER City OPEN AS city_handle; 
    mysql> HANDLER city_handle READ FIRST; 
    +----+-------+-------------+----------+------------+ 
    | ID | Name | CountryCode | District | Population | 
    +----+-------+-------------+----------+------------+ 
    | 1 | Kabul | AFG | Kabol | 1780000 | 
    +----+-------+-------------+----------+------------+
     
    mysql> HANDLER city_handle READ NEXT LIMIT 3; 
    +----+-----------+-------------+---------------+------------+ 
    | ID | Name | CountryCode | District | Population | 
    +----+-----------+-------------+---------------+------------+ 
    | 5 | Amsterdam | NLD | Noord-Holland | 731200 | 
    | 6 | Rotterdam | NLD | Zuid-Holland | 593321 | 
    | 7 | Haag | NLD | Zuid-Holland | 440900 | 
    +----+-----------+-------------+---------------+------------+
     
    mysql> CREATE TABLE `t2` ( 
    -> `t2_id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    -> `inserttimestamp` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    -> `somevalue` int(10) unsigned DEFAULT NULL, 
    -> `rowLastUpdateTime` datetime DEFAULT NULL, 
    -> PRIMARY KEY (`t2_id`,`inserttimestamp`) 
    -> ) ENGINE=InnoDB;
     
    mysql> ALTER TABLE t2 
    -> PARTITION BY RANGE ( TO_DAYS(inserttimestamp) ) ( 
    -> PARTITION Jan2014 VALUES LESS THAN (TO_DAYS('2014-02-01')), 
    -> PARTITION Feb2014 VALUES LESS THAN (TO_DAYS('2014-03-01')), 
    -> PARTITION Mar2014 VALUES LESS THAN (TO_DAYS('2014-04-01')), 
    -> PARTITION Apr2014 VALUES LESS THAN (TO_DAYS('2014-05-01')), 
    -> PARTITION May2014 VALUES LESS THAN (TO_DAYS('2014-06-01')), 
    -> PARTITION Jun2014 VALUES LESS THAN (TO_DAYS('2014-07-01')), 
    -> PARTITION Jul2014 VALUES LESS THAN (TO_DAYS('2014-08-01')), 
    -> PARTITION Aug2014 VALUES LESS THAN (TO_DAYS('2014-09-01')), 
    -> PARTITION Sep2014 VALUES LESS THAN (TO_DAYS('2014-10-01')), 
    -> PARTITION Oct2014 VALUES LESS THAN (TO_DAYS('2014-11-01')), 
    -> PARTITION Nov2014 VALUES LESS THAN (TO_DAYS('2014-12-01')), 
    -> PARTITION Dec2014 VALUES LESS THAN (TO_DAYS('2015-01-01')), 
    -> PARTITION Jan2015 VALUES LESS THAN (TO_DAYS('2015-02-01')) 
    -> );
     
    mysql> INSERT INTO t2 VALUES (NULL,NOW(),1,NOW()); 
    mysql> HANDLER t2 OPEN AS t_handle; 
    mysql> HANDLER t_handle READ FIRST; 
    +-------+---------------------+-----------+---------------------+ 
    | t2_id | inserttimestamp | somevalue | rowLastUpdateTime | 
    +-------+---------------------+-----------+---------------------+ 
    | 1 | 2014-05-14 21:53:28 | 1 | 2014-05-14 21:53:28 | 
    +-------+---------------------+-----------+---------------------+ 
    mysql> select @@binlog_format\G 
    *************************** 1. row *************************** 
    @@binlog_format: ROW
     

    # mysqlbinlog --database=world mysql-bin.000002 | grep world | wc -l 
    22543# mysqlbinlog --rewrite-db='world->renameddb' mysql-bin.000002 | grep renameddb | wc -l 
    22542

    2014年1月20日月曜日

    MySQLのレプリケーションは追いつくことができます

    Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html

    だから、複製は、最近のMySQL 5.6で改善された。 しかし、人々はまだ5.1および5.5を使用しているので、それらの改善点のいくつかは、現実の世界をヒットするのを待つ必要があります。

    私は最近、地理位置レプリケーションソリューションでこの方向に移動しました。 国の一部は、MySQL 5.1のサーバを持っていたし、国の他の部分は、新しいMySQL 5.6サーバがインストールされていた。

    (控えめに言っても、数時間かかった)セカンダリサーバにプライマリから初期データのバックアップを取得する問題に対処した後、私は追いつくの複製とついていく可能性が決めなければならなかった。 プライマリサーバはいくつかの大きなクエリを持っていたし、最適化が常に起動するには良い場所です。 私は、セカンダリサーバが引っ張って速く私も最初にできる限り適用しなければならなかった。

    だからここにチェックして、レプリケーションになると心に留めておくべきいくつかあります。 私はこの上で働いていたように私の思考のための支援を、以下のいくつかのリンクを追加した。

    レプリケーションは非常にI / Oの重いことができます。 アプリケーションによっては。 ブ ログサイトでは、多くの書き込みがレプリケーションのI / Oに光であることはありませんが、頻繁に書かれており、更新されたプライマリサーバは、それらが有効になっている場合relay_logsと binary_logsをたくさん書いてReplication Serverにつながるとしている。 バイナリログには、バックアップを実行するか、このサーバが他の人にプライマリにするかもしれない可能にするために、セカンダリ上で有効にすることができます。

    私は、データディレクトリとは別のデータ·パーティションにログを分割します。
    これは、my.cnfファイルに設定されているリレーログ-

    InnoDBのバッファプールは既に10GB以上の値に設定されました。 これは、このサーバーのたくさんいた。
    サーバーは背後に90,000秒であった。

    だから私は、サーバーにいくつかの調整を行うために開始され、最終的にはこれらの設定になってしまった。 付与されたすべてのサーバーが異なっている。

    MySQLの>を@ sync_relay_log_info \ G
    *************************** 1。 行***************************
    @ @ sync_relay_log_info:0
    セット内の1行(0.08秒)

    MySQLの> @選択innodb_flush_log_at_trx_commit \ G
    *************************** 1。 行***************************
    @ @ innodb_flush_log_at_trx_commit:2
    セット内の1行(0.00秒)

    MySQLの> @選択log_slave_updates \ G
    *************************** 1。 行***************************
    @ @ log_slave_updates:0

    MySQLの> @選択sync_binlog \ G
    *************************** 1。 行***************************
    @ @ sync_binlog:0
    セット内の1行(0.00秒)

    MySQLの> @選択max_relay_log_sizeを \ G
    *************************** 1。 行***************************
    @ @ max_relay_log_sizeを:268435456

    私は、レプリケーション·キャッチアップを支援する様々な設定やオプションをモニターして、私はバイナリログがオフになっています。 それはしばらく時間がかかった。 私はこの時間枠内で働いていたとして、あなたは上記を参照の設定の一部は、または適用されていない場合があります。 まだそれは戻って0秒に追いつくでした。 今、あなたは、これらの設定の多くは、上記のバイナリログとその周辺関連していることに気づくかもしれません。 だから私は少しのテストを実行しました。 だから、私はビンログを再起動し、使用可能に。 私は後で、サーバー上でチェックインし、万秒以上の背後にそれを発見した。 だから私は、もう一度再起動し、binログを無効に。 これは、15分以内のプライマリサーバと(0秒の後ろ)に追いついた。 私はAurimas「使用ツールは 、私はそれは同様に追いつく見守る。 あなたが前にそれを使用していない場合、それは非常に素晴らしく、便利なツールです。

    これは是非、プライマリサーバが、ACID準拠している必要がありますです。 このセットアップを使用すると、キャッシュ用のOSに依存し、クリーンアップしている。 これは、サーバーが他の人に情報を供給するための主リードサーバとして使用されている。 また、はい、地理位置レプリケーションがプライマリサーバで最新の状態に保つことができることを意味します。

    あなたは、スレーブを停止する必要がある場合は、それはまだすぐに何を追いつくだろうか?

    どのように、なぜあなたは、スレーブを停止しないのは、私の最初の反応である。 あなたが使用することの習慣を身に取得する必要があり、STOP SLAVE SQL_THREADを 、代わりに、STOP SLAVE ;これはリレーログがデータを収集し、ちょうどあなたのプライマリサーバに適用しないように続けることができます。 だから、それは後でリレーログを移入するのにかかる時間を短縮することを利用することができます。

    あなたのためのいくつかの追加の読書:

    2013年9月7日土曜日

    secure_authによってブロックされたMySQLアクセスおよびレプリケーション

    Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-access-and-replication-blocked-by.html

    ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

    MySQLデータベースに接続しようとしていて、このエラーが表示された場合、あなたは有効な41byteハッシュパスワードを持っている必要があります。 あなたがわからない場合は、下記のSQLを実行してきた。 あなたは、16文字のパスワードを持っている場合、それらは古いパスワードです。

    select Password from mysql.user;

    以下は、私はMySQL 5.0からMySQLの5.6への移行の一環として、これを解決する方法です。

    MySQL 5.0のサーバは古いプリ4.1パスワードや有効な41byteパスワードの混合物を持っていた。 MySQL 5.0のサーバーは、私は、レプリケーションのセットアップの一部としてMySQLのテーブルをダンプしないことにしました古いパスワードを使っていくつかの口座を持っていたので。 私は、mysqlデータベースを除いて、すべてのデータベースをダンプしました。 これは私が有効なのMySQL 5.6のテーブルの拡張を維持することを保証できます。

    MySQLは5.6サーバは、簡単にインストールし、最大だったと私はダンプデータをロードしました。 移行の一部は、彼らが新しいデータベースを評価しながら、レプリケーションを使用することでした。 のMySQL 5.6サーバ上で私は、レプリケーションユーザーアカウントをテストしている間。 私が得た応答は、このページの上部にエラーが発生しました。 レプリケーションが有効なユーザーアカウントなしで、もちろん実行されません。 エラーログは私に、このエラーを与えていた理由はここにあります:
    [ERROR] Slave I/O: error connecting to master '<user>@<hostname>:3306' - retry-time: 10 retries: 68, Error_code: 2049

    MySQL 5.0のサーバ上のアカウントの簡単なレビューでは、新しいアカウントがあらかじめ4.1パスワードを使用して確立されたことを示した。 だから私は、有効な41バイトのパスワードにアカウントをアップグレードする必要がありました。

    次のクエリでは、彼らは確かに古いパスワードが有効になっていなかったことを示した。 だから私はそれを無効にして、有効な41バイトのハッシュとしてパスワードを設定するには、再度ユーザーアカウントを更新する必要があります。

    >SELECT @@session.old_passwords, @@global.old_passwords;
    +-------------------------+------------------------+
    | @@session.old_passwords | @@global.old_passwords |
    +-------------------------+------------------------+
    | 1 | 1 |
    +-------------------------+------------------------+
    1 row in set (0.00 sec)


    >SET @@session.old_passwords = 0;
    Query OK, 0 rows affected (0.00 sec)

    >GRANT REPLICATION SLAVE ON *.* TO '<user>'@'<ip_address>' IDENTIFIED BY '<Password>';
    Query OK, 0 rows affected (0.00 sec)

    パスワードのチェックは今41byteパスワードとしてパスワードを示した。 私は、このセカンダリサーバからプライマリサーバに接続し、secure_authエラーを回避することができました。 複製が容易に接続し、問題が解決した。

    今後私は、MySQL 5.6サーバにMySQL 5.0のユーザーアカウントを取得する必要がありました。 (私はセカンダリサーバ構築の一部としてそれらを飛ばさ以来)。

    クライアントに関係なく、有効なパスワードのかどうか、ユーザーごとに再び金を​​設定する必要がありました。
    だから私は、次のSQLを実行するためにそれらを指示した。 私はこれを行っている可能性が、私は自分のパスワードのすべてを知っている必要がありますし、そのは必要ありませんでした。

    彼らのシステム内の各ユーザの。 すでに5.6システム上で有効なrootアカウントを持っているため、rootユーザーを行う必要はありません。

    >SET @@session.old_passwords = 0;
    >show grants for '<User>'@'<Host>';
    各ユーザーが次のコマンドを実行するために必要なSQLを収集するには、次のように
    SELECT CONCAT("SHOW GRANTS FOR '",User,"'@'",Host,"';") as sql_command from mysql.user;

    それぞれの結果は、 "ショーの助成金"文を実行してから、与えられた文を実行与え。
    文は次のようになります。

    GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';

    レプリケーションは、その後作成とMySQL 5.6サーバ上のMySQLテーブルを移入。

    もっとここで見つけることができます:
    http://dev.mysql.com/doc/refman/5.6/en/password-hashing.html

    2013年8月10日土曜日

    Percona Xtrabackupとスレーブ(セカンダリ)サーバを作成

    Original post: http://anothermysqldba.blogspot.com/2013/08/create-slave-secondary-server-with.html

    だから、最初のあなただけの自分自身にいくつかの時間を節約し、このためのPercona例を読むことがあります。
    http://www.percona.com/doc/percona-xtrabackup/2.1/howtos/setting_up_replication.html

    しかし、念のためにここに実際の状況に基づいて、一例です。

    プライマリサーバ

    # innobackupex /tmp/ <---- this is whatever directory you want to store the backup in. This is a very basic no fluff hot backup.

    InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy
    .........
    130809 14:40:11 innobackupex: Connection to database server closed
    130809 14:40:11 innobackupex: completed OK!

    あなたはxtrabackup_binlog_infoファイルを参照してください確認してください。 そうしない場合は、簡単に位置やログ情報を持っていないでしょう。 あなたは、必要以上の作品です時間等に基づいてバイナリログを掘り下げなければならないでしょう。

    innobackupex --apply-log /tmp/<Timestamp Directory Here>

    今、あなた次第。 あなたは、スレーブにスレーブまたはtar [GZIP]次にSCPにrsyncのディレクトリができます。 関係なくスレーブに移動する方法、作成ホットバックアップと行く準備を持っている。


    セカンダリサーバ

    # /etc/init.d/mysql stop
    mv /var/lib/mysql /var/lib/mysql_ORIG

    しかしあなたは、マスターからスレーブにファイルを移動したdatadirのフォルダに中身を入れて、例えば想定:は/ var / libに/ mysqlの。

    # chown -R mysql:mysql mysql
    /etc/init.d/mysql start
    Starting MySQL... [ OK ]

    今すぐあなたのスレーブMySQLサーバでは、簡単に複製ユーザー情報を設定することができます。

    CHANGE MASTER TO
    MASTER_HOST='<MASTER_HOST>',
    MASTER_USER='<MASTER_USER>',
    MASTER_PASSWORD='<MASTER_PASSWORD>',
    MASTER_CONNECT_RETRY = 10 ;

    xtrabackupファイルからログと位置を取得します。

    # more xtrabackup_binlog_info
    <BinLog info> <POSITION INFO>

    CHANGE MASTER TO MASTER_LOG_FILE='<BinLog info>', MASTER_LOG_POS=<POSITION INFO>;

    Start slave;


    一言で言えば、それはそれです。 詳細については、開始時に与えられたPerconaのURLを確認してください。

    2013年6月12日水曜日

    MySQL < 5.5 replication to MySQL 5.6

    Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-55-replication-to-mysql-56.html

    フラストレーションの時間後..... あなたはそのMySQLを5.5以下いずれかのバージョンを実行している場合、MySQLは5.6にアップグレードしないように私は単純にそれを配置します。 

    あなたの正気とタクトにデータを保持するためのMySQL 5.5最初にアップグレードする必要があります。 

    ブログの記事や情報の多くは、MySQL 5.6でのパスワード変更について利用可能であり、私はそれらをサポートしています。 私もMySQLは5.6のパスワードを更新し、ボックスがあったとうまく実行されている。 問題は複製だった。 私はMySQLのバージョンからMySQL 5.5未満を複製するために持っていたし、それは単に実行されませんでした。 私はレプリケーションでまだない運secure_authを無効にしないと接続することもできますが、。 

    私はアップグレードパスとして、レプリケーションをサポートしていますが、最初にMySQLを5.5時間とスティックを取る。 

    私は、MySQL 5.5にダウングレードすることになったし、すべてが今、うまく実行されます。ダウングレードにあなたのMySQLバージョンを持っている場合私は私でやったと同じ手順の多くがフォローしなければならなかったマリア双星ポストバックアップボックスを取得します。