MySQLのmy.cnfファイルサンプル
MySQLのバージョン インストールされたMySQLのバージョンは以下のようになります。 名前 バージョン ダウンロード元 my.cnfサンプル 以下のサンプルを参照して、my.cnfファイルを作成してください。 # このファイルは MySQL 5.6を基準として作られてあります。 # http://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html を参照しました。 [mysqld] ##-------------------------------------------------------------------- # mysqldの基本設定 ##-------------------------------------------------------------------- # id は 1 から 2^
MySQL最低限のメモリ設定 - Qiita
環境にもよりますが、MySQLのデフォルトのメモリ関連の設定は控えめな感じになっています（私のCentOS環境では、key_buffer_sizeが8M,innodb_buffer_pool_sizeも8Mとなっています）ので、適切な状態への変更が必要です。 MySQLのメモリについては、いろいろな情報がありますが、MySQLのsupport-filesの中にあるサンプルを見ればいいでしょう（ちょっと、サイズの感覚が古いですが）。多くの場合、my-huge.cnfかmy-innodb-heavy-4G.cnfを参考にすればいいでしょう。 後は、本家Oracleさんの資料も参考になります。 グローバルバッファとスレッドバッファ MySQLでは、mysqldが共通に使うグローバルバッファと、スレッド（コネクション）毎に割り振られるスレッドバッファがあります。MySQLのメモリ使用量は、 メモリ
Python の MySQL ドライバはどれを利用すれば良いのか
このblogは、著者である「sakito」が技術的に生存している事を報告するために存在します タイトルを「紹介マニアどらふと版」から変更しました 概要 Python から MySQL に接続するためのドライバは複数存在している。どれを使うのが一番良いのか確認してみる。 Python の MySQLドライバ Python の MySQLドライバの主な物は「MySQL - PythonInfo Wiki」に記載されている。 以下のような物がある。記事を書いた時点でのpypiでの最終リリース日の新しい順。 リンク Python3対応 DB API v2.0対応 ライセンス メンテナー 最終リリース日 概要
似非管理者の寂しい夜:MySQLのバックアップではユーザー情報は含まれない - livedoor Blog（ブログ）
MySQLのデーターベースをバックアップするのは割と簡単なんですが、実は登録されたユーザー情報は別にバックアップしないといけないんですよ。 先日、そのことを知りました。 こういう情報って、こういうブログにちゃんと書いておいたほうがいいですよね。 と言いつつ、なかなか書きそびれていたんですが。 具体的にはこんな感じ。 mysqldump -u root-p -x --all-databases > hogehoge.dump mysqldump -u root -p -x --allow-keywords mysql > hogehogeuser.dump 上の1行でデータベース全体のバックアップをします。 下の1行でユーザー情報をバックアップします。 リストアは以下のとおり。 mysql -u root -p < hogehoge.dump mysql -u root -p mysql <
Percona XtraBackupの基本的な使い方 | 外道父の匠
PerconaといえばXtraBackup!! といっても過言ではないこの機能。 バックアップ手法はいくつかあれど、少なくともmysqldumpを使うくらいならXtraBackupを使っとけばいいと思います。手始めに、簡単な使い方から紹介していきます。 はじめに インストールについては前にまとめてあり、単にパッケージインストールするだけになっています。 バージョンは必ず最新を使ってください。だいぶ安定してきたとはいえ、バグフィックスは常にされており、特に v2.0.0 では8GBを超えるデータの際にエラーが起こるため、修正されています（参照：Announcing Percona XtraBackup 2.0.1）。 XtraBackupはmysqldumpと比べると、バックアップ作成速度が遅くなったり、データ容量が大きくなったりする場合がありますが、その代わりに以下のようなメリットがありま
長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
sysbench を使って MySQL をベンチマークする - CUBE SUGAR CONTAINER
MySQL の設定や構成またはバージョンの違いによるパフォーマンスの変化を調べるにはベンチマークツールが必要になる。 今回は sysbench というツールを使って MySQL のパフォーマンスを測ってみよう。 検証環境には CentOS7 を使った。 $ cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) $ uname -r 3.10.0-229.11.1.el7.x86_64 MySQL (MariaDB) のインストール まずは測定対象となる MySQL をインストールする。 CentOS7 では MySQL の代わりに MySQL フォークの MariaDB を使用することになる。 $ sudo yum -y install mariadb-server インストールできたら MariaDB のサービスを開始す
Google、MySQL互換の第二世代「Cloud SQL」正式リリース。ベンチマークを公開し、Amazon Auroraより高速だとアピール
Google、MySQL互換の第二世代「Cloud SQL」正式リリース。ベンチマークを公開し、Amazon Auroraより高速だとアピール Googleは、Google Cloud Platformで提供しているマネージドサービスのMySQL互換データベースである「Cloud SQL」を正式版としてリリースしました。 Cloud SQLは2011年に発表され、2015年12月には性能を強化した第二世代が登場、最大10テラバイトのデータ容量とインスタンスあたり最大104GBメモリを提供し、最大2万IOPSの性能に達すると説明されていました。 正式版リリースにあたり、同社はブログ「Google Cloud Platform Blog: Cloud SQL Second Generation performance and feature deep dive」で競合となるAmazonクラウド
Postfix + Dovecot 2 + PostfixAdmin + MySQL [がらくたネット]
postfixはVDAパッチが適用されたものを利用する必要がある。Quota機能が働かないからね。 groupadd -g 10000 vusers useradd -g 10000 -u 10000 vusers mysql関連の設定ファイル作成 vi /etc/postfix/mysql_virtual_alias_maps.cf user = postfix password = ******** hosts = localhost dbname = postfix table = alias select_field = goto where_field = address vi /etc/postfix/mysql_virtual_domains_maps.cf user = postfix password = ******** hosts = localhost dbname
Zabbix 2.2でMySQLを監視する - Qiita
はじめに Zabbix 2.2のソースには「conf/zabbix_agentd/userparameter_mysql.conf」が含まれているので、これを使ってMySQLを監視します。本家が公開しているRPMパッケージのzabbix-agentにも「/etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf」として同梱されています。 手順 Zabbixエージェントを適切に設定する（ここでは説明しない） MySQLにZabbixエージェント用のユーザーを作成する 「userparameter_mysql.conf」で指定されているHOMEに「.my.cnf」を作成する Zabbixエージェントを再起動する zabbix_getなどで挙動を確認する 詳細な手順 2. MySQLにZabbixエージェント用のユーザーを作成する MySQLにユーザ
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ
漢(オトコ)のコンピュータ道
※この記事はMySQL Advent Calendar 2023の4日目です。 MySQL 8.0シリーズでは正式版になってから多数の新機能が追加されるというリリースモデルであった。正式版になってから追加された新機能の中に、GIPK（Generated Invisible Primary Key）というものがある。これはなんとMySQL 8.0.30で追加された機能だ。MySQL 8.0が正式版になってから、なんと4年と3ヶ月後のことである。そんな感じでMySQL 8.0の新機能は正式リリース後にも増え続け、途方もない規模になっている。このブログでは一度に紹介するのは諦め、少しずつ気の向いたものから紹介していこうと思う。今回はその第一弾として、GIPKについて解説しよう。
HonestyWorks TechNote » MySQLのレプリケーションが不整合になってしまったときの再構築手順
概要 先日MySQLのMaster-Slaveレプリケーションが何かの拍子に機能しなくなっていることがわかりました。 このような状況に陥ったときの修正手順についてまとめてみます。 環境： Debian lenny MySQL 5.0.51 1台のマスタから1台のスレーブに対してレプリケーションしている構成 修正前のSlave状態 まず、現在のSlaveの状態を確認します。 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Master_Host: xxx.xxx.xxx Master_User: repl Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysqld-bin
Zabbix MySQLスレーブサーバ（レプリケーション）の監視設定メモ
サーバ構成MySQL マスター/スレーブサーバの設定内容は「MySQL 5.6 マスター/スレーブサーバの設定メモ」をご参照ください。また、MySQL マスター/スレーブサーバには、Zabbix-agent をインストールしておきます。 Zabbixサーバの、インストールや初期設定については、以下の記事をご参照ください。 Zabbix 2.4 を yumでインストール（CentOS6.5） Zabbix 1-1. ユーザーの作成とアクション（メール通知）の設定 MySQL レプリケーションの仕組みZabbix の設定をする前に、レプリケーションの仕組みについて、簡単に確認しておきましょう。レプリケーション機能の中核を担うのが、マスターとの通信を担当する「スレーブ I/Oスレッド」と、スレーブDBの更新を担当する「スレーブ SQLスレッド」です。このどちらかが停止してしまうと、レプリケーショ
【シンプル】CentOS6にMySQL5.5をyumで簡単にインストールする手順 | 田舎に住みたいエンジニアの日記
CentOS6ではMySQL5.1がデフォルトバージョンです。今回はMySQL5.1を削除して、MySQL5.5をインストールする手順をメモします。パッケージインストールできるのでとても簡単です。 事前確認 MySQL5.1系の確認 [html]# rpm -qa | grep mysql mysql-utilities-1.3.6-1.el6.noarch mysql-server-5.1.71-1.el6.x86_64 mysql-libs-5.1.71-1.el6.x86_64 mysql-5.1.71-1.el6.x86_64 mysql-connector-python-1.1.4-1.el6.noarch mysql-devel-5.1.71-1.el6.x86_64[/html] MySQL5.1の削除 [html]# yum remove mysql*[/html] ※ここ
MySQLレプリケーションにおけるフェイルオーバー – OpenGroove
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
Amazon Auroraを真に理解するための性能検証 | 外道父の匠
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照／更新クエリを実行しています デ
HAPrxoy 1.6.0 で導入された DNS の動的名前解決の検証結果 - tkuchikiの日記
追記(2016-07-13 16:40) Changelog に書いてあるとおり(BUG/MEDIUM: dns: unbreak DNS resolver after header fix)、 動的名前解決ができないバグが修正されました。 HAProxy 1.6.6 で動的名前解決できないバグが修正されていました(Changelog にも書いていますが一応検証しました)— tkuchiki (@tkuchiki) 2016年7月13日 詳細は省きますが、本記事と同様の検証を行い、動的名前解決ができることを確認しました。 追記(2016-06-24 12:34) HAProxy 1.6.5 は、DNS の動的名前解決が動作しないようです。 ご注意ください。 HAProxy 1.6.5 で動的名前解決できない問題については 1.6.4 で困っていなければそれを使って、1.6.5 がよければ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.ielove-group.jp/blog/23
片手間MySQLチューニング戦略
