タグ

mysqlに関するigaiga07のブックマーク (49)

  • https://support.cpanel.net/hc/en-us/articles/4419382481815-MySQL-GPG-keys-expired-preventing-installation-upgrade-of-MySQL-packages-from-the-official-repository-

    igaiga07
    igaiga07 2022/02/10
    何かMySQLインストール出来ないとおもったらこれか・・・
  • SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる

    最近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

    SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
  • MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)

    どうも、今日も今日とて野毛で飲みながらブログを書いている@0kawaraです。 今日は、普段あまり意識してこなかったMySQLのInnoDBでのロックの振る舞いについて色々実験してみました。(もちろん、きっかは自分がドツボにはまったから) ちゃんと理解するためには「共有・排他的ロックとは」って話や、「行ロックってつまりインデックスレコードロックだよね」などの話とか理解する必要があるんですが、それは github.com をちゃんと一読してもらえれば十分かと思います。 (というか、これが問題なく読めて理解できる人はこの記事読む必要ない….) 以下は上のドキュメント含め関連する記事などを読んで自分でInnoDBの行ロック周りについて、というかSELECT FOR UPDATEについて理解を深めるために手元で実験したことのまとめです。 技術的にちゃんとした理解を深めたい人は最後にまとめた参考サイ

    MySQLでSELECT FOR UPDATEと行ロックの挙動を検証してみた - Continue(s)
  • MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に

    MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に 前バージョンのバージョン番号は5.7で、バージョンが8.0になったのは、過去のバージョン番号で6が使われたことがあったというMySQL のバージョンの都合や、MySQL Clusterがバージョン7であることなどを考慮したためとされています。 MySQL 8.0では、大幅な性能向上、JSONデータに対応したNoSQL機能の搭載、地理情報の対応、ロールによるユーザー権限など、さまざまな改善が行われています。 性能が最大で2倍に MySQL 8.0では、MySQL 5.7と比較してユーザー数が増えた場合に最大で約2倍ほどの大きな性能向上を実現しています。下記は読み込み性能の比較です。 読み込みだけでなく書き込み性能も向上しており、これはInnoDBでREDOログ

    MySQL 8.0正式版がリリース。性能が最大で2倍、JSONデータや地理情報などサポート。ロールによるユーザー権限の管理も可能に
  • MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる

    仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO

    MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
  • MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響

    攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 米Oracle傘下のオープンソースデータベース「MySQL」に未解決の脆弱性が見つかったとして、セキュリティ研究者が9月12日に概略やコンセプト実証コードを公開した。サイバー攻撃に利用された場合、root権限で任意のコードを実行され、サーバを制御される可能性が指摘されている。 研究者のDawid Golunski氏が公開した情報によれば、MySQLの脆弱性は複数発見され、、中でも特に深刻な1件については、リモートの攻撃者がMySQLの設定ファイルに不正な内容を仕込むSQLインジェクション攻撃に利用される恐れがある。 この脆弱性は、MySQLの最新版を含む5.7系、5.6系、5.5系の全バージョンに、デフォルトの状態で存在する。現時点でOracle MySQLサーバの脆弱性修正パッチは存在

    MySQLに重大な脆弱性見つかる、パッチ存在せずデフォルトで影響
  • InnoDBのオプティマイザとロックの範囲の関係 - addsict's blog

    MySQLのInnoDBのロックの挙動を色々調べていたのですが、レコードの数によってロックの範囲が変わる現象に頭を悩まされたので、メモがてら少しまとめてみます。 どこまでロックする? 以下のようなテーブルがあるとします。 id列に1〜6までの数値が入っています。 CREATE TABLE t ( `id` int unsigned NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB; INSERT INTO t VALUES (1),(2),(3),(4),(5),(6); ではidが3より小さなレコードを取得するクエリを投げると、どのレコードをロックするでしょうか。 BEGIN; SELECT id FROM t WHERE id < 3 LOCK IN SHARE MODE; 1〜2のレコードでしょうか。それとも1〜3までロックするでしょうか。 実

    InnoDBのオプティマイザとロックの範囲の関係 - addsict's blog
  • InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ@日記

    はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー`)ノ 〜 私がMySQLで えっ?! っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう! http://

    InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ@日記
  • InnoDBのネクストキーロックによるデッドロックの例 - iakioの日記

    あまりMySQLのことは自信ないですが。 一見問題なさそうに見える操作でデッドロックしてしまうケースがあったので動画にしてみました。 SELECTしてみて「有ればUPDEATE、無ければINSERT」や、あるいは「有れば何もせず、無ければINSERT」を行ないたい場合に、SELECT FOR UPDATEして無ければINSERTとしてしまうと、動画の最初の例のようにデッドロックしちゃいます。存在しない行に対してSELECT FOR UPDATEするとちょっと広めに行ロックがかかってしまう感じでしょうか。 「有ればUPDATE、無ければINSERT」であれば、INSERT ... ON DUPLICATE KEY UPDATEを使うのが良さそう。「有れば何もせず、無ければINSERT」なら、いきなりINSERTしてみて一意制約違反ではじいてもらうのがいいのかな。 動画の2つめの例は、i =

    InnoDBのネクストキーロックによるデッドロックの例 - iakioの日記
  • Joomla!の「ゼロデイコード実行脆弱性」はPHPの既知の脆弱性が原因

    Joomla!にコード実行脆弱性(CVE-2015-8562)があり、パッチ公開前から攻撃が観測されていたと話題になっています。 Joomlaに深刻な脆弱性、パッチ公開2日前から攻撃横行 「Joomla!」に再び深刻な脆弱性、3.4.6への速やかなアップデートを推奨 パッチ公開の前に攻撃が始まる状態を「ゼロデイ脆弱性」と言いますが、それでは、この脆弱性のメカニズムはどんなものだろうかと思い、調べてみました。 結論から言えば、この問題はJoomla!側に重大な脆弱性はなく、PHPの既知の脆弱性(CVE-2015-6835)が原因でしたので報告します。 exploitを調べてみる 既にこの問題のexploitは公開されていますが、悪い子が真似するといけないのでURL等は割愛します。以下のページでは攻撃の原理が説明されています。 Vulnerability Details: Joomla! Re

  • Column SQL Truncation脆弱性にご用心

    前回のブログ記事「CMS四天王のバリデーション状況を調査したところ意外な結果になった」にて、JoomlaとMovableTypeは長大なログイン名を登録することにより、ログイン名の重複が起こり得ることを指摘したところ、facebookの私のウォールにて、Column SQL Truncation脆弱性の話題になりました。Column SQL Truncationは、2008年にWordPressの脆弱性として報告されたことがあります(参照、参照)。 稿では、簡単なログイン機能のSQL呼び出し例を用いてColumn SQL Truncationを説明したいと思います。 認証用テーブル定義の説明 認証に用いる会員テーブルを下記とします。ご覧のように、ログイン名を示す列 username には一意制約がありません。(追記)一意制約はふつうあるだろと思われるでしょうが、CMS四天王の中で一意制約

  • MySQL と寿司ビール問題 - かみぽわーる

    MySQL と Unicode Collation Algorithm (UCA) - かみぽわーる に関連するトピックで、 MySQL には寿司ビール問題というのがある。 寿司ビール問題どっかで詳しくお話を聞くべきだよなぁ。。。— RKajiyama (@RKajiyama) March 18, 2015 これはどういう問題かというと、 MySQL の Unicode では binary collation にしてコードポイントで比較しないと🍣と🍺に限らず絵文字が同値判定されるという問題です。 あれ? MySQL の utf8mb4 charset って、4バイト文字同士を比較すると同じ文字扱いされる? SELECT '🍣'='🍺' → 1 MySQL的には寿司とビールは同じ扱い。— とみたまさひろ (@tmtms) December 22, 2014 MySQLで select

    MySQL と寿司ビール問題 - かみぽわーる
  • 20140518 JJUG MySQL Clsuter as NoSQL

    (in Japanese)2014年5月18日のJJUG CCCにて「R2-3 Cluster/J で MySQL Cluster をトランザクション対応 NoSQL として使う」で利用したプレゼンテーションです。

    20140518 JJUG MySQL Clsuter as NoSQL
  • 長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場

    (2014.12.3追記:このblogの内容は、以下の書籍にも反映させた。) SQLレベルの差異 MariaDB5.5とMySQL5.5ではSQLレベルでの違いはほとんどなかった。autoincrementの最大値の扱いくらい。 ただし、MariaDB10.0でREGEXPがマルチバイト対応になったので、アプリ側は注意。 項目 MySQL MariaDB Autoincrement 最大値に達すると、以降は最大値を繰り返す。Warningのみ。エラーにならない。tinyintなら…,125,126,127,127,127… 最大値-1まで。以降はエラーを返す。tinyintなら…,125,126,ERROR,ERROR,… EXPLAIN文 JSON形式 バージョン5.6から 未対応 Optimizer Trace バージョン5.6から 未対応(ただし、MariaDBのほうがオプティマイザ

    長年の議論に終止符 -- MySQLとMariaDBの違い一覧 - 技術メモ置き場
  • MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録

    トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス

    MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
  • MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ

    もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました(と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです) 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその

  • MySQL 5.1のプロダクトライフサイクルが終了 - SH2の日記

    2013年12月31日をもってMySQL 5.1のプロダクトライフサイクルが終了しました。今後MySQL 5.1に対して新たな不具合や脆弱性が見つかっても、開発元による修正は行われません。現在もMySQL 5.1を使用している場合は、MySQL 5.5/5.6へ計画的にバージョンアップをされることをおすすめいたします。 ライフタイム・サポート リリース GA日 Premier Support終了 Extended Support終了 Sustaining Support終了 MySQL 5.0 2005年10月 2011年12月 Not Available Indefinite MySQL 5.1 2008年12月 2013年12月 Not Available Indefinite MySQL 5.5 2010年12月 2015年12月 2018年12月 Indefinite MySQL

    MySQL 5.1のプロダクトライフサイクルが終了 - SH2の日記
  • MySQL 5.6正式版が公開。オプティマイザやInnoDBの向上でさらに高速。クラッシュセーフなレプリケーションなど

    MySQL 5.6正式版が公開。オプティマイザやInnoDBの向上でさらに高速。クラッシュセーフなレプリケーションなど 米オラクルは、MySQL 5.6の正式版が公開されたことを発表しました。MySQLはオープンソースのデータベースで、無料で利用可能なMySQL Community Server 5.6.10も公開されています。 MySQL 5.6のおもな新機能はプレスリリースやドキュメント「What's New in MySQL 5.6」で紹介されています。記事ではこれらと、オープンソースカンファレンス 2012 Tokyoで公開された日オラクル 山崎由章氏の資料「圧倒的な進化を続けるMySQLの最新機能」(PDF)の一部を引用しつつ主な機能を紹介します。 オプティマイザ、InnoDB、レプリケーション MySQL 5.6では、SQLを解析して実行するオプティマイザの改善と、データベ

    MySQL 5.6正式版が公開。オプティマイザやInnoDBの向上でさらに高速。クラッシュセーフなレプリケーションなど
  • MySQLトラブルシューティング

    OracleMySQL担当サポートエンジニアを長年務める著者による、MySQLのトラブル解決のための決定版。著者はどこで問題が起こりやすいか、ユーザがどこで躓くかを熟知しており、6年にわたるテクニカルサポートの経験に基づいた実践的で現場指向の内容となっています。現場の生きた経験を反映した実践的なコンテンツは、MySQLを使うシステムに関わっている中級以上の開発者、運用担当者にとって福音となる一冊です。 序文 はじめに 1章 基テクニック 1.1 構文の間違い 1.2 SELECTの結果が間違っている 1.3 直前の更新に問題があるかもしれない 1.4 クエリに関する情報を取得する 1.5 データからエラーの原因を遡る 1.6 クエリが遅い 1.6.1 EXPLAINの情報をもとにクエリを調整する 1.6.2 テーブルの調整とインデックス 1.6.3 いつ最適化を終わりにするか 1.6.

    MySQLトラブルシューティング
    igaiga07
    igaiga07 2012/10/01
    @弊社 買っとけ
  • MySQL 5.5.6-rcリリース - SH2の日記

    2010年9月にMySQL 5.5.6-rcがリリースされ、リリース候補版となりました。現在MySQLの最新バージョンは5.1ですが、5.2〜5.4は欠番となり、5.5が次のメジャーバージョンとなります。 MySQL 5.5の新機能は各所で紹介されているので、以下のウェブサイト、資料をご覧ください。 開発中のMySQL 5.5、デフォルトエンジンはInnoDB、200%の性能向上。「MySQL Conference & Expo」基調講演で紹介 - Publickey MySQLコミュニティ騒然!MySQL 5.5.4が与えるインパクト。 - 漢(オトコ)のコンピュータ道 MySQLの次期バージョンMySQL5.5について(PDF) - OSC 2010 Nagoya 以前MySQL 5.1.35とMySQL 5.1.42のときにMySQLのバグ曲線を描いてみたのですが、MySQL 5.5

    MySQL 5.5.6-rcリリース - SH2の日記