第 31 回 中国地方 DB 勉強会 in オンライン 2021/04/02
パスワードをゴニョゴニョする前に atsuizo.hatenadiary.jp で パスワードを生テキストで書くなって人はゴニョゴニョしてください。 って書いた話の件ですが、なんでこんな話になるの、ってところをまず押さえましょう。 mysqlクライアントでのログイン方法あれこれ 普通は、以下のように指定してログインを行うと、パスワードについてプロンプトがきて、そこで入力します。入力内容は見えないやつです。 (サンプル古くてすみません。5.6.23です。) $ mysql -u ユーザ -p -h 接続先 Enter passowrd: パスワードを入力してEnter Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 480 Server version: 5.6.23-l
I ran a mysql import mysql dummyctrad < dumpfile.sql on server and its taking too long to complete. The dump file is about 5G. The server is a Centos 6, memory=16G and 8core processors, mysql v 5.7 x64- Are these normal messages/status "waiting for table flush" and the message InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal mysql log contents 2016-12-13T10
MySQLではバージョン 5.7.8 以降でJSON型がサポートされるようになりました。 このシリーズでは基本編、パフォーマンス編、論理設計編と、JSON型のデータ操作方法やどのような場合に使用を検討するべきかをベンチマーク結果も踏まえて探っていきたいと思います。 MySQLでJSON型を使う(基本編) MySQLでJSON型を使う(パフォーマンス編) MySQLでJSON型を使う(論理設計編) 今回はJSON型を使った場合のパフォーマンスについて見ていきたいと思います。 検証マシンスペックとMySQLの設定 今回はAWSのEC2上にMySQL5.7.18を構築して検証を行いました。 マシンスペックは以下です。 インスタンスタイプ: t2.medium CPU: v2core メモリ: 4GB MySQLで設定変更したのは以下のみで、後はデフォルトです。 [mysql] [mysqld]
INSERT INTO `json_users` VALUES ('{"name": "tanaka", "gender": 1, "options": {"x": 100, "y": 200}}'), ('{"name": "yamada", "gender": 2, "options": {"x": 300}}'), ('{"name": "suzuki", "gender": 1, "options": {"x": 100, "y": 200, "z": [1, 3, 4]}}'); mysql> INSERT INTO `json_users` -> VALUES -> ('{"name": "tanaka", "gender": 1, "options": {"x": 100, "y": 200}}'), -> ('{"name": "yamada", "gender": 2,
MySQLのロック ロックとはトランザクションの並列度を上げる為の並列スケジューリング方法の一つ トランザクションをサポートしているデータベースにおいては、トランザクションの並列数を上げる事が性能アップの一つの方法。 他のトランザクションに更新して欲しくないデータだけにロックをかけて、ロックされたデータ以外を更新するトランザクションは並列で実行される。 Innodbは行ロック? Innodbは更新対象の行だけをロックする。と思っていると、意外な落とし穴にハマる。 その一つがギャップロック。 ギャップロックを実際に起こしてみる サンプルテーブル idとstrがあるだけのシンプルなテーブル。idがPKで1~5までは順番に、その後、10,20と飛んで行が入っている。 通常の行ロック トランザクション1 select for updateでid=2の行を明示的にロック トランザクション2 id=1
はじめに この記事は実際の業務で発生した MySQL のデッドロックとそのいくつかの回避方法や対応方法を(テーマは変えて)手元で実行できるコードを用いて解説する記事です。具体的には「トランザクション張っておけば大丈夫」と思ってませんか? バグの温床になる、よくある実装パターンの記事で紹介されている「1on1 チャットサービス」で紹介されているデッドロックとデータベースレイヤでは同じ状況だったのですが、記事で紹介されている方法とは別の方法でデッドロックを回避する必要があったため、同じ状況に遭遇した人の助けになればという思いで記事を書きました。また、こちらの記事が無ければ私自身も現象を理解するのにもっと苦労したと思うので、この場を借りてお礼申し上げます! 出金サービス履歴登録サービスを例に考える コードと説明が https://github.com/shuntagami/withdrawal_
yokuo825さんのカッコいいインタビュー記事を t.co 読んで、この部分ですね ──例えばどのような話をしましたか? 「インストールされたばかりのMySQLがあるとして、特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」と質問されたのを覚えています。 具体的にどのような理由でどのファイルにアクセスするか、一連の流れを片っ端から答えていくと、彼らがすごく楽しそうにしてくれて。「そうか、LINEの環境だと○○の設定が最初から○○になっているので、そのファイルへのアクセスは考えていなかったです。確かにそれもありますね」などと答えてくれました。 でこんなツイートしたんですが 全国のDBAは「特定テーブルに1件のレコードを最初にINSERTした場合、アクセスが発生するファイルとその理由をすべて教えてください」これ明日から職場で
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
あんまり知識ないけどがんばる SQLにも存在する様だけど, MySQLでしか経験がないからMySQLで書くよ 対象 以下に該当する方が対象です。 ある程度, SQLクエリが読める ある程度, DBの知識がある 背景 資料を探せど探せど, (個人的に)良いドキュメントが見つからなかったので 『じゃあ書いちゃおう』と思いました。 ※悪い資料だらけってわけじゃないけど, 物足りないとか惜しい記事ばかりだったので。 ストアドプロシージャって? DB上での一連処理に, 名前をつけて関数のように, 呼び出して使用できるもの。 DB上で動作を完結させちゃうから, 開発言語に依存しないよ! Ruby とか PHP だとか Perl でも Python だろうと CALL できれば結果は同じになるはずだよ! 権限まわり 作成
CREATE TABLE tbl_unique_test ( id INTEGER NOT NULL, value INTEGER NOT NULL DEFAULT 0, PRIMARY KEY (id) ); 挿入してみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); Query OK, 1 row affected (0.50 sec) 同じクエリをもう一回叩いてみます。 mysql> INSERT INTO tbl_unique_test VALUES (1,1); ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY' はい。 IGNORE を指定してみます。 mysql> INSERT IGNORE INTO tbl_unique_test VALUES (1,1)
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan(以下AAJ)とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語(繁体字)、中国語(簡体字)、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 (サーバー構成は後に記述
Many of you have probably already heard about the new vulnerability affecting most existing MySQL forks and versions. The bug has been patched in some of the most recent MySQL and Percona Server releases and so, at least in theory, all it takes to apply a fix is to update the MySQL or Percona Server packages to their latest versions. However, it would likely require a database restart and restarts
CVE-2016-6662 MySQL Remote Root Code Execution / Privilege EscalationについてMySQL 免責 取り敢えずわかっている範囲で書いただけなので、手元で再現やパッチの正当性は確認していません。 自己責任でどうぞ。 これ(2016/09/22 22:00)以降新しい情報が出てきても、おそらくもう更新しません。 CVE-2016-6662 についてはこちら MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響 - ITmedia ニュース oss-sec: CVE-2016-6662 - MySQL Remote Root Code Execution / Privilege Escalation ( 0day ) この脆弱性を再現させるために必要なもの (未検証) 5.5.52, 5.6.33, 5.7.15は影響を
概要 Dockerコンテナ内にmysqlサーバを立てます。 mysqlアカウントを作成したり、mysqlサーバを外部に公開することも行います。 動作確認を行った環境は、ホストOS, コンテナOSともにCentOSです。 そもそもDockerとは 仮想環境構築に docker を使う - apatheia.info を読んでください! Dockerfile さっそくですが、以下が Dockerfile です。 コンテナイメージを作成するために必要なファイルです。 # DOCKER-VERSION 0.3.4 FROM centos:6.4 # ここは自由に変えてください MAINTAINER Taro Tanaka # パッケージインストール RUN yum install -y mysql mysql-server # mysqlサーバのセットアップ RUN echo "NETWORKIN
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く