1 Minute Tips

投稿者: sumito.tsukada

  • ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1

    ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ” at line 1

    はじめに

    mysqldumpで取得した結果を、そのままmysqlへ流しこもうとしたらエラーになった。

    実施したコマンド

    変数には適宜設定値が入る。

    やりたいことはmysqldumpでデータを取得し、標準出力で別のサーバへ流し込む。

    mysqldump -u$dbbackupuser $dbbackupname $table -h$dbbackuporiginal -p$dbbackuppass | mysql -u$dbrestoreuser -h$dbrestoreserver -p$dbrestorepass $dbrestorename

    発生したエラー

    ERROR 1064 (42000) at line 101: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

    原因

    mysqldumpコマンドはデフォルトでmysqlの独自構文が入ってしまうことがあり、微妙なmysqlのversionの差異がこの独自構文を受け付けないことがある。

    対処

    ANSIフォーマットで出力させるオプション “` –compatible=ansi “` を追加する

     after

    mysqldump --compatible=ansi -u$dbbackupuser $dbbackupname $table -h$dbbackuporiginal -p$dbbackuppass | mysql -u$dbrestoreuser -h$dbrestoreserver -p$dbrestorepass $dbrestorename

     

  • gitのリポジトリの引越しをする

    gitのリポジトリの引越しをする

    はじめに

    リポジトリが肥大化したり、プロジェクトが大きくなり、サービス名が変わったり、プロジェクトを進めていくといろいろなことがある。

    リポジトリの移行方法をまとめる。

    移行元(gitlab) -> 移行先(gitlabの別プロジェクト

    before projectからgit cloneする

    % git clone --mirror git@git.hoge.com:before/beforeproject.git
Cloning into bare repository 'beforeproject.git'...

    移行先のプロジェクトへgit pushを行う

    % git push --mirror git@git.sumito.com:after/afterproject.git
Counting objects: 1381, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (520/520), done.
Writing objects: 100% (1381/1381), 266.47 KiB | 88.82 MiB/s, done.
Total 1381 (delta 629), reused 1381 (delta 629)
remote: Resolving deltas: 100% (629/629), done.%

    最後に

    今回はgitlabのプロジェクトからgitlabですが、gitlabからgithubのような場合も同様の手順でいけます。

  • CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    はじめに

    fargateでタスクを登録し、起動させた時エラーが発生。原因と対処をまとめる

    An error occurs when a task is registered and started with fargate. Summarize causes and actions

    原因

    CannotStartContainerError: API error (500): failed to initialize logging driver: failed to create Cloudwatch log stream: ResourceNotFoundException: The specified log group does not exist. status code: 400,

    CloudWatch のロググループが存在しない

    CloudWatch log group does not exist

    対処

    CloudWatchにロググループを作成する

    Create a log group in CloudWatch

    その後、再度タスクを実行すれば問題は解消できる。

    After that, the problem can be solved by executing the task again.

     

  • nodeのversion管理をnvmで行う

    nodeのversion管理をnvmで行う

    はじめに

    Linux/Macにてnodeのversion管理を手軽に行うよう、nvmで切り替えれられるようにする

    nvmインストール

    nvmのオフィシャルリポジトリはこちら

    https://github.com/creationix/nvm

    ここに記載があるように、installを行う。

    curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.34.0/install.sh | bash

    ~/.bash_profileに環境変数を追加する

    export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

    変更した~/.bash_profileを読み込む

    source ~/.bash_profile

    stableをインストール

    nvm install stable

    を行うと、stableをインストールすることが可能。

    執筆時のversionは以下の通り

    # node -v
v11.12.0

    任意のversionをインストール

    nvm ls-remoteコマンドを実施すると、インストール可能なversionが列挙される

    # nvm ls-remote
        v0.1.14
        v0.1.15
        v0.1.16
        v0.1.17
        v0.1.18
        v0.1.19
        v0.1.20
        (略)

    version 8.9.4をインストールする際は以下の通り実施する

    nvm install v8.9.4

    aliasを切り替える

    # nvm alias default v8.9.4
default -> v8.9.4

    version変更を確認

    # node -v
v8.9.4

     

  • mysql 5.7で実行された全クエリをログに出力する

    mysql 5.7で実行された全クエリをログに出力する

    はじめに

    どのようなクエリが実施されたのかトレースする時に使う

    設定

    /etc/my.cnfの設定変更

    general_log=ON
general_log_file=/var/log/mysqld-query.log

    general_logの記載を追加する

    パーミッション設定

    touch /var/log/mysqld-query.log
chown mysql:mysql /var/log/mysqld-query.log
chmod 640 /var/log/mysqld-query.log

    上記設定を入れたら再起動する

    systemctl restart mysqld

    確認

    cat /var/log/mysqld-query.log

2019-03-14T05:39:18.710354Z	    3 Query	INSERT INTO s_bookmark (  id, bookmark_at,

     

     

  • wordpressのDBをRDSに移行する

    wordpressのDBをRDSに移行する

    はじめに

    wordpressは1台のマシンにmysqlも、wordpress自体もinstallすることはよくあると思う。

    その状態からmysqlをRDSに移行する。

    multi-AZを使うことができるので、DBの可能性が向上するというメリットがある。

    前準備

    mysqlをdumpする

    mysqldump -uroot -p sample_wpdb > sample_wpdb.sql

    移行

    RDSを作成する。

    userを作成する

    RDSを作った際のroot権限を持ったIDでも可能だが、セキュリティを考慮し、1 wordpressあたり、1 user作成すると良いと思う。

    ユーザ作成

    sampleuserを作るとする

    パスワードはpassword123

    database名はsample_wpdb

    SELECT PASSWORD('password123');

GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,ALTER,INDEX,DROP,LOCK TABLES
ON sample_wpdb.*
TO 'sampleuser'@'%' IDENTIFIED BY PASSWORD '*xxxxxxxxxxx';

     

    dumpファイルを読み込む

    mysql -uroot -ppassword123 -hsample.ap-northeast-1.rds.amazonaws.com  sample_wpdb < sample_wpdb.sql

    wordpressの設定ファイルでDBの設定を変更

    wp-config.php 

    /** WordPress のためのデータベース名 */
define('DB_NAME', 'sample_wpdb');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'sampleuser');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password123');

     

    以上。

     

     

     

     

  • BigQueryのtimestampをUTCから日本時間JSTへ変更する

    BigQueryのtimestampをUTCから日本時間JSTへ変更する

    はじめに

    BigQueryのtimestampの戻り値はデフォルトでUTCである。

    クエリを修正することでJSTを表示できる。

    クエリ

    #standardSQL

select
created_at as UTC,
FORMAT_TIMESTAMP('%Y-%m-%d %H:%M:%S', created_at, 'Asia/Tokyo') AS JST

from `BQ.sample`

    結果

    参考情報

    ビッギデータ解析について分かりやすくまとまっているのでおすすめ。

  • EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    EC2(Amazon Linux 2)のディスクサイズをオンラインで拡張する

    作業前

    ディスクサイズを確認する

    $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       20G   20G  291M  99% /

    Elastic block storeで割り当てDISKを増やす

    何ギガに増やしたいのかサイズを指定する

    （増やす容量ではなく、現在のDISKと併せてトータルの容量にする）

    ブロックデバイスの変更作業

    ブロックデバイスの一覧を表示する

    $ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  40G  0 disk 
└─xvda1 202:1    0  20G  0 part /

    ブロックデバイスを拡張する

    （ここの手順がAmazon Linux1と2で異なる）

    以下の手順はAmazon Linux2。

    $ sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=41938910,end=41943006 new: size=83881950,end=83886046

    ブロックデバイス一覧を表示する。

    変更された事を確認する。

    $ lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  40G  0 disk 
└─xvda1 202:1    0  40G  0 part /

    パーティションを拡張する

    $ sudo xfs_growfs /dev/xvda1
meta-data=/dev/xvda1             isize=512    agcount=11, agsize=524159 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=5242363, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 5242363 to 10485243

    パーティションが拡張された事を確認する

    $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       40G   20G   21G  50% /

    参考情報

    https://dev.classmethod.jp/cloud/aws/expand-ebs-in-online/

     

  • go routine/channelを整理する

    go routine/channelを整理する

    go routineのchannelについて勉強したので整理する

    package main

import (
	"fmt"
)

// sliceとchannelを受け付ける
func goroutine(s []int, c chan int) {
	sum := 0
	for _, v := range s {
		sum += v
	}
	// channelに送信
	c <- sum
}

// channel

func main() {
	// スライスのinteger
	s := []int{1, 2, 3, 4, 5}
	// channel (makeで書く)
	// makeはキューの働きをする
	c := make(chan int)
	go goroutine(s, c)

	// チャネルを受信。ブロッキングの役割があるので、入ってくるまでずっと待っている状態
	x := <-c
	fmt.Println(x)
}

    結果 “` 15 “`

  • wordpressをLoadBalancer配下にインストールする

    wordpressをLoadBalancer配下にインストールする

    はじめに

    WordPressをインストールする際、ブラウザ越しにポチポチする必要がある。

    しかし、既にLoadBalancerの配下にサーバが存在していて、

    LoadBalancerがHTTPSを受け止め、内部的にHTTPで通信している環境ではこのインストールが非常に悩ましい。

    対処

    この場合bastionサーバ（踏み台サーバ）を利用しプロキシさせる事でHTTPでブラウザ越しに接続する事ができる

    ssh -L Proxyポート:接続先サーバのIP:接続先サーバのPort bastionサーバ

# ex) ssh -L 8080:wordpress-server:80 bastion.sumito.jp

    これで自分の端末とbastionサーバ(踏み台サーバ)がトンネリングを張ることができる。

    自身の端末のブラウザでproxy設定をする

    また、wordpressのインストールの際は、HTTPのリクエストヘッダが重要になる。

    /etc/hostsに以下を記載

    127.0.01    FQDN

# ex) 127.0.0.1   wordpress.sumito.jp

    ブラウザで wordpress.sumito.jp へ接続する事でインストール画面になる。