MySQLの「ALTER TABLE ADD INDEX」と「CREATE INDEX」 - なからなLife
ALTER権限とALTER TABLEの検証作業の中で。。。 atsuizo.hatenadiary.jp ここで、ALTERしか付与してないのに、INDEXのADD/DROPが成功してたことが、どうにも引っかかってまして。 公式ドキュメント上は。。。 表 13.1 GRANT および REVOKE に対して許容可能な権限 権限 意味と付与可能なレベル （略） INDEX インデックスの作成または削除を有効にします。レベル: グローバル、データベース、テーブル。 （略） MySQL :: MySQL 5.6 リファレンスマニュアル :: 13.7.1.4 GRANT 構文 CREATE INDEX は、インデックスを作成するために ALTER TABLE ステートメントにマップされます。セクション13.1.7「ALTER TABLE 構文」を参照してください。CREATE INDEX を使
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
MySQL 8.0.0 Development Milestone Release登場！！
先月、詳解MySQL 5.7を発刊したばかりであるが、MySQL 5.7自体は去年の10月にリリースされたバージョンである。それから約1年弱、MySQLは開発の手を緩めること無く日々改良を重ねている。 そう、MySQL 8.0の登場である。 現在はDevelopment Milestone Release（通称DMR）という状態なので、まだ正式版における機能が固まっている段階ではないという点には注意して欲しい。MySQLの開発プロセスでは、DMRをリリースするごとにその段階で成熟した機能をマージする。DMRを何度かリリースした後に、キリの良いところでリリース候補版となって正式版で追加される機能が一応確定し、その後バグ修正を経て正式版（GA版）がリリースされる予定となっている。詳しくはMySQLのマニュアルを参照して欲しい。 バージョン8.0!!5.7の次は誰もが5.8だと思っていただろう・
CVE-2016-6662 MySQL Remote Root Code Execution / Privilege Escalationについて - Qiita
免責 取り敢えずわかっている範囲で書いただけなので、手元で再現やパッチの正当性は確認していません。 自己責任でどうぞ。 これ(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は影響を受けないかも知れません。詳しくは図のさらに下に。 手元で再現させてはいませんが、 オリジナルの脆弱性報告 の影響を受けるバージョンがしゃらっと "5.7.14
mysqlのバックアップ(mysqldump)のロック問題 | シーズクリエイターズブログ
2015.07.31 mysqlのバックアップ(mysqldump)のロック問題 Writer: はらぐち ／ Category: インフラ . こんにちは、はらぐちです。 今回お話したいのは、mysqlのバックアップ方法についてのあれこれです。 バックアップ mysqldump mysqlのバックアップといえばmysqldumpです。 以下のような形で使います。 mysqldump -u root -p -x -A > my_dumpall.db これで全データベースのダンプができます。 特定のデータベースをダンプしたい場合は、以下のようにデータベース名を指定します。 mysqldump -u root -p -x データベース名 > dump.sql 定期的にバックアップを取りたい場合は、シェルスクリプトで以下のようなものを cronで実行してあげるといいでしょう。 二日間のバ
mysql の定期的なバックアップ - Qiita
解説が不十分な部分ついては、補足（コピペで本文に取り込める体裁だとありがたい）を頂けると助かります！ mysqlのバックアップ手法に関しては様々な方法がありますので随時追記していきたいと思います！ サーバー構成に関しても様々なパターンがありますので、随時追記していきたいと思います。 mysql-server 5.1.8以降では、以前の手法ではWarningが発生するようになったため、 それ回避した上での手法を公開したいと思います。 まずmysql5.1.8以前のバージョンでのバックアップ手法 mysqldump --opt --all-databases --default-character-set=binary -u root > /root/backup/mysql/all_db.sql
長年の議論に終止符 -- 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だけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
mysqlのログファイルのサイズを変更する - よかろうもん！
バイナリデータを格納するために、BLOB型やその拡張のMEDIUMBLOB型を利用するシーンが時折あるかと思います。 BLOB型を利用していて、サイズの大きなデータをDBに格納しようとすると、MySQLのログに以下のようなエラーログが出力されることがあります。 100906 00:00:00 InnoDB: ERROR: the age of the last checkpoint is 9440228, InnoDB: which exceeds the log group capacity 9433498. InnoDB: If you are using big BLOB or TEXT rows, you must set the InnoDB: combined size of log files at least 10 times bigger than the InnoDB:
データベースの削除ができない - ぱんくず
データベース再作成の際にdrop databaseで失敗した場合の対応。 問題 drop database時に何らかの事由によって失敗してしまった場合、コマンド（drop database）による削除を受け付けなくなる。 コマンドで削除 管理ユーザでmysqlにログイン mysql -u root -p mysqlの管理ユーザでログインする。 DB名確認 mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | test_db | | mysql | +--------------------+ 3 rows in set (0.01 sec) test_dbを削除 mysql> drop database test_db; ERROR
Strange MySQL database that I can't select
I am investigating a web site server (CentOS release 6.3) that runs the traditional lamp stack; I am getting the following output my MySQL; mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | #mysql50#.config | | webtestdb | | mysql | | test | | websitedb | +--------------------+ 6 rows in set (0.00 sec) What is "#mysql50#.config"? Also, I can
MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.2.4 識別子とファイル名のマッピング
データベース識別子やテーブル識別子とファイルシステム内の名前との間には対応があります。 基本構造では、MySQL は各データベースをデータディレクトリ内のディレクトリとして表し、ストレージエンジンに応じて、各テーブルは適切なデータベースディレクトリ内の 1 つ以上のファイルによって表されます。 データファイルとインデックスファイルの場合、ディスク上の正確な表現はストレージエンジンによって異なります。 これらのファイルは、データベースディレクトリに格納することも、別のファイルに格納することもできます。 InnoDB データは InnoDB データファイルに格納されます。 InnoDB でテーブルスペースを使用する場合は、新たに作成した特定のテーブルスペースファイルが代わりに使用されます。 ASCII NUL (X'00') を除くすべての文字は、データベース識別子またはテーブル識別子で有効で
InnoDBのログとテーブルスペースの関係
InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
MySQLのibdataファイルを複数表領域に変更する – OpenGroove
InnoDBのibdataファイルのサイズは、放っておくと相当肥大化してしまう。10G、20Gなんてフツーにいってしまう。30Gくらいになる例もある。もっと大きくなろうと思えばなれるんだろう。まったく怪物みたいなヤツだな・・・。 と、いうわけで、通常のibdataファイルを複数表領域にしてみる。複数表領域にするときのパラメータはinnodb_file_per_table。通常のibdataファイルでDBが稼働している状態から、複数表領域に変更するときの手順メモ。詳しい仕様の話は割愛させていただく。早く寝たいので。 以下、my.cnfの記述例一部。複数表領域に変更してもibdataファイルは消えない。autoextend:max:4096Mなどと記述することでサイズを制限しておく。 innodb_data_file_path = ibdata1:100M:autoextend:max:409
mysql replicationの復旧方法
Master_Log_File, Relay_Master_Log_Fileの意味は混同しやすいので、細心の注意を払ってください。また、それぞれのポジションの実態は、master.info, relay.infoというファイルです。 mysql レプリケーション 復旧シナリオ 事前準備 mysql レプリケーション 復旧シナリオ 事前準備 – mysqld_multi環境の構築 mysqld_multiを用いて、3つのmysqld(MySQLサーバ)を起動させます。動作確認のシナリオで使用する/etc/my.cnfの設定は以下の通りです。mysqld_multiの使い方は、mysqld_multiの設定方法を参照ください。 [mysqld] log-bin=mysql-bin relay-log=mysql-relay log-slave-updates master_info_repos
MySQLのメモリ設定の勘所 – sawara.me
MySQLサーバーをダウンさせた夜は数知れず。 その度にmy.cnfの設定を見なおしてみてはトライし、治ったと思いきや突然のダウン。 サーバーがダウンしてしまう原因は何かと聞かれれば、「メモリです」と断言しましょう。 メモリ設定は諸刃の剣。 パフォーマンスを最大に引き出すこともできればそれと引き換えにサーバーをダウンさせてしまうこともできるんです。 今回はMySQLのメモリの設定の勘所というかたちで紹介しようと思います。 グローバルバッファとスレッドバッファ メモリの設定についてまず「グローバルバッファ」と「スレッドバッファ」について理解しておくことが大事です。バッファとは一時的な記憶領域・つまりはメモリの領域のことなのですが。 グローバルバッファ MySQLで使用する全体的なメモリ使用量を計算するには グローバルバッファ + (スレッドバッファ × コネクション数) = メモリ使用量 と
innodb_buffer_pool_sizeのチューニング：どれくらい割り当てる？
結論としてはinnodbテーブルの全データ量だそうです。 ここ最近はデータベースサーバのリプレースの案件の担当をしているのですが、サーバのサイジングをしていてふと、「どれくらいメモリあれば足りるんだろう」と疑問に思いました。 よく「サーバの全メモリの50％から70％くらい」とか「80％」くらいとか言われますが、それはどちらかというとスワップしないための限界値を示すものであって、理想値ではないですよね。それでいろいろ調べてみたところ、なかなか日本語で良いまとめがなかったので、まとめてみようと思います。 目次 そもそもinnodb_buffer_poolとは？ 使用状況を確認する(SHOW ENGINE INNODB STATUSでの計測) 適切なinnodb_buffer_pool_sizeは？（チューニング方法） そもそもinnodb_buffer_poolとは？ InnoDB maint
MySQLでlocalhostと127.0.0.1の違い - Qiita
全然違います windows環境でCygWin入れてると怒られますよね？ ※ Linuxでもとても難解な問題が出てくるので環境依存関係無いです（バグです） mysql -uroot -p して怒られます。 ekaneko@hoge ~ $ mysql -uroot -p Enter password: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysql.sock' (2) ekaneko@hoge ~ $ mysql -h 127.0.0.1 -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 22 S
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヤフー社内でやってるMySQLチューニングセミナー大公開
mysqldump
Events Overview