MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
Percona Toolkit
All of Percona’s open source software products, in one place, to download as much or as little as you need.
カジュアルに MySQL を監視する方法 | Carpe Diem
このエントリーは、MySQL Casual Advent Calendar 2011 – MySQL Casual の第 19 日目のエントリーです。 皆さんこんにちは、n0ts こと、Naoya Nakazawa です。 今日は、みなさん日頃からカジュアルに MySQL を運用して、日々生活されていることと思います。MySQL は、非常に安定したオープンソースソフトウェアだと思いますが、どんなものでもときにはおかしくなったりするものです。 「備えあれば憂いなし」ということで、僕は日頃から Nagios というオープンソースソフトウェアを利用して、MySQL がおかしくなっていかいか日々カジュアルに監視しています。 今日は、カジュアルに MySQL を Nagios を使って監視する方法を紹介したいと思います。なお、今回は CentOS 5.7 x86_64 というカジュアルな Linux
MySQL
HeatWave Use automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse scale analytics. Get faster insights from all your data with unmatched performance and deploy apps in your choice of cloud providers. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical support to achieve
How Twitter Stores 250 Million Tweets a Day Using MySQL - High Scalability -
Jeremy Cole, a DBA Team Lead/Database Architect at Twitter, gave a really good talk at the O'Reilly MySQL conference: Big and Small Data at @Twitter, where the topic was thinking of Twitter from the data perspective. One of the interesting stories he told was of the transition from Twitter's old way of storing tweets using temporal sharding, to a more distributed approach using a new tweet store c
Bug #68112 for DBD-mysql: is_prefix is not exported by mysql
diff -up DBD-mysql-4.018/mysql.xs.isprefix DBD-mysql-4.018/mysql.xs --- DBD-mysql-4.018/mysql.xs.isprefix 2010-07-09 19:47:47.000000000 +0200 +++ DBD-mysql-4.018/mysql.xs 2011-05-10 18:08:07.812894258 +0200 @@ -721,7 +721,7 @@ dbd_mysql_get_info(dbh, sql_info_type) case SQL_IDENTIFIER_QUOTE_CHAR: /*XXX What about a DB started in ANSI mode? */ /* Swiped from MyODBC's get_info.c */ - using_322=is_pr
「Can't connect to local MySQL server through socket」エラーについて
■ このような場合に参考にして下さい MySQLのクライアントソフト(mysql,PHP,Perl他)からMySQLサーバーに接続しようとすると 「Can't connect to local MySQL server through socket '/tmp/mysql.sock'」 のようなエラーが出て接続に失敗する。 ■ 対処方法の前に まずはじめに、エラーメッセージは次の意味を持ちます。 「ソケット'/tmp/mysql.sock'を通じてローカルのMySQLサーバーに接続することが出来ません」 ソケットとはプロセスやネットワーク間の通信機構のことで、MySQLではこのソケットを通じて サーバーとクライアントとが接続されます。ソケットというとポート番号を指定して利用する方法が 思い浮かびますが、ここでは/tmp/mysql.sockというファイルが出てきています。 これはUNIXド
MySQLの高速化のメモ - LukeSilvia’s diary
最近Railsアプリを作成している中で、初めて高速化をやったので、その際のことをメモしておく。 高速化の手順 ベンチマークをとる まずはベンチマークをとっておく。これによって、どのくらい早くなったか見極める。Railsなら、script/performance/benchmarkerを使って出来る。 テストコードとして、大量のフィクスチャを用意し、それに対して処理したベンチをとる方法もあるが、フィクスチャのデータがかなり現実味を帯びている必要があるため、本番環境でベンチをとった方がいい。 また、プロファイルして、本当にDBアクセスがボトルネックになっているのかを見ておく。 スロークエリログを見る MySQLには、結果を得るのに一定時間以上かかったクエリを記録しておく、「スロークエリログ」という機能があるので、どのクエリがボトルネックになっているかをこのログを見て調べる。 ログファイルの場所
Art of MySQL Replication.
1. Art Of MySQL Replicaton 〜 10 年の歴史を誇るレプリケーションの妙技〜 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 ●
MySQL レプリケーションの設定 - maruko2 Note.
MySQL レプリケーションの設定 提供：maruko2 Note. 移動： 案内, 検索 目次 1 MySQL レプリケーションの特徴 2 MySQL レプリケーションの動作概要 3 レプリケーションのセットアップ 3.1 レプリケーション用の my.cnf 設定 3.2 マスターにレプリケーション専用のユーザーを登録する 3.3 マスターサーバのスナップショットを作成する 3.4 マスターサーバのスナップショットを元に、スレーブを作成する 4 レプリケーションが正常に行われているか確認する方法 5 マスターのバイナリログの削除 6 参考ページ 7 MySQL 関連のページ MySQL レプリケーションの特徴 MySQL のレプリケーションは非同期。 1つのマスターに対して、1つ以上のスレーブが可能。 更新系のクエリはマスターのみで実行しなければならい。更新系クエリをスレーブで実行すると
MySQL レプリケーションの設定 - とみぞーノート
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.2 バイナリログファイルの位置ベースのレプリケーションの設定
ソースで、バイナリロギングが有効になっていることを確認し、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.1「レプリケーションソース構成の設定」を参照してください。 ソースに接続する各レプリカで、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.2「レプリカ構成の設定」を参照してください。 必要に応じて、レプリケーション用のバイナリログを読み取るときに、ソースとの認証中にレプリカで使用する別のユーザーを作成します。 セクション17.1.2.3「レプリケーション用ユーザーの作成」を参照してください。 データスナップショットを作成したり、レプリケーションプロセスを開始したりする前に、ソースで現在の位置をバイナリログに記録するようにして
MHA for MySQL 0.52 released
I'm happy to announce that MHA for MySQL (Master High Availability Manager and tools for MySQL) version 0.52 has been released. Downloads are available here. This is a stable release. I have been using MHA on our(DeNA's) cross-datacenter environments. We had tens of failover opportunities and MHA worked successfully in all cases. Here are release notes. * multi-master configuration is supported Se
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
漢(オトコ)のコンピュータ道: モダンなMySQLの開発環境の構築方法
遅ればせながら モダンな Perl の開発環境の構築方法 モダンなPHPの開発環境の構築方法 モダンなPythonの開発環境の構築方法 モダンな Java の開発環境の構築方法 に続いてみる。MySQLは言語じゃないけど。 コンパイラ等MySQLをソースからビルドするのでなければコンパイラ等は必要ないけど、どうせアプリ開発に必要なので「MySQLなんかいつでもハックしてやるぞ！」という意気込みを示すために入れておこう。OSXならXcode、LinuxならGCC。最新のソースコードじゃないとヤダ！という粋な人にはBazaarのインストールもお勧めしたい。Bazaarは言わずと知れた分散バージョン管理システムであり、MySQL開発チームも採用している。最新のソースコードは次のコマンドでゲット可能だ。 shell> bzr branch lp:mysql-server/5.1 mysql-5.1
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
MySQL レプリケーション基礎 - shibainu55日記
今日は、MySQLのレプリケーションのお話。バージョンは5.0を前提として説明。 MySQLにおけるレプリケーションは更新情報を記録したバイナリログ(binlog)をベースとしたアーキテクチャ。マスターでの更新情報をバイナリログとしてスレーブに転送、これをSQLに変換しスレーブで実行しデータ同期を行う。Oracle Data GuardのLogicalスタンバイによく似ている。 基本概念図を以下に示す。 特徴 複数のスレーブを用意することで、参照系クエリの負荷分散が可能 マルチマスター構成の場合には更新系クエリの負荷分散も可能 ただし、この場合にはアプリの扱うデータに依存し実現可否が分かれる。 マルチマスター扱いとするオブジェクトを限定するなど、論理設計でも考慮が必要 マスタのバックアップとしてスレーブを切り離し、サービス無停止のままバックアップが可能 この場合、スレーブを停止しコールドバ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL Triggers
このページを見るには、ログインまたは登録してください
現場指向のレプリケーション詳説