問題点 MySQL5.5以前では4byteのutf8文字列を入れることができない ⇒日本での絵文字などはこれにあたる。 ⇒他の国の言語も一部ここにあたる 現象 実際に入れてみると、4byte文字を境に後ろの文字列が全て消えてしまう。すっぱりと・・・! あい[絵文字]うえお->あい abc[絵文字]def->abc どんなに長い文字列も絵文字の部分から後ろが全部切れてしまうorz CHARCODE設定 CHARCODE設定をutf-8からutf8mb4に変更 skip-character-set-client-handshake設定 skip-character-set-client-handshakeを入れるといいよ!という記事があるものの、利用環境によるかもしれない。 SQLインジェクションの脆弱性がある。 利用している環境にあわせてskip-character-set-client-h
opscodeのリポジトリにあるMySQLのcookbookでは、rootユーザやレプリケーション用のユーザのパスワードをランダムに生成して設定している。 opscode の recipe の特徴 このランダムという点をカバーするべく、うまい仕組みが組み込まれている。 パスワードを設定するところは node.set_unless['mysql']['server_root_password'] = secure_password といった形で、attributeに設定されていない場合はランダムに生成するという事をして、2度目以降も同じパスワードとなるようになっている。 2回目以降も同じパスワードを保証するために、もうひとつの技が unless Chef::Config[:solo] ruby_block "save node data" do block do node.save end
Unlike Light’s older phones, the Light III sports a larger OLED display and an NFC chip to make way for future payment tools, as well as a camera.
Oracle is holding back test cases in the latest release of MySQL. It’s a move that has all the markings of the company’s continued efforts to further close up the open source software and alienate the MySQL developer community. The issue stems back to a recent discovery that the latest MySQL release has bug fixes but without a single one having any test cases associated with it. That creates all
元旦の夜だっていうのにこんなしょーもないことで一時間半も… クライアント機からTCP/IP経由で全然接続ができない… 最近MySQL全然使ってないのでよぉわからん… そんな夜に。 mysql.userテーブルのuserとhostカラムを何度も何度も確認して、Enter passwordも指一本で丁寧に丁寧に押してやっても、こんなエラーしか返ってこないときは十中八九これが原因、と言いきってやる! DBサーバのmy.cnfに、 [mysqld] bind-address = クライアントが接続できるIPアドレスと書くべし!書くべし!書くべし!なければMySQLのベースディレクトリっぽいところに作っちゃえばおk. そのへんは雰囲気で。 これが書いていないとlocalhostからしか接続ができないみたい。 あ。 明けましておめd
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
重要なデータを暗号化して安全に保護するセキュアサーバアプライアンス Security-GENERALは企業で取り扱うさまざまな重要データを暗号化して安全に保護します。暗号鍵の厳密な管理や複数の管理者による役割分離、ファイアウォール、ログ、レポートなどの機能を有し、重要なデータを簡単かつ安全に管理できます。 Security-GENERALはPCI-DSSにも対応しています。PCI-DSSでは、クレジットカード情報の取り扱いに対して厳しい条件が具体的に定められています。Security-GENERALは、その厳しい条件をクリアすることを目的として開発されました。Security-GENERALを利用することにより、PCI-DSSで求められる高度なセキュリティ要件に対して適切に対応することが可能になります。
本年4月から個人情報保護法が本格施行され,セキュリティに対する関心や必要性が高まっている。データベースは様々なデータを格納しており,重要なセキュリティ対策対象である。MySQLは,ネットワーク上の盗聴に対応するための暗号化接続をサポートしている。今回は,MySQL 5.0を使用した,SSLによる暗号化接続の設定方法を紹介する。 ネットワークの盗聴による情報流出 MySQLをデフォルトの状態で使用するとサーバーとクライアント間の通信は,暗号化されずに送受信される。これらのパケットは,パケット・キャプチャ・ソフトを使用すれば,簡単に参照することができる。例えば,リスト1のような処理をクライアントで実行したとする。 リスト1●テーブル「member」の内容参照 mysql> select * from member; +----+-------+------------------+------
DBを作る上で必ず悩んでしまう問題。 もし、もし、仮にDBからレコードのデータを全部ぶっこぬかれた場合、そこに個人情報が載っかってると非常にマズイ。 だから、もし、もし、仮にDBからレコードをぶっこぬかれても、データとして意味が内容に、暗号化しておけないか・・と。 DBに格納されている時は暗号化されておいて、スクリプトから取り出した時点で、復元されているという感じ。 MD5やCRYPTは、一方通行なため、暗号化する前のデータがわかってなければ使えない。 どうしたらいいものかと調べたので、結果をここにまとめる。 環境:MySQL 4.0.2以降 phoneというカラムがあり、これを暗号化する。 INSERT INTO test( phone ) VALUES ( AES_ENCRYPT( '0120-000-1234', 'secret_key' ) )
多くの暗号化関数および圧縮関数では、結果に任意のバイト値が含まれている可能性のある文字列が返されます。 これらの結果を格納する場合は、VARBINARY または BLOB バイナリ文字列データ型のカラムを使用します。 これにより、バイナリ以外の文字列データ型 (CHAR, VARCHAR, TEXT) を使用している場合など、データ値を変更する可能性がある後続の領域削除または文字セット変換の潜在的な問題を回避できます。 一部の暗号化関数は ASCII 文字の文字列を返します: MD5(), SHA(), SHA1(), SHA2(), STATEMENT_DIGEST(), STATEMENT_DIGEST_TEXT()。 戻り値は、character_set_connection および collation_connection システム変数によって決定される文字セットと照合順序を持つ文
接続プーリングは、すべてのスレッドが必要な接続をすぐに使用できるよう、接続のプールを作成し管理する方法です。 接続をプールするこの方法は、ほとんどのアプリケーションは、普通数ミリ秒で完遂できるトランザクションを積極的に処理している時に、スレッドが JDBC 接続にアクセスすることだけを必要とするという事実に基づいています。トランザクションを処理していない時、接続はそうでなければ待機します。代わりに、接続プールは他のスレッドに、待機接続を有効に利用することを許可します。 実際には、スレッドが MySQL や、JDBC を使用する他のデータベースに対して作業を行う時、プールからの接続を要求します。スレッドは接続を使い終えたらそれをプールに戻し、他のスレッドが使用できるようにします。 接続がプールから貸し出されると、要求したスレッドが独占的にそれを使用します。プログラミングの観点からは、スレッド
いっつも忘れちゃうから残します。 以下の設定を加えることでプールされているコネクションの接続チェックしてくれます。 (切断されちゃってた場合、再接続してくれます。) Tomcatのと言うより、DBCPのってのが正しいのかな? testOnBorrow="true" validationQuery="select 1 from dual" 実際の定義ファイルでは↓こんな感じかな。 <Resource name="jdbc/repositoryDataSource" auth="Container" type="javax.sql.DataSource" maxActive="20" maxIdle="10" minIdle="2 initialSize="2" maxWait="10000" testOnBorrow="true" validationQuery="select 1 from
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く