#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
タイトルのとおりですが、InnoDB は行ロックをかける事で有名ですが、行ロックをかけるには必ず INDEX が必要になります。 今回はその事について簡単にまとめようと思います。 行ロックがかからない例 まずは、行ロックがかからない例を書いてみます。 下記のような単純な test テーブルを用意します。 +----+--------+ | id | number | +----+--------+ | 1 | 1 | | 2 | 2 | | 3 | 3 | | 4 | 4 | | 5 | 5 | | 6 | 6 | | 7 | 7 | | 8 | 8 | | 9 | 9 | | 10 | 10 | +----+--------+
こんにちは、はらぐちです。 今回お話したいのは、mysqlのバックアップ方法についてのあれこれです。 バックアップ mysqldump mysqlのバックアップといえばmysqldumpです。 以下のような形で使います。 mysqldump -u root -p -x -A > my_dumpall.db これで全データベースのダンプができます。 特定のデータベースをダンプしたい場合は、以下のようにデータベース名を指定します。 mysqldump -u root -p -x データベース名 > dump.sql 定期的にバックアップを取りたい場合は、シェルスクリプトで以下のようなものを cronで実行してあげるといいでしょう。 二日間のバックアップを保持するスクリプト例です。 #!/bin/bash MPASS=パスワード mysqldump --defaults-extra-file=<
事象 MySQLのワークベンチでUPDATE文を実行すると、以下のエラーが発生した。 Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column To disable safe mode, toggle the option in Preferences -> SQL Editor and reconnect. 0.062 sec 原因 大量の(主キー以外の)update/deleteを誤って行えない様に制限してくれているため。 対応方法(一時的) SET SQL_SAFE_UPDATES = 0; 参考サイト http://rikutoto.blogspot.jp/2013/11/mysqlerror-code
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。先日親知らずを抜歯した時、つらすぎたので MySQL の JOIN のことを考えて心の平静を保っていました。 サイボウズの製品のひとつである kintone はニーズに応じて自由に業務アプリのようなものを手軽に作ることができ、データの検索条件やソート条件も細かくカスタマイズ可能で、様々なレベルでのアクセス権も設定可能という非常に便利なツールです。 しかしその機能を支える裏側では複雑なクエリが発行され、MySQL に多大な負荷をかけています。サイボウズのクラウドには数十テラバイトに登る MySQL データがあり、数千万件オーダーのテーブルを複数 JOIN するクエリが毎秒のように実行されるという、エンジニア魂が滾る環境です。 現在サイボウズでは性能改善に力を入れており、僕もその業務に従事しています。例えば2018年
MySQLのデータをCSVファイルに出力したい場合、 SELECT … INTO OUTFILE 構文を使うのがよくあるパターンなのですが、 DBサーバーがリモートホスト上にある場合はこの方法が使えません。 CSVファイルに出力するコマンド このコマンドで、リモートDBの結果をローカルCSVファイルに出力できます。 構文 mysql -u [ユーザー名] -p -h [DBサーバーホスト名] [DB名] -e "`cat [実行SQLファイル名]`" | sed -e 's/\t/,/g' > [出力CSVファイルパス] 実行例 $ mysql -u test -p -h dbhost testdb -e "`cat outcsv.sql`" | sed -e 's/\t/,/g' > /tmp/test.csv いろいろ調べた結果たどり着いたのが以上の方法です。 理由とか気にならない人は
※RDSは使っていません。 負荷を見てみる DBサーバーの負荷状況を見てみます。 当時の監視ツールの画像がないのですが、以下の状況でした。 LA(Load Average)が突き抜けている リクエスト数は「常識的に考えて」それほどでもない メモリの使用量にあまり変化がない swapはしていない ストレージ容量を結構食っている WEBサーバーから見れば、処理待ちのままプロセスが処理されていない典型的なパターンだったと思います。 DBサーバーとしては、LAに対し、メモリの使用量があっていないように思われました。 仮説 上記の状態から、仮説を立てます。 スロークエリ が頻発しているのではないか メモリ が正しく割り当てられていないのではないか 各種ログ の設定が適切ではないのではないか 仮説を検証することで、対策をしていきます。 設定を見直す 上記の仮説の設定は、MySQLの設定ファイルである「
各々のエンジニアが開発に使用するDockerやVagrant等内のデータベースって、あまりチューニングされていなかったりしますよね。 チューニングされているサーバーは、カーネルパラメータ含め多くのパラメータが調整されているので何が主要なポイントか分からない。 耐障害性を捨ててでも開発環境は速く。 そんな方のための開発環境用簡易チューニング記事です。 MariaDBは10.1(10.x系)を想定しています。 ※ちなみに筆者は価格の事を棚に上げればSQLServer(MSSQL)や PostgreSQLも9.4以降(特に9.5)なら好きですし、MariaDBはGalera Clusterがあるから好きです。 仕事ではAWSを扱う機会が非常に多いのでAmazon Auroraは外せません。 設定例メモリ1Gほどデータベースに割り当てる例です。 [mysqld] skip-name-resolve
みなさん、最近人生のパーティショニングしてますか? こんにちは、勝利です。 今回はMySQLのパーティショニングについて紹介させていただきます。 MySQLのパーティショニングとは? MySQL5.1ぐらいから使えるようになった、1つのテーブルを分割する機能。 テーブルを分割するので、格納できる根本的な容量の拡張や、やり方(Plunning)によっては高速処理を実現できます。 分割した際のデータ振り分け方法としては大体以下のような形があります。 RANGE ・・・ パーティションごとに範囲を指定して振り分ける LIST ・・・ パーティションごとに格納する値で振り分ける HASH ・・・ 1つのカラムの値を式の結果で振り分ける KEY ・・・ 1つ以上のカラムの値をMD5関数等で評価して分割する 使用するメリットとしては下記2点のようなことが考えられます。 メリット1 [高速化が見込める]
参考URL パーティショニングとは パーティショニングの種類 RANGE パーティショニング このタイプのパーティショニングは、指定された範囲に含まれるカラム値に基づいて、行をパーティションに割り当てます。 LIST パーティショニング RANGE によるパーティショニングに似ていますが、別個の値のセットのいずれかに一致するカラムに基づいて、パーティションが選択されます。 HASH パーティショニング このタイプのパーティショニングでは、テーブルに挿入される行内のカラム値を操作するユーザー定義式によって返される値に基づいて、パーティションが選択されます。関数は、負ではない整数値を返す MySQL の有効な式で構成できます。このタイプを拡張した LINEAR HASH も使用できます。 KEY パーティショニング このタイプのパーティショニングは、HASH によるパーティショニングに似ていま
2016年1月、Oracle Databaseのライセンス体系が変更され、最も安価だった中小規模システム向けの「Oracle Database Standard Edition One(以下、SE1)」が廃止。従来の「Oracle Database Standard Edition(以下、SE)」の内容を変更した新ライセンスである「Oracle Database Standard Edition 2(SE2)」に一本化されました。 例えば、約70万円だったSE1の最低価格は、SE2では210万円からと高額になります(2016年11月現在、以下同)。また、SEのユーザーとしても、物理サーバ単位の最大搭載CPUソケット数が、SEの4ソケットから、SE2では2ソケットに減ることから、システム環境によっては、より上位で570万円からとなる「Oracle Database Enterprise Ed
<Insert Picture Here> MySQLパフォーマンスチューニング概要 日本オラクル MySQL Global Business Unit Copyright© 2011, Oracle. All rights reserved. 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。 また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことは できません。以下の事項は、マテリアルやコード、機能を提供することをコミットメン ト(確約)するものではないため、購買決定を行う際の判断材料になさらないで下さ い。オラクル製品に関して記載されている機能の開発、リリースおよび時期につい ては、弊社の裁量により決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文
Full MySQL Support Sequel Pro is a fast, easy-to-use Mac database management application for working with MySQL databases. Perfect Web Development Companion Whether you are a Mac Web Developer, Programmer or Software Developer your workflow will be streamlined with a native Mac OS X Application! Flexible Connectivity Sequel Pro gives you direct access to your MySQL Databases on local and remote se
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗(?)でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう!!と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢(オトコ)のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負!!というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く