出典について
この記事は、Stewart Smith氏のブログ記事「The sad state of MySQL and NUMA」(2015/07/08)を翻訳したものです。
2010年にまで遡ると、MySQL Bug 57241がレポートされ、"swap insanity"問題についての指摘がx86のシステム上ではより深刻になってきた。とりわけ、以後NUMAがより一般的になるに従ってである。
スワップの問題はあるNUMAノード上のメモリが枯渇し、他のノードとスワップせざるを得なくなるためである(Jeremy Cole氏の2010年のswap …
[さらに読む]
昨日の 日々の覚書: MySQL 5.7では迂闊にperformance_schemaをOFFするとSHOW
STATUSが使えない の派生バージョン。
MySQL 5.7.8以降、show_compatibility_56=
0が暗黙のデフォルトになり、SHOW
VARIABLESとかはinformation_schemaではなくperformance_schemaを見に行くようになる。performance_schema.*_variablesテーブルにSELECT権限がないとSHOW
VARIABLESは転ける。
さて…レプリケーションスレーブを作ろうと思った時、どんな権限を持ったユーザーを作るか。
俺ならこうだ。
mysql> CREATE USER replicator;[さらに読む]
Query OK, 0 rows affected (0.07 …
オンラインで色々なDDL処理が出来るのは、サービス提供側も、利用者も、DBAとしても
非常に便利な機能かと思います。MySQLは4.1からUnicode対応していたので、
10年弱程利用してますが、Online DDLが利用可能になるまでは、
夜中のユーザーが少ない時間にテーブル定義を変更していたりする事も多々ありました。
MySQL5.6以降のオンラインDDLはそういったメンテナンス対応の方には、非常に便利で有難い機能かと思います。
オンライン処理可能かどうかは、14.11.1. オンライン DDL の概要で確認する事が出来ます。
手元で簡単に確認したい場合は、以下のオプションで処理を指定して確認する事が可能です。
…
動作は5.7.7で確認していて、 5.7.8で暗黙のデフォルトがOFFになるって書いてある のでやってみた。
MySQL 5.7.6から show_compatibility_56 というサーバー変数が追加されている。
SHOW {GLOBAL|SESSION} STATUS, SHOW {GLOBAL|SESSION} VARIABLES
は今まで内部的にinformation_schemaのテーブルを叩いていた。これをperformance_schemaのテーブルを叩くように変えるのがこのパラメーター。
ONだとinformation_schemaから、OFFだとperformance_schemaから情報を取ってくる。
mysql57> SELECT @@version;[さらに読む]
+--------------+
| …
MySQLのmysqlbinlogコマンドでは、MySQL5.6からリモートにあるバイナリーログを読み取る事が可能になりましたが、SSLを利用した通信の暗号化はサポートされておりませんでした。
次期メジャーバージョンのMySQL5.7では、ここら辺も機能拡張されておりmysqlbinlogコマンドを利用して、リモートのバイナリーログを読み込み場合にもSSLを利用した通信の暗号化を行う事が出来るようになりました。
Firewall、セキュリティ機器、セグメント分割された環境で、何処まで必要になるかは状況次第ですが、
リモートサーバーが自然災害対策の為に、自分でインフラを準備する必要が無いPublicクラウド上にある場合などに通信の暗号化が出来ると安心ですね。
…
TL;DR
kamipo
traditionalですら完全に防ぎきれないアレがあるので、そこを気にするなら出来る限りさっさとMyISAMからInnoDBに引っ越しましょう。
これらの記事を読んだ人向けです。
ルーク！MySQLではkamipo TRADITIONALを使え！ |
おそらくはそれさえも平凡な日々
Javaでkamipo traditionalを有効にする -
その手の平は尻もつかめるさ
アプリでミスって不正なデータが入るくらいだった500になったほうがマシ。というのが個人的な考えです。
+激しく同意+
さて、激しく同意したところで、kamipo …
免責事項
この記事はTodd Farmer氏によるMySQL Server Blogの投稿(2015/6/24)をユーザが翻訳したものであり、Oracle公式の文書ではありません。
MySQL 5.7より前は、CREATE USERコマンドはたくさんの制約を持っていた
…
[さらに読む]
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。
未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。
DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。
…
innodb_stats_on_metadata=1でディスク容量激増とCPU負荷が発生 |
DEVLAB を読んだ誰か（忘れた）に「innodb_stats_on_metadata=
0だと統計情報ズレない？ 手でANALYZE TABLEしないといけないの？」って聞かれて答えたメモ（だと思う）
そもそも8ページとか20ページじゃ全然足りないじゃんというのはここでいう「問題なく」の中には含まれない。
innodb_stats_on_metadataは *メタデータにアクセス(=information_schema, SHOW
TABLE STATUSなど)* した時に統計情報を再作成するかどうかのフラグで、データが大量に更新された時の統計情報の再作成は
ここらへん …