MySQL 総合 Part26 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
my.cnfやmy.cnf.d以下のファイルを少しでも編集すると、
ERROR 2002
/var/lib/mysql/mysql.sock(13)や(2) (111)
となります。
それらは編集してはいけないものだとすれば、
どれを編集すべきなのでしょうか?
CentOS7.3 MariaDB 5.5.52です。 テラタームで一画面に表示できないような、縦にも横にも長いテーブルを表示させると、
どこかに変な改行が入った様な画面になることが有ります。変な改行をなくす事はできますでしょうか。
具体的には、100列全てテキスト型のテーブル(20万行程度)が綺麗に表示できません。
「どこかに変な改行が入った様な画面」というのはこんな画面です。
※下記の例は、イメージを伝えるために、適当なサイトから引っ張ってきたもので、
実際のテーブルは異なります。
mysql> select * from eiga;
+----+--------------------+-------------+------+
| id | title | genre | year |
+----+--------------------+-------------+------+
| 1 | Star Wars | SF | 2015 |
←変な改行
| 2 | Back To The Future | SF | 2015 |
←変な改行
| 2 | City Of God | SF | 2015 |
+----+--------------------+-------------+------+
pagerはlessを使っています。(SQL>pager less -F)の設定で使っています。
また、ページャのpager less -S -Fの設定で確実にずれるのは、先頭列をを含む表示をさせているときです。
→を押して、画面を横にめくっていくと、ずれたりずれなかったりします。
テーブルで最も長いフィールドは、1バイト文字だと、40文字〜50文字ぐらい
2バイト文字だと、20文字ぐらいです。元データ自体に変な改行が入っているのではないかと、
20万行の元データを確認しましたが、改行が入っていたり、フィールドの値に、\rや\r\n等の変な文字もありませんでした。
各フィールドに、余計なフィールド区切り文字が入っている事もありませんでした。
テーブルはlaod data infile 〜〜で改行コードも、フィールド区切り文字も指定しました。
確認した範囲は以上です。他にお伝えすべき情報がございましたら、ご指示ください。
宜しくお願いいたしします。 すみません、一部訂正があります。推敲が足りませんでした。
テラタームで一画面に表示できないような、縦にも横にも長いテーブルを表示させると、
どこかに変な改行が入った様な画面になることが有ります。変な改行をなくす事はできますでしょうか。
具体的には、100列全てテキスト型のテーブル(20万行程度)が綺麗に表示できません。
「どこかに変な改行が入った様な画面」というのはこんな画面です。
※下記の例は、イメージを伝えるために、適当なサイトから引っ張ってきたもので、
実際のテーブルは異なります。
mysql> select * from eiga;
+----+--------------------+-------------+------+
| id | title | genre | year |
+----+--------------------+-------------+------+
| 1 | Star Wars | SF | 2015 |
←変な改行
| 2 | Back To The Future | SF | 2015 |
←変な改行
| 2 | City Of God | SF | 2015 |
+----+--------------------+-------------+------+
pagerはlessを使っています。(SQL>pager less -F)の設定で使っています。
また、ページャのpager less -S -Fの設定で確実にずれるのは、先頭列をを含む表示をさせているときです。
→を押して、画面を横にめくっていくと、ずれたりずれなかったりします。
テーブルで最も長いフィールドは、1バイト文字だと、40文字〜50文字ぐらい
2バイト文字だと、20文字ぐらいです。元データ自体に変な改行が入っているのではないかと、
20万行の元データを確認しましたが、行末以外に改行が入っていたり、フィールドの値に、\rや\r\n等の変な文字もありませんでした。
各フィールドに、余計なフィールド区切り文字が入っている事もありませんでした。
テーブルはcreate tableをして、laod data infile 〜〜で改行コードも、フィールド区切り文字も指定し、データを流しました。
確認した範囲は以上です。他にお伝えすべき情報がございましたら、ご指示ください。
宜しくお願いいたしします。 >>6
ターミナルなんか捨てれば。
MySQL Workbenchがオススメ。 columnstore使ってる人いますか?
200万件ぐらいだと集計めっちゃ早かったんだが 「データベース」って一体何なの?
俺ん中でDB言うたらMySQLのイメージなんだよね。
DBエンジンがあって、ディレクトリ構造持ってて、
データはバイト化されて格納されてるって感じなのよ。
ところが、テキストファイル1枚あって、「これがDBです。」って
いわれても、「は?」ってなるわけよ。
あとなんでDBって絵だとタルみたいな形してんの? >>12 「ファイル」との違いは?
なんでタルなの? >>10
mysqlはdbmsやぞ、壮大な勘違いしとるなお前w >>15
> オラクル社によるオープンソースのRDBMS、MySQLの総合スレです。
の解釈次第だな。
ID:JqaOw3r6
が、データベース一般の質問なのか、MYSQLとして答えてほしいのかがわからんからな。 >>16
わからんなら答えんでもいいんやで
お前にはその自由があるんや >>17
お前にもその自由があるんやで
おまえやて、わからんから答え書いてへんのやろ >>18
なんでエセ関西弁使うの?
気持ち悪いよお前、関西弁関係ないけどw >>19
あそれあそれガイジが出た出たよよいのよいw メンテナンスのために一時的にトリガーの動作を停止させたいんだけど、そういう時は一旦dropして終了後にまたcreate…
ですかね。 設定か権限かなかったっけ?
権限を外したらエラーになる? >>22です。
今回考えているのは日付の修正なんだけど、トリガーがその日付の更新時に
その日付データの更新前の日付を別テーブルにinsertするもので、つまり
insertはしないようにしたいということなんですね。
対象データが履歴テーブルに書き込まれないようにすれば良いので。
権限とかはどうなんだろう。同じユーザーで作業するので、それはいじりたく
ないんですが。 今の職場の制作してるサイトのMYSQLのバージョンが5.6.10であることが判明したが
これってヤバイ?
2013年2月にリリースされたバージョンで
mysqltunerで脆弱性の数を見ると
200以上ある
4年半以上も前のなら
そらそうなるか まさかMySQL自体は外に晒してないやろ?
そうでなければ、MySQLの脆弱性を突かれるときには、すでにサーバーに侵入されとるやないか。
心配する意味があんの? >>29
Amazon RDSってサーバーらしいけど
これ使ってても手動アップデートが必要なのかね
外に晒してないって
同じサーバーに立ててlocalhostだけから接続するようにするか
違うサーバーでも接続出来るIPを制限するとか?
mysqltunerの警告に
User 'foobaruser@%' hasn't specific host restriction.
ともあるから接続IPは制限されてないと思われる
ヤバイ? RDSのインスタンスが動いてるホスト名が分かれば外からでも接続出来そうだが
関係者しか分かんないよな?
もしホスト名が漏れたら
脆弱性でデータが流出したり書き換えられたり
サーバーが止まったり等の被害が予想されるが・・・ MySQL以前に、そのサーバーにはファイアウォールがないのか?
ないんだったら、そっちのほうが問題じゃないか? ファイアウォールあれば
アップデートの適用は不要・・・な事は無いよね? 程度問題だろ。
完璧じゃなきゃイカンのか?
アップデートしたいならすればいい。 ちゃんとファイアーウォールが設定してあればmysqlに直接侵入は出来ないだろう
アプリケーションサーバー側の防護が不十分で
侵入できればmysqlにもアクセス出来るだろうけど
そっちに侵入できた時点でもう色々終わってるよね
脆弱性にはroot取得を可能にする物とかあるっぽいけど
root取得してまで仕込みたいウイルスって何だ まあ何層も防護があれば全て破られる可能性は低くなるな >>36
アプリサーバーへ侵入してDBサーバーへのアクセス権を入手できたからといって
DBサーバーのデータすべてを抜いたり改ざんしたり管理者権限を奪取できるとは限らない
だから被害の度合いが違ってくる
単に侵入を防ぐだけでなく被害を抑えるためにも多段防御+早期検知が重要 そもそも、そこまで心配しなければいけないものなのか?ということは、立ち止まって考えてみよう。
アップデート作業やそのあとの動作検証など、いろいろやらないといけないことがあるんだから。 会社で使ってる場合は>>39さんの言うようにやることが沢山あるから気軽に出来るものではないけど、
個人で使ってる人はバージョンアップよくする?
自分は現在5.6.20のままで次バージョンアップするのはPC買い換える時にと思ってるけど。 MariaDBとMySQLって、結局どうなるの?
やっぱMariaDBが主流になるのかな Oracleに飼い殺しされるとか危惧されてたけど
8.0も出るみたいだし、このまま使い続けそう Oracleを信じていいのか?
Java、Solaris、Sunの現状を知っているか? 去年のなつだったか、脆弱性の問題が出て
Mariaは即時対応したけれど
Oracleはしばらく放置していなかったよね >>45
知れよ!w
端的な印象を言えば、飼い殺しだ。 Auroraって言うのを使えば良くね?
あれもMySQL互換でしょ なんだかんだ言っても結局、一番まともなのはOracleだから仕方ない。 innodb_log_buffer_size
innodb_log_file_size
この項目を入れるとエラーになるようになりました。
今、サーバーが死んでしまい、新たに1から構築し直しています。
バックアップしてあったmy.cnfファイルを使っていますが、
各種設定ファイルはバックアップから引き継いで(もしくは目視で見ながら書き写し)で設定しているので、
ほとんどの設定は同じに近いと思います。
サーバーに触れるのは初めてでなんとか構築した状態で、
もはやその時何をやったか記憶が曖昧です。
my.cnf.d内の各ファイルは未編集で、編集したのはmy.cnfだけでした。
php.iniもバックアップからの復元です。
何か違う場所で編集することがあるのでしょうか?
MariaDB 5.5.56です。 ■ このスレッドは過去ログ倉庫に格納されています