Galeraレプリケーションに Primary Key が必要な理由 | スマートスタイル TECH BLOG
はじめに Galera Cluster（およびそのブランチ）には、「全テーブルにPrimary Keyが設定されている必要がある」という制約事項があります。これは以下のように公式リファレンスマニュアルでも明言されています。 DIFFERENCES FROM A STANDALONE MYSQL SERVER Do not use tables without a primary key. MariaDB Galera Cluster – Known Limitations All tables should have a primary key (multi-column primary keys are supported). 特に Percona XtraDB Cluster（以下、PXC）の場合、PXC5.7で「PXC Strict Mode」という機能を実装し、PKがないテーブルが
utf8_general_ciとutf8_unicode_ci - 技術メモ帳
技術メモ帳 開発するうえで調べたこと、知ったことを備忘録としてメモメモ！ トップページページ一覧メンバー掲示板編集 utf8_general_ciとutf8_unicode_ci 最終更新： clever_next 2012年07月27日(金) 13:50:19履歴 Tweet utf8_general_ciとutf8_unicode_ci utf8_general_ciとutf8_unicode_ciの違いは主に以下。 utf8_general_ci 英字の大文字小文字は区別しない。 全角半角は区別する。 utf8_unicode_ci 英字の大文字小文字は区別しない。 全角半角も区別しない。 さらに濁音、半濁音、ひらがな、カタカナも区別しない。 「は」で検索すると「は」「ば」「ぱ」「ハ」「バ」「パ」「ﾊ」がヒットする。 ちなみに全てを区別したい場合はutf8_binを使用すればよい。
長年の議論に終止符 -- 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だけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
1日に100万レコード増える場合のテーブル設計
MySQL（マイエスキューエル）は、TCX DataKonsultAB社などが開発するRDBMS（リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
MySQL 5.7.6のInnoDB日本語全文検索 ngram
日々の覚書: プレビュー "MySQL 5.7.6のInnoDB日本語全文検索 MeCab Plugin" に引き続き、今度はngramなトークナイザー。ドキュメントは ここ 。 MeCab Pluginと違って特にINSTALL PLUGINとかせずに即使える。 mysql> ALTER TABLE articles ADD FULLTEXT KEY (title, content) WITH PARSER ngram; Query OK, 0 rows affected (6 hours 25 min 20.67 sec) Records: 0 Duplicates: 0 Warnings: 0 ( д ) ﾟ ﾟ 6時間半！？ しょうがないとはいえ、MeCabのときは1時間半でお釣りが来てたのにと思うとちょっとしょんぼり。 時間もさることながら、このやり方(データをインポートしてから
MySQLで書いてあるDBをNode.jsから利用する - Qiita
事務所のMySQLで書いてあるDBをNode.jsで利用しようと思って、今日は node-mysql https://github.com/felixge/node-mysql を使ってみました、の巻。 インストール node-mysqlのREADMEには、npm install mysql@2.0.0-alpha3 と書いてありますが、 試しに npm install mysql とやると mysql@0.9.6 が入ってしまいます。 でも、-alpha3って微妙に嫌だなぁ、と思いつつnpm install mysql@2とするとやっぱり mysql@2.0.0-alpha3が入るのでした。まいっか。 コードを書く 今日は、今使ってるDBへのアクセスだけなのでとりあえずこんな感じ。 データベース piyo_db テーブル piyotable このMySQLテーブルのUserNO が '0
Express 4 で MySQL に接続 - Qiita
Express 4 から MySQL に接続してみました。 なお、コードは github にあります。(mysql ブランチに移動しました。) https://github.com/hoshi-takanori/express-sample/tree/mysql 準備 あらかじめ MySQL に適当なデータベースとユーザーを作っておきます。 $ mysql -u root -p Enter password: ******** mysql> create database test_db; mysql> grant all on test_db.* to test_user@localhost; mysql> set password for test_user@localhost=password('test_password'); mysql> exit Bye $
mysql
mysql Table of Contents Install Introduction Contributors Sponsors Community Establishing connections Connection options SSL options Connection flags Terminating connections Pooling connections Pool options Pool events acquire connection enqueue release Closing all the connections in a pool PoolCluster PoolCluster options Switching users and altering connection state Server disconnects Performing
Rails4 で MySQL の utf8mb4 を扱う - xyk blog
環境： MySQL Server version: 5.6.19 Rails 4.1.5 iPhone の絵文字を MySQL に登録しようとしたらMysql2::Error: Incorrect string value:...というエラーが出た。3バイトに収まらない4バイトUTF-8を扱うには MySQL 5.5.3 以上でキャラクタセットをutf8mb4にする必要がある。 database.yml の encoding を utf8 から utf8mb4 に変更した。 config/database.yml 修正前： default: &default adapter: mysql2 encoding: utf8 pool: 5 username: root password: socket: /tmp/mysql.sock development: <<: *default dat
MySQL :: Download Connector/J
MySQL Connector/J is the official JDBC driver for MySQL. MySQL Connector/J 8.0 and higher is compatible with all MySQL versions starting with MySQL 5.7. Additionally, MySQL Connector/J 8.0 and higher supports the new X DevAPI for development with MySQL Server 8.0 and beyond. Online Documentation: MySQL Connector/J Installation Instructions Documentation MySQL Connector/J X DevAPI Reference Change
UTF-8 エンコードされた絵文字を MySQL / JDBC で取り扱うには？
2013.06.08 追記：JDBC 接続文字列で characterEncoding / connectionCollation を指定すると思った通りの挙動をしてくれないようなので、別の方法 (多分これが正しい方法) を記載しました。 Unicode における、こんな 感じの絵文字、いわゆる Unicode の 追加面 の文字、Java で言えばサロゲートペアでの表現が必要となる文字を、JDBC 経由で UTF-8 エンコーディングして MySQL のテーブル・カラムに格納しようとすると、以下の例外が発生することがあります。 Caused by: java.sql.SQLException: Incorrect string value: '\xF0\x9F\x98\x81 h...' for column 'col_name' at row 1 at com.mysql.jdbc.S
第6回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（1） | gihyo.jp
mroongaのN-gramについては、bigramだけでなく、uni-gramやtri-gramの他、多数の派生N-gramでのトークナイザに対応しています。さらに2013年5月末リリースのmysql-mroonga-3.04にて、待望のWプラグマに対応しました。これにより、Tritonnからmroongaへ移行する際の障壁はEプラグマのみになったと言えます。 Tritonnから乗り換えるならば、mroongaの1択ですね。 Tritonnからmroongaへ移行する7つのメリット それでは早速、Tritonnからmroongaヘ移行するメリットを見てみましょう。 MySQL 5.6対応であること もはやレガシーとなったMySQL 5.0という縛りがなくなることで、MySQL 5.1以降の先進的な機能を取り入れることができます。特にMySQL 5.6ではその進化が甚だしく、次の点を始めと
![第6回 [実録] MySQL向け全文検索エンジン「Tritonn」から「mroonga」への移行ガイド（1） | gihyo.jp](https://cdn-ak-scissors.b.st-hatena.com/image/square/05b0af51bb41516773d6954ec69cb62b4b24568e/height=288;version=1;width=512/https%3A%2F%2Fgihyo.jp%2Fassets%2Fimages%2FICON%2F2013%2F1099_groonga.png)
MySQLでMyISAMからInnoDBに乗り換える際に知らないとハマる、怖い話 - Y-Ken Studio
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった！さあランチタイムだ！ ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
全文検索エンジンMroonga_エンジニア勉強会20140418
Embulk, an open-source plugin-based parallel bulk data loaderSadayuki Furuhashi
MroongaのラッパーモードでInnoDBを使う落とし穴
Mroonga(ストレージモード)はトランザクション非対応だから、ラッパーモードでInnoDBにしてトランザクション…とか考えているとハマる(かもしれない)落とし穴。 Mroongaのラッパーモードは「データは任意のストレージエンジンに」「転置索引はGroonga上に」作るモードであって、飽くまでGroonga上ではトランザクションは利きません。つまり、こういうことが起こる。 mysql56> CREATE TABLE t1 (num int, val varchar(32), primary key(num), fulltext key(val)) Engine= Mroonga COMMENT= 'engine "innodb"'; Query OK, 0 rows affected (0.09 sec) mysql56> INSERT INTO t1 VALUES (1, 'yoku
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPerに知ってほしいRDBな事
MySQLの全文検索に関するあれやこれや
https://blogs.oracle.com/mysql/post/innodb-%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2-n-gram-parser/
MySQLのバックアップ運用について色々
[ヅ] MySQL + Java で UTF-8 の4バイト文字に対応 (utf8mb4) (2015-02-28)