• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
MySQL Casual Talks in Fukuoka vol.2
 

MySQL Casual Talks in Fukuoka vol.2

on

  • 9,354 views

 

Statistics

Views

Total Views
9,354
Views on SlideShare
2,061
Embed Views
7,293

Actions

Likes
3
Downloads
13
Comments
0

17 Embeds 7,293

http://mysql-casual.org 3473
http://matsumana.wordpress.com 3225
http://spring-mt.tumblr.com 530
http://webcache.googleusercontent.com 32
http://tumblr.hootsuite.com 10
http://matsumana.info 3
http://localhost 3
https://www.google.co.jp 3
http://translate.googleusercontent.com 3
https://matsumana.wordpress.com 3
http://www.google.co.jp 2
http://mysql-casual.sakura.ne.jp 1
http://yandex.ru 1
http://search.yahoo.com 1
http://s.deeeki.com 1
http://cache.yahoofs.jp 1
http://www.google.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    MySQL Casual Talks in Fukuoka vol.2 MySQL Casual Talks in Fukuoka vol.2 Presentation Transcript

    • 5.6のレプリケーション周りを 試してみた MySQL Casual Talks in Fukuoka vol.2 2012/10/18
    • 自己紹介名前: 松崎 学所属: 株式会社キャム http://www.cam-net.co.jp/ (自社オリジナルの統合基幹業務システムをSaaSで提供中)Twitter: matsumana最近のお仕事:Javaプログラマ(Rubyもほんの少し)、 インフラ最近の興味: Ruby, Python, Groovy, Scala Fluentd, Hadoop, Asakusa Framework
    • MySQLと私使用歴5ヶ月程(前回のMySQL Casual参加後、業務でも使い始めました)まだまだアウェー感がありますが、よろしくお願いします!
    • 今回は、5.6の中で個人的に一番気になったレプリケーションについて 調べてみました。
    • まずは、とても重要な機能となる GTIDから。
    • @rkajiyamaさんのブログより http://d.hatena.ne.jp/rkajiyama/20120726/p1 GTID5.6.5から実装された、バイナリログに書かれたトランザクション単位にユニークなIDを割り当てる機能。レプリケーション環境での状況の確認やスレーブ間での進 の比較が簡単になります。
    • binlogの中身を見てみると、SQL実行前にGTIDがSETされている事が確認できます。 実行したSQLは、”create database aaa”です。
    • スレーブ側で CHANGE MASTERしてみます。GTIDを使ってレプリケーションするには、MASTER_LOG_FILE, MASTER_LOG_POSの代わりにMASTER_AUTO_POSITION = 1を指定します。(MySQL Utilitiesに含まれるmysqlreplicateでも出来るみたいです)
    • GTID使ってレプリケーション出来た! (途中は省略)
    • 試してわかった事 その1マスタから物理ファイルをスレーブにコピーした後、auto.cnfのserver-uuidを書き換えないとSTART SLAVEする時にエラーが出て、レプリケーション出来ない。The slave I/O thread stops because master and slave have equal MySQL serverUUIDs; these UUIDs must be different for replication to work.スレーブ側で以下のコマンドを実行$ echo "[auto]nserver-uuid=`uuidgen`" > /var/lib/mysql/auto.cnf※auto.cnfのパスは自分の環境に合わせて読み替えてください。
    • 試してわかった事 その2gtid-mode=ONdisable-gtid-unsafe-statementsをmy.cnfに書いた状態では、mysql_install_dbとmysql_secure_installationの実行時にエラーが出る。ERROR: 1785 Updates to non-transactional tables are forbidden whenDISABLE_GTID_UNSAFE_STATEMENTS = 1.mysql_install_dbとmysql_secure_installationを実行する時だけ、上記2つのオプションはコメントアウトする。
    • 試してわかった事 その3START SLAVEでエラーが出て、レプリケーション出来ない。mysql_install_dbとmysql_secure_installation を実行した時のbinlogも実行されているっぽい。Last_Error: Error Updates to non-transactional tables are forbidden whenDISABLE_GTID_UNSAFE_STATEMENTS = 1. on query. Default database: .Query: UPDATE mysql.user SET Password=PASSWORD(hoge) WHEREUser=root and plugin = mysql_old_passwordとりあえず、my.cnfに以下を指定(いいのかな・・・?)replicate-ignore-db=information_schema,performance_schema,mysql
    • 試してわかった事 その4master-info-repository=TABLEをmy.cnfに書かないとmysqlfailoverでエラーが出る。$ mysqlfailover --master=root@mysqlmaster:3306 --slave=root@mysqlslave:3306CRITICAL Failover requires --master-info-repository=TABLE for all slaves.
    • 今からmysqlfailoverで自動フェールオーバーを やってみます!
    • フェールオーバー テストの内容以下の構成でレプリケーション構築済。マスタ → debian00スレーブ → debian01, debian02debian01はDelayed Replicationしておく(反映までの残り時間はSHOW SLAVE STATUSGしてSQL_Remaining_Delayで確認できる)CHANGE MASTER TO MASTER_HOST=debian00,MASTER_USER=repl, MASTER_PASSWORD=repl,MASTER_AUTO_POSITION=1, MASTER_DELAY=30;
    • こうなるはずdebian02の方が進んでるので、マスタになる。debian01がdebian02をマスタとして参照する。しばらく待つとスレーブ(debian01)がマスタ(debian02)に追いつく。
    • すみません、ちゃんと動かすことが出来ませんでした><GAがリリースされたらもう一回試してみます。
    • mysqlfailoverのログFailover starting in auto mode...# Checking eligibility of slave debian01:3306 for candidate.# GTID_MODE=ON ... Ok# Replication user exists ... Ok# Candidate slave debian01:3306 will become the new master.# Preparing candidate for failover.# LOCK STRING: FLUSH TABLES WITH READ LOCK# Connecting candidate to debian02:3306 as a master to retrieve unprocessed GTIDs.# Change master command for debian01:3306# CHANGE MASTER TO MASTER_HOST = debian02, MASTER_USER = repl, MASTER_PASSWORD = 3306,MASTER_PORT = 3306, MASTER_AUTO_POSITION=1# UNLOCK STRING: UNLOCK TABLES# Waiting for candidate to catch up to slave debian02:3306.# Slave debian01:3306:# QUERY = SELECT SQL_THREAD_WAIT_AFTER_GTIDS(1EABB17C-52B6-483C-82F7-7292D4AB0373:1-91, 3)# Return Code = 0# Slave debian01:3306:# QUERY = SELECT SQL_THREAD_WAIT_AFTER_GTIDS(E16A96E0-1787-11E2-96F7-000C299AE524:1-6, 3)# Return Code = -1# Creating replication user if it does not exist.# Stopping slaves.# Performing STOP on all slaves.# Executing stop on slave debian01:3306 Ok# Executing stop on slave debian02:3306 Ok# Switching slaves to new master.# Change master command for debian01:3306# CHANGE MASTER TO MASTER_HOST = debian01, MASTER_USER = repl, MASTER_PASSWORD = 3306,MASTER_PORT = 3306, MASTER_AUTO_POSITION=1# Change master command for debian02:3306# CHANGE MASTER TO MASTER_HOST = debian01, MASTER_USER = repl, MASTER_PASSWORD = 3306,MASTER_PORT = 3306, MASTER_AUTO_POSITION=1# Starting slaves.# Performing START on all slaves.# Executing start on slave debian02:3306 Ok# Checking slaves for errors.# debian02:3306 status: Ok# Failover complete.
    • mysqlfailoverの疑問点
    • mysqlfailover使うと 自動フェールオーバーが 楽なのは良いけど、どういう感じに運用するのかな?mysqlfailoverって対話型ツールだけど、デーモン化できるの?mysqlfailover自身の監視方法は?
    • ご清聴ありがとうございました。