MySQL 8.0.17でついにCloneプラグインが入った
TL;DR MySQL 8.0.17 でついに俺待望の Cloneプラグイン が追加された CLONE LOCAL DATA DIRECTORY .. で、ローカルファイルシステムにほぼノンブロッキングで物理バックアップを吐き出す CLONE INSTANCE FROM USER@HOST:PORT IDENTIFIED BY 'password' .. でグループレプリケーションの経路を使ってフツーのレプリケーションと同じ3306の経路を使ってインスタンスの丸コピーができるらしい このへんを読んでおくのが良さげ MySQL :: MySQL 8.0 Reference Manual :: 5.6.7 The Clone Plugin MySQL :: MySQL 8.0 Reference Manual :: 5.6.7.13 Clone Plugin Limitations mysql
MySQLで全文検索をするために必要なこと - 小さな星がほらひとつ
与えられたキーワードに合致するデータをデータベースから取得することを考えた時、完全一致であれば「=」で検索を行うと思います。 では与えられたキーワードを「含む」検索、つまり部分一致を行いたいのであればどうするか。最も簡単なのは「search_column like '%キーワード%'」といった形で、「like」を使いキーワードの前後にワイルドカードを与える方法でしょう。 ですがこれを何の気無しに使うのはちょっと危険。 上記のようなlike検索ではインデックスが利用されないため（※）、全レコードをスキャンします。 かつキーワードを部分一致で探したいようなカラムは、文章等の比較的大きなサイズであると考えられます。 そのため検索コストは大きく、数千〜数万行であればまだ良いかもしれませんが、数十万ともなると利用には耐えられないでしょう。（実体験） ※ただし前方一致検索であれば、最初のワイルドカード
MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳
結論 何がいいたいかといいますと0000-00-00 00:00:00があるとORMも死ぬし、DBマイグレーションツールも死ぬし、そもそもMySQLからポスグレにデータを持っていくこともFDWをすることも出来なくて死ぬのじゃ。— そーだい@初代ALF (@soudai1025) 2018年4月25日 色々困るので使わない。 理由 以下に理由を述べる SQL標準ではない 正論で殴った場合。 0000-00-00 00:00:00の仕様が難しい 0000-00-00 00:00:00 はMySQLの独自な仕様で NOT NULL制約のカラムではNULLと等価であり、NULLではない という仕様がある。 "NOT NULL として宣言された DATE および DATETIME カラムでは、次のようなステートメントを使用することで、特殊な日付 '0000-00-00' を検索できます"https:
MySQL 8.0登場！立ち止まることを知らない進化はこれからも続く。
ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その
How large should be mysql innodb_buffer_pool_size?
I have a busy database with solely InnoDB tables which is about 5GB in size. The database runs on a Debian server using SSD disks and I've set max connections = 800 which sometimes saturate and grind the server to halt. The average query per second is about 2.5K. So I need to optimize memory usage to make room for maximum possible connections. I've seen suggestions that innodb_buffer_pool_size sho
InnoDBで行ロック/テーブルロックになる条件を調べた #mysqlcasual Advent Calendar 2013 - あおうさ＠日記
はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー｀)ノ 〜 私がMySQLで えっ？！ っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう！ http://
なぜあなたは SHOW ENGINE INNODB STATUS を読まないのか - そーだいなるらくがき帳
この記事は、MySQL Casual Advent Calendar 2017の20日目の記事です。 煽り気味のタイトルですがみなさん SHOW ENGINE INNODB STATUS 読んでますか？ SHOW ENGINE INNODB STATUS \G 見づらいのなんとかならんのか。— そーだい@初代ALF (@soudai1025) 2016年12月20日 わかる。でもMySQLの振る舞いを知る中でSHOW ENGINE INNODB STATUSを読まざる得ない場面はそこそこあります。 どんな時に必要になるのでしょうか？ そこでSHOW ENGINE INNODB STATUSにまつわる話を書きます。 SHOW ENGINE INNODB STATUS をまず読みやすくする まず末尾に \G を付けましょう。 これで3倍読みやすくなります。 次に pager less -S を
データベースエンジン — SQLAlchemy 0.6.5 ドキュメント (和訳)
データベースエンジン¶ SQLAlchemy を使うアプリケーションは、全て データベースエンジン (Engine) を扱うところから始まります。エンジンは、実際のデータベースや DBAPI にアクセ スするためのいわば足場です。エンジンは、それぞれのデータベースや API との組 み合わせごとに、特定のコネクションプールや ダイアレクト (Dialect) を経 由してアクセスします。 この関係は、以下のような図で表せます: +-----------+ __________ /---| Pool |---\ (__________) +-------------+ / +-----------+ \ +--------+ | | connect() <--| Engine |---x x----| DBAPI |---| database | +-------------+ \ +---
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
MySQL に大きなデータを送る際に max_allowed_packet を確認した方がいい | Sun Limited Mt.
MySQL でクライアントからサーバに送ることができるパケットの最大は 16MB です。しかしデフォルトでは 1MB になっています。画像を DB に格納している OpenPNE のようなアプリケーションではこの制限に引っかかってしまうことがあります。 max_allowed_packet の確認 mysql> show variables like 'max_allowed_packet'; +--------------------+---------+ | Variable_name | Value | +--------------------+---------+ | max_allowed_packet | 1048576 | +--------------------+---------+ max_allowed_packet を SQL により変更する mysql> set
MySQLでログを出力してみる - yk5656 diary (旧)
CentOSにMySQLとMemcacheのインストールしてみる の続き MySQLでログを出力してみる。 ログ出力用のディレクトリ作成 まず、ログ出力用のディレクトリを作成しておく。 $ sudo mkdir /var/log/mysql $ sudo chown mysql:mysql /var/log/mysql エラーログ エラーログは、デフォルトの設定で/var/logの下に出力するようになっている。 $ sudo vi /etc/my.cnf ・・・ [mysqld_safe] log-error=/var/log/mysqld.log 作成したmysqlディレクトリに出力させたい場合は、下記のように設定する。 $ sudo vi /etc/my.cnf ・・・ [mysqld_safe] log-error=/var/log/mysql/mysqld.log 設定を変更した場
【MySQL】総メモリー使用量を算出するSQL作ってみた - もぐめぽろぐ
必要メモリ量＝グローバルバッファのサイズ＋（各スレッドのバッファサイズの合計 × 最大接続数(max_connections)） 各スレッドのバッファサイズの合計とは、以下の値の合計値です。 sort_buffer_size myisam_sort_buffer_size read_buffer_size join_buffer_size read_rnd_buffer_size グローバルバッファのサイズは、以下の値の合計値です。 key_buffer_size innodb_buffer_pool_size innodb_log_buffer_size innodb_additional_mem_pool_size net_buffer_length ※実践ハイパフォーマンスMySQL による とあるのだが、一般的にいわれてる計算式はさらにそれに+query_cache_sizeがプラ
MariaDB(MySQL) - ログローテート時のエラー！
こんにちは。 Linux サーバでのログローテート時に MariaDB(MySQL) ログ部分でエラーが発生することがあります。 以下、当方が以前体験した事案についての現象・原因・対策の記録です。 0. 前提条件 Debian GNU/Linux 7.8(64bit) を想定。 MariaDB 10.0.15 を想定。 環境等により設定ファイルの配置場所等が以下の記事内容と若干異なるかもしれないので注意すること。 1. 現象 ログローテート時に以下のようなエラーが発生する。 /etc/cron.daily/logrotate: /usr/bin/mysqladmin: flush failed; error: 'Unknown error' error: error running shared postrotate script for '/var/log/mysql.log /var/
MySQL 5.7 初期パスワード設定あれこれメモ - Akey Blog
MySQLインストール後、パスワード設定関連であれこれ調べたのでメモ。 MySQLバーション：mysql 5.7.15 root初期パスワード mysqlインストール後、mysql_secure_installationコマンドで初期設定を開始。 # mysql_secure_installation --- Securing the MySQL server deployment. Enter password for user root: --- ・・・rootのパスワードが分からない 調べた所、ログからパスワードを確認可能とのこと。 # vi /var/log/mysqld.log 以下を確認（"~root@localhost:"以降が初期パスワード） --- [Note] A temporary password is generated for root@localhost: K
MySQL 5.7.6でデータベースの初期化が変わる mysql_install_dbからmysqld --initialize
MySQL 5.7.6でデータベースの初期化が変わる mysql_install_dbからmysqld --initialize MySQL 5.7.6のメモその1。 MySQLの初期化がmysql_install_dbからmysqld --initializeに変わる。 リリースノートのいわく、 mysql_install_db functionality now has been integrated into the MySQL server, mysqld. To initialize a MySQL installation, invoke mysqld with the --initialize or --initialize-insecure option, depending on whether you want the server to generate a rand
MySQL 5.7.5 on Windowsでskip-name-resolveするとrootでログインできなくなる
ことの発端はこのバグレポート。 MySQL Bugs: #75656: 5.7.5 skip_name_resolve stops all connection attempts なんでかよくわからないけれど、調べてみようと思った。そしたらば。 mysql57> SELECT user, host FROM mysql.user; +------+-----------+ | user | host | +------+-----------+ | root | localhost | +------+-----------+ 1 row in set (0.00 sec) mysql_install_dbして起動しただけでコレ。これじゃあ--skip-name-resolveしたらつながらなくなるだろうという感じ。 日々の覚書: user@localhostとuser@127.0.0.1
MySQLの文字コードをutf8mb4に変更 - Qiita
+--------------------------+----------------------------+ | Variable_name | Value | +--------------------------+----------------------------+ | character_set_client | utf8mb4 | | character_set_connection | utf8mb4 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8mb4 | | character_set_server | utf8mb4 | | character_set_system | utf8mb4 | | char
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLでbulk insert + on duplicate key updateしたい - oinume journal
MySQL InnoDB Cluster を使って運用を手抜きしよう
Django + MySQLでの設定あれこれ - Qiita
