現職を選んだ理由と将来

エンジニアを選んだ理由

敷居が低く、努力で能力を伸ばせそうだったから。

データベースエンジニアを選んだ理由

アプリは永続的な状態を持たないため、論理的に再構築することができる。
永続的な状態を保持しなければいけないデータベースソフトウェアは再構築できても、
格納されるデータは再構築できない
この再構築できないデータを整合性・完全性・機密性・可用性を維持向上させるには
データインターフェイスとなるアプリケーションを理解、ハードウェアを理解と勉強することが多い。
そのため、努力の継続が必要であり、やりがいがある。

将来はどうなりたい

データベース活用(更新性能、参照性能、整合性、可用性、完全性、信頼性、保存)スペシャリストになりたい。

年末年始 勉強リスト

年末年始 勉強リスト

日付 起床時刻 就寝時刻 行動
12/23 11時 25時30分
  • 図書館(貸し借り)
  • ツタヤ
  • ゲーム(コンパス)
  • 勉強(spring,MyBaris)
12/24 13時30分 N/A
12/25 11時30分 N/A
  • ゲームやりすぎ(反省orz)
  • 読書-入門コンピュータ科学(ゲームしながらで集中できていなかったorz)
12/26 8時 3時
  • 通院-内科、皮膚科、歯科
  • ゲーム-コンパス
  • アニメ-宝石の国
  • 勉強-paiza-c言語
12/27 11時30分 N/A
  • ゲームやりすぎ(反省orz)
  • 読書-入門コンピュータ科学(ゲームしながらで集中できていなかったorz)
12/28 N/A N/A N/A
12/29 N/A N/A N/A
12/30 N/A N/A N/A
12/31 N/A N/A N/A
1/1 N/A N/A N/A
1/2 N/A N/A N/A
1/3 N/A N/A N/A
1/4 N/A N/A N/A
1/5 N/A N/A N/A
1/6 N/A N/A N/A
1/7 N/A N/A N/A
1/8 N/A N/A N/A
1/9 N/A N/A N/A

【めも】prometheus - mysqld_exporter(percona)の設定

      - job_name: 'mysql-hr'
    metrics_path: /metrics-hr
    static_configs:
      - targets: ['192.168.10.72:9104']

  - job_name: 'mysql-mr'
    metrics_path: /metrics-mr
    static_configs:
      - targets: ['192.168.10.72:9104']

  - job_name: 'mysql-lr'
    metrics_path: /metrics-lr
    static_configs:
      - targets: ['192.168.10.72:9104']

【めも】fluentd 設定

ファイルに出力されたMySQLのslow query logを、Elasticsearchに格納しGrafanaで閲覧するために必要なfluentdの設定

    
  @type mysqlslowquery_ex
  read_from_head
  path /mysql/MyHome/logs/slow_query.log
  tag mysqlslowquery.myapplication
  pos_file /var/log/td-agent/mysql-slow.log.pos
  last_dbname_file /var/log/td-agent/mysql-slow.log.lastdb



  @type typecast
  types datetime:time



  @type record_transformer #このフィルタでデータ型を変更しておかないと、抽出されたunixtimeが整数型として扱われwarningとなる
  enable_ruby
  
    hostname ${hostname}
    datetime ${time.strftime('%Y-%m-%dT%H:%M:%S%z')} # %zでタイムゾーンを認識させないとGrafanaでJSTのさらに9時間先を示してしまう。
  



  @type mysql_explain # 現状は、slow queryのログファイルに複数のDBが存在するケースではexplainが取れない。lastdbがDBを取得するように改善予定
  host 127.0.0.1
  port 5605
  database tpcc
  username root
  password root
  sql_key sql
  added_key explain



  @type sql_fingerprint
  fingerprint_tool_path /usr/bin/pt-fingerprint



  @type elasticsearch
  type_name myapp-mysqlslowquery
  host 192.168.10.32
  port 8092
  time_key datetime
  time_key_format %Y-%m-%dT%H:%M:%S%z
  logstash_format true
  logstash_prefix mysqlslowquery
  include_tag_key true

【めも】binlog shell

#!/bin/bash

grep -v "^SET\|latin1" ${1} \
        | grep -B 1 "^BEGIN\|^COMMIT" \
        | grep "^#[0-9]*" \
        | awk ' BEGIN{bt_cnt = 0; ct_cnt =0}
                {
                gsub("#","",$1);
                Y="20" substr($1,1,2);
                gsub(":"," ",$2);
                M=substr($1,3,2);
                D=substr($1,5,2);
                if (NR % 2 == 1){
                    bt =  mktime(Y" "M" "D" "$2);
                    ++bt_cnt;
                }else if (NR % 2 == 0) {
                    ct =  mktime(Y" "M" "D" "$2);
                    ++ct_cnt;
                }
                if (bt_cnt == ct_cnt) {
                     if ( ct - bt > 1){
                             print $0;
                     }
                }
        }'

PMM(Percona Monitoring and Management)でmetricsの取得ができなかった場合

PMMでメトリクスを取得できなくなってしまい、若干ハマったので記録する

グラフで取得対象に表示されていなかった

pmm-serverとの接続状況を確認する

[root@localhost docker]# pmm-admin list
pmm-admin 1.0.6

PMM Server      | 192.168.12.3
Client Name     | localhost.localdomain
Client Address  | 192.168.12.4
Service manager | unix-systemv  #CentOS7 だと linux-systemd

-------------- ---------------------- ------------ -------- ----------------------------------------- ---------------------
SERVICE TYPE   NAME                   CLIENT PORT  RUNNING  DATA SOURCE                               OPTIONS        
-------------- ---------------------- ------------ -------- ----------------------------------------- ---------------------
linux:metrics  localhost.localdomain  42000        NO       -                                                        
mysql:queries  localhost.localdomain  42001        NO       root:***@unix(/var/lib/mysql/mysql.sock)  query_source=slowlog
mysql:metrics  localhost.localdomain  42002        NO       root:***@unix(/var/lib/mysql/mysql.sock)                 

考えられる原因

ここまでに行ったこと

  • 設定ファイル "/usr/local/percona/pmm-client/pmm.yml" の編集(IPアドレスの変更)
  • クライアントの再設定
    [root@localhost docker]# pmm-admin config --server 192.168.12.3
    OK, PMM server is alive.
    
    PMM Server      | 192.168.12.3
    Client Name     | localhost.localdomain
    Client Address  | 192.168.12.4
        

試行錯誤一覧

  • クライアント設定のリペア ->効果なし
          [root@localhost docker]# pmm-admin repair
          No orphaned services found.
        
  • listen状況の確認
    [root@localhost docker]# netstat -tan
    Active Internet connections (servers and established)
    Proto Recv-Q Send-Q Local Address               Foreign Address             State
    tcp        0      0 127.0.0.1:42001             0.0.0.0:*                   LISTEN
    tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN
    tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN
    tcp        0      0 192.168.12.4:22             192.168.12.2:65278          ESTABLISHED
    tcp        0      0 :::22                       :::*                        LISTEN
    tcp        0      0 :::3306                     :::*                        LISTEN
        

    気になるこの42001はQANで使用しているポート

  • QANのログを確認
        [root@localhost docker]# less pmm-mysql-queries-42001.log
        ...skipping...
        # Version: percona-qan-agent 1.0.6
        # Basedir: /usr/local/percona/qan-agent
        # Listen:  127.0.0.1:42001
        # PID:     2262
        # API:     192.168.12.3/qan-api
        # UUID:    1e077f75b7c34601526d1383f7e04ac6
        2016/11/23 19:04:09.522733 main.go:165: Starting agent...
        2016/11/23 19:04:09.543769 main.go:343: Agent is ready
        2016/11/23 19:04:09.559502 status.go:51: listen tcp 127.0.0.1:42001: bind: address already in use
        

    すでに使われていると…

  • 対象サービスを削除
          [root@localhost docker]# pmm-admin rm mysql localhost.localdomain
    [linux:metrics] OK, removed system localhost.localdomain from monitoring.
    [mysql:metrics] OK, removed MySQL metrics localhost.localdomain from monitoring.
    [mysql:queries] Error removing MySQL queries localhost.localdomain: timeout 10s waiting on agent to connect to API.
    
    [root@localhost docker]# pmm-admin list
    pmm-admin 1.0.6
    
    PMM Server      | 192.168.12.3
    Client Name     | localhost.localdomain
    Client Address  | 192.168.12.4
    Service manager | unix-systemv
    
    -------------- ---------------------- ------------ -------- -------------------------------------------- ---------------------
    SERVICE TYPE   NAME                   CLIENT PORT  RUNNING  DATA SOURCE                                  OPTIONS
    -------------- ---------------------- ------------ -------- -------------------------------------------- ---------------------
    mysql:queries  localhost.localdomain  42001        NO       root:***@unix(/mysql/MyHome/tmp/mysql.sock)  query_source=slowlog
        

    なぜか、QANだけが残る…

  • QANのプロセスだけ削除
    [root@localhost docker]# pps -ef | grep percona
    root       1079      1  0 16:41 ?        00:00:13 /usr/local/percona/qan-agent/bin/percona-qan-agent -listen=127.0.0.1:42001
    
    [root@localhost docker]# p /usr/local/percona/qan-agent/bin/percona-qan-agent --help
    Usage of /usr/local/percona/qan-agent/bin/percona-qan-agent:
     -basedir string
           Agent basedir (default "/usr/local/percona/qan-agent")
     -listen string
           Agent interface address (default "127.0.0.1:9000")
     -pid-file string
           PID file
     -ping
           Ping API
     -version
           Print version
    
           [root@localhost docker]# pkill -15 1079
    
           [root@localhost docker]# ppmm-admin rm mysql
    [linux:metrics] OK, no system localhost.localdomain under monitoring.
    [mysql:metrics] OK, no MySQL metrics localhost.localdomain under monitoring.
    [mysql:queries] OK, removed MySQL queries localhost.localdomain from monitoring.
    
    [root@localhost docker]# ppmm-admin add mysql --password=root
    [linux:metrics] OK, now monitoring this system.
    [mysql:metrics] OK, already monitoring MySQL metrics.
    [mysql:queries] OK, now monitoring MySQL queries from slowlog using DSN root:***@unix(/mysql/MyHome/tmp/mysql.sock)
    [root@localhost.localdomain log]# pmm-admin list
    pmm-admin 1.0.6
    
    PMM Server      | 192.168.12.3
    Client Name     | localhost.localdomain
    Client Address  | 192.168.12.4
    Service manager | unix-systemv
    
    -------------- ---------------------- ------------ -------- -------------------------------------------- ---------------------
    SERVICE TYPE   NAME                   CLIENT PORT  RUNNING  DATA SOURCE                                  OPTIONS
    -------------- ---------------------- ------------ -------- -------------------------------------------- ---------------------
    linux:metrics  localhost.localdomain  42000        YES      -
    mysql:queries  localhost.localdomain  42001        YES      root:***@unix(/mysql/MyHome/tmp/mysql.sock)  query_source=slowlog
    mysql:metrics  localhost.localdomain  42002        YES      root:***@unix(/mysql/MyHome/tmp/mysql.sock)
         

これでメトリクスを取得し、グラフに表示できるようになった

Mroonga(ラッパーモード)のテーブルでalter tableを途中で停止したら、中間テーブルが残ってテーブルコピーを必要とするalter tableができなくなった話

起こったことはタイトルの通りなんですが、解決に至るまでの紆余曲折を書こうと思います。

 

環境

CentOS6.5

MySQL Community Edition 5.6-17

Mroonga 4.10

groonga ライブラリ 4.1

 

事象の再現方法

  1. Mroonga(ラッパーモード)でテーブルコピーが必要となるalter tableを実行する
  2. 処理中にCtrl-Cで中断する

 

解決に至る紆余曲折

  1. テーブルコピーを必要とするalter tableができる方法を探す
  2. 残存した中間テーブルを、テーブルスペースから消さなければいけないことを知る
  3. alter table <table name> discard tablespace やdrop table では削除できなく、再起動が必要なことを知る
  4. 再起動すると別のバク(#67179)を踏み抜く。
  5. しかも、踏み抜き方が悪かったのかWAがうまくいかない。具体的に言うと、初めに対象のテーブルをdropするのだがそこもうまくいかないし、dropした後にテーブルを再生成する工程でcreate tableもできなかった。
  6. そこでmysqldを再起動したらcreate tableできるようになったが、ほかのデータベースのテーブルがshow tables では見れるのに、開けない、という謎現象に遭遇。
  7. 公式マニュアルのinnodbトラブルシューティングを参考にするもにっちもさっちもいかず

解決方法

  1. 公式マニュアルのinnodbトラブルシューティングに残存した中間テーブルに関する記載を見つける
  2. マニュアル通りに進める。
  3. マニュアルには最終的に、その中間テーブルをdropできるような書き方がされているが実際には消せなかった。
  4. しかし、alter table はできるようになり、問題は解決。

それで中間テーブルはどうしたか、というとそのままです。

できれば消したかったのだけれど、再起動した際にその中間テーブルが見つからないとなっては嫌なので、残しています。教訓になりました。alter tableはコピーするだけだから問題ないと思っていたのになぁ('A`)

 

マニュアルの詳細は以下に譲ります。

MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.19.3 InnoDB データディクショナリの操作のトラブルシューティング