bundle upgradeにてmysqlが8になってしまった時の対処方法

brewコマンドでアップグレードしてしまった時に、動かなくなりました。

エラー内容はこんな感じです。

dlopen(/Users/xxxx/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle, 9): Library not loaded: /usr/local/opt/mysql/lib/libmysqlclient.20.dylib (LoadError)
  Referenced from: /Users/xxxx/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle
  Reason: image not found - /Users/xxx/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/mysql2-0.5.3/lib/mysql2/mysql2.bundle

libmysqlclient.20.dylib\

mysql8になると、↑の２０のところが２１になるようですね。

直した時のコマンドはこんな感じでした。

brew uninstall mysql

brew install mysql@5.7


bundle exec gem uninstall mysql2

rbenv exec bundle config --local build.mysql2 "--with-ldflags=-L/usr/local/opt/openssl/lib --with-cppflags=-I/usr/local/opt/openssl/include"

or 

bundle install

mysqlのバージョンをチェック

mysql --version

ref

https://note.com/shoki_rails/n/nf7b51ba48084

posgresqlが起動しない時の対処方法

下記エラーがでてうまく動かない時の対処方法

PG::ConnectionBad: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

結論

versionが１０で古かったので、１２にあげたら動きました。

xxxx [master=]$ postgres -D /usr/local/var/postgres
2020-07-05 20:51:03.344 JST [4538] FATAL:  database files are incompatible with server
2020-07-05 20:51:03.344 JST [4538] DETAIL:  The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 12.3.

brew postgresql-upgrade-database

直らない

rm /usr/local/var/postgres/postmaster.pid

そのリポジトリには秩序があるか？

**個人のメモ書きです。

いろんな案件に参加していると、ルールが明確化されているプロジェクトもあればされていないプロジェクトもあり、様々である。

そんなカオスな中、リポジトリ 、組織に秩序をどう導入していくかはいつだって課題にあがる内容だと思う。

秩序やルールがあると何が嬉しいのか

別になくたっていいじゃん、という意見もあるだろうが、基本的には秩序がある方がよいと思う。

• 第三者がみてわかる
• 属人化しない
• 技量によらずある一定の質に保たれる
• ミスが検知しやすい

Ruby on Railsは規約が厳しめのフレームワーク。設定より規約という理念で作られている。

まさにそういう秩序があることでどこに何があるのかを把握しやすいし、それぞれ役割が明確化されている。

誰が、どのタイミングで、どのようにやっても一定のラインで開発できることがメリットとして大きいと思う。

そう思うと、組織が大きかったりレベル感がバラバラだったりすると効果的に思う。

個人の開発であれば、その本人が把握していれば極論どうだっていいのかもしれない。

どうやって導入するか

納得感をもって導入できればいいけど、そんなケースばかりでないようにも思う。

そうなってくると、導入する理由、メリット・デメリットをきちんと共有した上で、一回やってみる、という精神が大切な気がする。

やってみてわかることも大いにあるだろうし、無秩序でそのまま放置するよりはなにかしら良いことがあると思う。

人数が多くなればなるほど決めにくさは増すような気もする。

そうなってくるとどうやって意思決定するのがいいのか難しい。

やはりまとめている役割のメンバが少人数で議論した上で決めきってしまうのが、早く、確実な方法な気がする。

database.ymlについて理解する

Ruby on Railsを利用していると必ず確認するファイルがdatabase.ymlです。

新しい環境でプログラミングを始めるときに設定するか、確認することが多いと思います。

お手伝い先でtest先のdatabaseを設定したりする機会があり、理解が浅いなと感じたため勉強がてらメモとして残しておきます。

database.ymlの役割

その名の通りですが、databaseの接続先に関する設定ファイルです。

ruby側、Ruby on Railsがどこのdatabaseに接続するかをこのファイルを参照します。

productionであれば、そちらを、localであればlocalの環境のdatabaseをみにいくことになります。

それぞれの項目

adapter

mysql2や postgresqlなどのデータベースの種類を記載します。

pool

コネクション数の上限

database

DB名

username

接続に使用するユーザの名前

password

接続する際に利用するパスワード

host

host名

port

ポートを指定

デフォルトの設定はこちら

MySQLでは3306

PostgreSQLでは 5432

portは扉の概念で説明されていることが多いですね。

hostやドメインは番地なので、住所っぽく例えるなら

マンションなどを指定がexample.comとすると、portが部屋番号のような役割ということですね。

普段あまり意識しませんが、大切なことだなと思いました。

Railsでの運用

基本的にdatabase.ymlはgithubなどのバージョン管理サイトにアップします。 なので、直接接続先のホストやpasswordを書くとセキュリティ的に問題です。

極論データを書き換えたりもできてしまう可能性があるので。

なので、環境変数を利用するなどして、第三者に漏れないようにする必要があります。

参考

https://toomeeto.hatenablog.com/entry/2019/07/07/025205#:~:text=database.yml%E3%81%A8%E3%81%AF%E2%80%A6,%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%A8%AD%E5%AE%9A%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%80%82&text=database.yml%20%E3%81%AE%E4%B8%AD%E3%81%A7%E3%81%AF,%E3%81%8C%E8%A8%98%E8%BF%B0%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%80%82

FTPツールを使ってLight Sailのインスタンスに接続する

背景

wordpressの画像を抜き出したい。 が、エクスポートできないし、ファイルごとバックアップをzipで作ってもダウンロード中にエラーがでてちゃんとダウンロードできない。

FTPツールでダウンロードするしかなくなった。

手順

https://lightsail.aws.amazon.com/ls/docs/ja_jp/articles/amazon-lightsail-connecting-to-linux-unix-instance-using-sftp

ほぼこれです。

filezilla

ここからダウンロード https://filezilla-project.org/download.php?show_all=1

注意点

ユーザに bitnamiの Certified by Bitnami インスタンス : bitnamiを指定すること。

みてた記事

https://kabeto.net/2019/10/24/backwpup_networkerror/

localはdockerでMySQLでCircleCIでもRspecを実行する時の注意点

手元のローカルのためのdatabase.ymlとci上で利用するdatabase.ymlは分けたという記事

認識

localで立てたdockerのmysqlと ciでimageで引っ張ってくるmysqlは当然ながら設定が違う。

できるだけ同じようにしておくことが望ましいと思うが、 異なるケースもあるはずなので、それぞれで対応させる必要がある。

手元の環境でrspecを実行する

portの指定やpasswordの指定がある。

docker-compose.ymlの設定をチェックしよう。 portやパスワードを要チェック。

ci

database.yml.ci を用意して、 ciの途中でmvを実行させて上書きする。

run: mv config/database.yml.ci config/database.yml

portなどが異なっているか確認。

      - image: circleci/mysql:5.7
        environment:
          - MYSQL_ALLOW_EMPTY_PASSWORD: 'true'
          - MYSQL_ROOT_HOST: '%'

とかならパスワードはなくてとおる。

例

test:
  adapter: mysql2
  encoding: utf8
  pool: 5
  username: 'root'
  host: '127.0.0.1'
  database: test_ci

ref

https://qiita.com/AK4747471/items/b2161784065f21cd1645

seed.rbでテーブルの初期化をする 【MySQL】

rails db:seedをした時に毎回テーブルの中身を初期化する処理を書く。

code

ActiveRecord::Base.establish_connection

ActiveRecord::Base.connection.disable_referential_integrity do
  ActiveRecord::Base.connection.tables.each do |table|
    next if table == 'schema_migrations'

    ActiveRecord::Base.connection.execute("TRUNCATE TABLE `#{table}`")
  end
end

table周りの処理で `を書くと、予約語にバッティングしているテーブルがあっても削除できる。 sqlの処理としてぶつからない。