MySQL 8.0.17のCLONE INSTANCE FROMを使うとすごく楽にレプリケーションスレーブが作れる
TL;DR 日々の覚書: MySQL 8.0.17でついにCloneプラグインが入った で紹介した CLONE LOCAL DATA は現在のdatadirをローカルのファイルシステムに一貫性のある形でコピーするステートメントだった これをスレーブになるサーバーに転送してやってももちろん良いんだけど、そこまで一括でやってくれる CLONE INSTANCE FROM のステートメントも存在する スレーブ増やすのが捗る CLONE INSTANCE FROM を使うためには、データのコピー元（ ドキュメント 上では ドナー(Donor) ）とコピー先（同 レシピエント(Recipient) ）それぞれのMySQLでCloneプラグインが有効化されていないといけない。 donor> INSTALL PLUGIN clone SONAME 'mysql_clone.so'; recipient>
MySQL 5.7.6からSSL周りのセットアップが扱いやすくなった
MySQL :: MySQL 5.7 Release Notes :: Changes in MySQL 5.7.6 (2015-03-09, Milestone 16) から抜粋。 MySQL Server from Community Edition distributions now tries to deploy with SSL support enabled automatically if no SSL options are specified explicitly and it finds any of the ca.pem, server-cert.pem, and server-key.pem files in the data directory. In this case, clients can use a secure connection merely by
AnemometerというMySQLスローログ専用の可視化ツールの弱点と、その克服スクリプト
一部の人にしか知られていない Anemometer というMySQLのスローログ専用の可視化ツールがある。 box/Anemometer: Box SQL Slow Query Monitor 中身はpt-query-digestの テーブル出力機能 （サマライズした結果をMySQLのテーブルに保存する機能があるのだ）に依存していて、スローログの可視化というよりはpt-query-digestの可視化というのがたぶん正しい。 だけどこのやり方にはちょっと弱点があって、pt-query-digestはクエリーをサマライズする時に発生時間の情報を 「そのダイジェストが最初に現れた時間(ts_min)」と「そのダイジェストが最後に現れた時間(tx_max)」 という値にサマライズしてしまう。よく見る出力結果の中では"Time range"として表示されている。 # Query 14: 0.00
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！）
MySQL 5.7.4で導入されたdefault_password_lifetimeがじわじわくる（MySQL 5.7.11でFIX！！） 【2016/01/13 10:12】 MySQL 5.7.11でdefault_password_lifetimeのデフォルトは0に変更になりました！ それ以降のバージョンであればこの記事の内容は気にする必要はありません。 日々の覚書: MySQL 5.7.11でdefault_password_lifetimeのデフォルトが0になるらしい！ TL;DR default_password_lifetime= 0 を秘伝のmy.cnfに入れておくつもり。 MySQL :: MySQL 5.7 Reference Manual :: 5.1.4 Server System Variables パラメーターの意味は読んで字のごとく、「最後にパスワードが更新さ
MySQL Fabricつらい(XML-RPCでつついてみる編)
MySQL Fabricの基本概念としては、 * Fabricサーバーはファームに関する情報だけを提供して、 * 実際の接続のハンドルはFabric対応コネクターが提供する Fabricサーバーがしゃべるプロトコルは2種類。XML-RPCとMySQLプロトコルで、問い合わせ結果はコネクター側にキャッシュされて、TTLによって破棄される（実際にはコネクターの実装に依存するんだろうけど） 現在MySQL Fabricに対応しているコネクターは * Connector/Python (○racleさん謹製) * Connector/J (○racleさん謹製) * mysqlnd (PHPによるクライアント実装で、シャード機能のみ実験的にサポート(HA機能は(まだ?)サポートしない)) * Connector/C (○racleさん謹製だけどlabsリリース) そして、Connector/Cが現
MySQL Fabricつらい（HA/登録編）
昨日インストールしたMySQL Fabric にファーム(MySQL Fabric管理下のmysqld群をこう呼ぶぽい)を追加していく。 まずはグループを作成。これが「同じデータセットを持っているマスターとスレーブの組」扱いになるはず。 $ mysqlfabric group create my_first_fabric --description="MySQL Fabric is too hard to me" Password for admin: Fabric UUID: 5ca1ab1e-a007-feed-f00d-cab3fe13249e Time-To-Live: 1 uuid finished success result ------------------------------------ -------- ------- ------ 8fb1a6df-0be9-4
Percona XtraDB Cluster設計の迷いどころ（現在進行形）=> 解決
今、とあるサービスに Percona XtraDB Cluster を突っ込むことを画策しているんですが、今まさに迷っている真っ最中なのでメモしておきます。誰か何か思いついたら教えてください。 Percona XtraDB Cluster(以下PXC)というか Galera Replication の仕組みというかコンセプトというか自体が、「マルチマスターなMySQL *の* クラスター」なわけで、PXCを使えばこれは簡単に実現できます。 が。 PXCでマルチマスターすると、バイナリーログの扱いがちょっと問題になってきます。 wsrep providerが提供するPXC内の同期はGalera Cacheと呼ばれる専用のバイナリーログ(からヘッダーを取り除いたもの)に格納され、同期されます。Galera Cacheのファイルは（どういう仕組みなのか調べてないけれど）原則として一定サイズで（必
知られざるinnodb_flush_methodの値
innodb_flush_methodの値といえば、fdatasync(暗黙のデフォルト)かO_DIRECTくらいしか知らなかった訳だが、O_DSYNCやO_DIRECT_NO_FSYNC(5.6.7から)もあったり、Percona ServerにはALL_O_DIRECTなんてものがあったりする。 ⇒http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_flush_method ⇒http://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_flush_method ⇒http://www.percona.com/doc/percona-server/5.1/scalability/innodb_io.
MySQLサーバーのディスク容量減少アラートが飛んでくる前に
このビッグウェーブにいつ乗るの！ 今でしょ！ 元RX-7乗りの適当な日々 Linuxサーバがディスク容量不足になった！何か消さねば！ってなった時にどう対処するか tagomorisのメモ置き場 Linuxサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか iをgに変えるとorangeになることに気づいたoranieの日記 Cassandraサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか …と思ってたらMySQLバージョンも既に出た。けどめげない。かぶらないように書きます。というかタイトルはかぶらないように変えました(つд｀) Y-Ken Studio MySQLサーバのディスク容量減少アラートが飛んできた！ってときにどう対処するか さてまず、MySQLで勝手に(?)増えるものといえば。 データファイル(.MYD, .MYI, .ibd, ibda
InnoDB buffer pool dumpで遊ぶ
掲題のMySQL5.6の新機能で遊んでみたメモ。 InnoDBバッファプールの内容をファイルに書き出しておくことが出来る機能が追加された。 書き出すタイミングは正常終了時(SET GLOBALまたはmy.cnfでinnodb_buffer_pool_dump_at_shutdown = 1を設定)または 任意のタイミングで即時書き出し(SET GLOBAL innodb_buffer_pool_dump_now = 1;) 読み出すタイミングは起動時(my.cnfにinnodb_buffer_pool_load_at_startup = 1)または 任意のタイミングで即時読み込み(SET GLOBAL innodb_buffer_pool_load_now = 1;) これで、mysqldを再起動してバッファプールが空っぽになっても 素早くウォームアップできるぞ、ということらしい。 特に何
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
