2013年9月25日水曜日

グローバルコミュニティをMySQLの

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-global-community.html


私はこのブログへの応答によって勇気づけするので、それを読んだことのすべてに感謝

MySQLの以来グローバルなコミュニティです私は私がこのブログを経由して追跡していることをグローバルな関心を指摘したい考え出した。決してこれは、地域ごとの全体的なMySQLの唯一の関心を決定することができます。しかし私は別の国/言語に着目していることをのトピックを参照することは興味深い発見した。トピックは、実際に変化はない。たぶん、あなたはまた、有用な何かを見つけることができますし、多分それは、英語以外のコミュニティに、より直接的な支援を助けることができる

私は別のブログを反映するためにではなく、代わりに言語によってそれを打破することはありません。


English:






Chinese:




Japanese:





Spanish:




Portuguese:







MySQLをYUMレポ(Oracleの、MariaDBとPercona)

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-yum-repo-oracles-mariadb-and.html

例えばMySQLの最新のRPMをダウンロードの上、関連するソフトウェアをインストールする際に多くの人々は、今日のyumパッケージマネージャに固執することを好む。

あなたがベンダーからRPMSをダウンロードして、yumを(yumをインストール*。rpmの)を使ってインストールできますが、あなたはまた、MySQLのパッケージベンダーから直接引っ張ってあなたのyumのリポジトリを更新することができます。 この記事の時点では、あなただけのMySQL 5.6 GAがリリースされたにもかかわらず、MySQLを5.5.13にあなたを取得します2013年2月5 Oracleのレポを介して。 今、MariaDBはMariaDB-5.5.33をリリースしたことを、私はOracleが上の動きを取得し、それらの公共レポを更新します望んでいるだろう。

かかわらず、あなたは何を選ぶかの。 ここでは、あなたが好む何にアクセスできるようにベンダーのレポを設定する方法である。

すべてのインスタンスは、フォローして設定するのは簡単です、私が記載しているページがあります。 私が先に行くと同様の例を与える。

私は、これらの例については、CentOSの6 64bit版を使用します。

すべてのケースでは、rootとしてyum.repos.dディレクトリから働くことになります。
CDの/ etc / yum.repos.d


http://public-yum.oracle.com
wgetのhttps://public-yum.oracle.com/public-yum-ol6.repo
#viの公開YUM-ol6.repo
次を見つけて、0から1に有効に編集し、ファイルを保存します。




[ol6_MySQL]
オラクルのLinux 6の名前= MySQLの($ basearch)
BASEURL = http://public-yum.oracle.com/repo/OracleLinux/OL6/MySQL/ $ basearch /
gpgkey =ファイル:/ /の/ etc / PKI / RPM-GPG / RPM-GPG-KEY-オラクル
gpgcheck = 1
有効= 1

yum list | grep MySQL
mysql.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-embedded-devel.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-libs-compat.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-server.x86_64 5.5.34-1.el6 ol6_MySQL
mysql-test.x86_64 5.5.34-1.el6 ol6_MySQL


https://downloads.mariadb.org/mariadb/repositories/
viのMariaDB.repo






MariaDBはあなたに5.5 OR 10を選択するための選択肢を提供していません、私は、この例では5.5を使用していました。


# MariaDB 5.5 CentOS repository list - created 2013-09-24 21:59 UTC
# http://mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/5.5/centos6-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1



MariaDB-Galera-server.x86_64 5.5.32-1 mariadb
MariaDB-client.x86_64 5.5.33a-1 mariadb
MariaDB-common.x86_64 5.5.33a-1 mariadb
MariaDB-compat.x86_64 5.5.33a-1 mariadb
MariaDB-devel.x86_64 5.5.33a-1 mariadb
MariaDB-server.x86_64 5.5.33a-1 mariadb
MariaDB-shared.x86_64 5.5.33a-1 mariadb
MariaDB-test.x86_64 5.5.33a-1 mariadb
galera.x86_64 23.2.6-1.rhel6 mariadb



http://www.percona.com/doc/percona-server/5.5/installation/yum_repo.html
viのPercona.repo

[percona]
name = CentOS $releasever - Percona
baseurl=http://repo.percona.com/centos/$releasever/os/$basearch/
enabled = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-percona
gpgcheck = 1


percona-toolkit.noarch 2.2.4-1 @/percona-toolkit-2.2.4-1.noarch
percona-xtrabackup.x86_64 2.1.3-608.rhel6 @/percona-xtrabackup-2.1.3-608.rhel6.x86_64
Percona-SQL-50-debuginfo.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-client-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-devel-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-server-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-shared-compat.x86_64 5.0.92-b23.89.rhel6 percona
Percona-SQL-test-50.x86_64 5.0.92-b23.89.rhel6 percona
Percona-Server-51-debuginfo.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-55-debuginfo.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-56-debuginfo.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-client-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-client-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-client-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-devel-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-devel-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-devel-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-server-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-server-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-server-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-shared-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-Server-shared-compat.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-shared-compat-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-51.x86_64 5.1.71-rel14.9.589.rhel6 percona
Percona-Server-test-55.x86_64 5.5.33-rel31.1.566.rhel6 percona
Percona-Server-test-56.x86_64 5.6.13-rc60.6.427.rhel6 percona
Percona-XtraDB-Cluster-client.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-debuginfo.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-devel.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-galera.x86_64 2.7-1.157.rhel6 percona
2.7-1.157.rhel6 percona
Percona-XtraDB-Cluster-server.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-shared.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
Percona-XtraDB-Cluster-test.x86_64 1:5.5.33-23.7.6.495.rhel6 percona
jemalloc.x86_64 3.3.1-1.el6 percona
jemalloc-devel.x86_64 3.3.1-1.el6 percona
percona-cacti-templates.noarch 1.0.4-1 percona
percona-nagios-plugins.noarch 1.0.4-1 percona
percona-playback.x86_64 0.6-2.el6 percona
percona-playback-debuginfo.x86_64 0.6-2.el6 percona
percona-playback-devel.x86_64 0.6-2.el6 percona
percona-xtrabackup.x86_64 2.1.5-680.rhel6 percona
percona-xtrabackup-20.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-debuginfo.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-20-test.x86_64 2.0.8-587.rhel6 percona
percona-xtrabackup-test.x86_64 2.1.5-680.rhel6 percona
qpress.x86_64 11-1.el6 percona
qpress-debuginfo.x86_64 11-1.el6 percona

 
うまくいけば、これは、すべての瞬間にあなたの標準リポジトリにあるかもしれないものを超えて更新され得ることができるようにするのに役立ちます。

2013年9月24日火曜日

ERROR 1146(42S02):表が存在しません

Original post: http://anothermysqldba.blogspot.com/2013/09/error-1146-42s02-table-doesnt-exist.html

MySQLの5.6をインストールする際だからうちのいくつかは次のエラーが全体を実行している可能性があります:
  • ERROR 1146(42S02):テーブル 'mysql.innodb_index_stats'は存在しません
  • ERROR 1146(42S02):テーブル 'mysql.innodb_table_stats'は存在しません
  • ERROR 1146(42S02):テーブル 'mysql.slave_master_info'は存在しません
  • ERROR 1146(42S02):テーブル 'mysql.slave_relay_log_info'は存在しません
  • ERROR 1146(42S02):テーブル 'mysql.slave_worker_info'は存在しません
おそらくあなたは、新鮮なデータベースのインストールにこのエラーが表示されたことに驚いている。 あなたが一人ではありません。 問題はしかし、修正可能です。

行うための最も安全なものは、次のコマンドを使用してMySQLデータベースを再インストールすることです:mysql_install_dbを
私は最近、Solaris SPARCの環境上でMySQL 5.6のすべての新規インストール(はい、それは複数回起こった)でこれをしなければならなかった。

あなたが不足しているテーブルを作成するには、次のように使用しようとすることができますが、私はそれが最高のすべてがきれいに保ち、すべてはmysql_install_dbを使用して設定されていることを確認することがわかった。
いくつかは、私は上記ランチの修正をお勧めしませんが、私が好きな私は、すべてが正しくインストールされてリンクされていることを確認するためにmysql_install_dbをを好むと述べた。

私は、このコマンドの使用例を含む他のブログの記事があります:

このトピックについての関連記事:
この表の中から、この全体で実行した場合はmysql_install_dbをスコープの外であなたが始めるのに役立つピーターのブログ記事を参照してください。

2013年9月11日水曜日

mysqld_multiは

Original post: http://anothermysqldba.blogspot.com/2013/09/mysqldmulti.html

だから私は最近で働いていたmysqld_multiは 、私は、これは私は、これらの日は非常に多くのブログ記事に表示されていないのが特徴であったことに気づいた。 彼らは存在しないと私はあなたの参照のため、この記事の下部にあるいくつかを記載しております。

同じハードウェア上で複数のMySQLインスタンスを実行する必要があります :あなたの理由は異なり、それはの概念に来るときにも議論の余地があると思われる。

あなたはテストの目的のために別のMySQLインスタンスをインストールするために、生産インスタンスとして、その後、あなただけで動作するはずではないしたい場合は、任意の混乱を避けるために、 MySQLをサンド 多くの人々が一般的に行うようにその場合は動作しないいくつかの理由で、あなたは別のサーバーを実行することができます。新しいのmy.cnfファイルを作成して、mysqld_safeをとカスタムコマンドを使用してMySQLサーバを起動する。

mysqld_multiはは、複数のサーバを実行するためにあなたのために、それは非常に簡単になります。

たとえば、次のように
あなたは、ポート3306上で実行されているセカンダリサーバを持っている。 それはREAD_ONLYスレーブとは、現在のプライマリに障害が発生したときに新しいプライマリサーバになることを待っている場所に多くのハードウェアを持っている。 また、を活用したいと思いますPerconaツールキットと遅延モードで実行されている複製セカンダリサーバを持っている。 あなたに更新できればMySQLは5.6 、あなたは必要はありませんPT-スレーブ遅延が、現在、それはオプションではありません。

どちらのケースでは、予算の限界を持っているし、別のサーバーを許可されていません。 だから、あきらめますか? あなたのセカンダリボックスサーバーの別のバージョンを保持するためのディスク·スペースを持って、なぜしない? カスタムバージョンとなどの開始と停止をしなければならないという考え方は、一部に入れてオフにすることができます。 だから代わりに、my.cnfファイルの新しいバージョンを設定することができますが、最初は、次の操作を行うことができます。

(:VIすなわち)あなたのお気に入りのエディタを選ぶ
vi /etc/multi_my.cnf
[mysqld_multi]
mysqld = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user = mysql
log = /var/log/multi_mysql.log

# Port 3306 Server
[mysqld1]
>socket = /tmp/mysql_3306.sock
port = 3306
pid-file = /var/lib/mysql/mysql_3306.pid
datadir = /var/lib/mysql/
user = mysql
今すぐあなたのmy.cnfファイルから[mysqld]セクションを取ると、この場所にそれをコピーすることができます。

cat /etc/my.cnf >> /etc/multi_my.cnf
あなたは単に上書きコピー[mysqld]セクションを持っているので、クリーンアップするために編集上のコマンドを使用している場合。

その後、3307ポート部を作成することができます。
# Port 3307 Server
[mysqld2]
socket = /tmp/mysql_3307.sock
port = 3307
pid-file = /var/lib/mysql2/mysql_3307.pid
datadir = /var/lib/mysql2/
user = mysql
およびコンフィギュレーションの例をここで見つけることができます:
http://dev.mysql.com/doc/refman/5.6/en/mysqld-multi.html

この例では、私はあなたがPercona Xtrabackupでポート3306サーバーのバックアップを作成し、新しいDATADIRにそれを置きますと仮定します。
innobackupex --defaults-file=/etc/my.cnf --user=root --password=<password> --port=3306 --no-timestamp /var/lib/mysql2/
innobackupex --apply-log /var/lib/mysql2/
今、あなたはmysqld_multiはバイナリ(は/ usr / bin / mysqld_multiは)となりましたこれをテストするか、スクリプトを起動および停止に設定することができます。 テンプレートは、MySQLのインストールに付属している:は/ usr / share / mysqlの/ mysqld_multi.server

あなたinit.dディレクトリにこれをコピーしたり、現在の場所からそれをテストすることができます。
スクリプトは、/ etc / my.cnfにファイルにデフォルト設定されます。 default_file =の/ etc / multi_my.cnfレポート - だから、このテストを開始する

レポートオプションは、サーバが動作しているかどうかを確認するためにstatus引数に似ています。 あなたはシンボリックリンクすることができ、デフォルトのプロセスとしてこれを実行したり、新しい/ etc / my.cnfには、/ etc / multi_my.cnfをコピーすることを選択した場合
/etc/init.d/mysqld_multi.server report 1,2
/etc/init.d/mysqld_multi.server report 1
/etc/init.d/mysqld_multi.server report 2

上記は、各与える引数の異なるMySQLインスタンスへのコースを参照のことのためにあなたが実行してステータスを与えるだろう。 あなたが同じことを行うことができ、次のオプションのすべて:{開始|停止|レポート|再起動を}

すべてがうまくいった場合は、ポート3307上のインスタンスを開始している "2スタート"することができます。 次にログインしxtrabackup_binlog_infoファイルで提供ビンログ位置情報とマスターを変更します。
CHANGE MASTER TO
MASTER_HOST='localhost',
MASTER_PORT=3306,
MASTER_LOG_FILE='<log filename>',
MASTER_LOG_POS=<position>;

Start slave;
今ではあなたのセカンダリスレーブサーバのコピーを持っている。 PT-スレーブ遅延を使用する場合は、次のコマンドを実行することができ、デフォルトは時間の遅延です。
pt-slave-delay --port=3307 --socket=/tmp/mysql_3307.sock --host=localhost

これは、少なくともあなたが始めることができると思います。

2013年9月7日土曜日

secure_authによってブロックされたMySQLアクセスおよびレプリケーション

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-access-and-replication-blocked-by.html

ERROR 2049 (HY000): Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

MySQLデータベースに接続しようとしていて、このエラーが表示された場合、あなたは有効な41byteハッシュパスワードを持っている必要があります。 あなたがわからない場合は、下記のSQLを実行してきた。 あなたは、16文字のパスワードを持っている場合、それらは古いパスワードです。

select Password from mysql.user;

以下は、私はMySQL 5.0からMySQLの5.6への移行の一環として、これを解決する方法です。

MySQL 5.0のサーバは古いプリ4.1パスワードや有効な41byteパスワードの混合物を持っていた。 MySQL 5.0のサーバーは、私は、レプリケーションのセットアップの一部としてMySQLのテーブルをダンプしないことにしました古いパスワードを使っていくつかの口座を持っていたので。 私は、mysqlデータベースを除いて、すべてのデータベースをダンプしました。 これは私が有効なのMySQL 5.6のテーブルの拡張を維持することを保証できます。

MySQLは5.6サーバは、簡単にインストールし、最大だったと私はダンプデータをロードしました。 移行の一部は、彼らが新しいデータベースを評価しながら、レプリケーションを使用することでした。 のMySQL 5.6サーバ上で私は、レプリケーションユーザーアカウントをテストしている間。 私が得た応答は、このページの上部にエラーが発生しました。 レプリケーションが有効なユーザーアカウントなしで、もちろん実行されません。 エラーログは私に、このエラーを与えていた理由はここにあります:
[ERROR] Slave I/O: error connecting to master '<user>@<hostname>:3306' - retry-time: 10 retries: 68, Error_code: 2049

MySQL 5.0のサーバ上のアカウントの簡単なレビューでは、新しいアカウントがあらかじめ4.1パスワードを使用して確立されたことを示した。 だから私は、有効な41バイトのパスワードにアカウントをアップグレードする必要がありました。

次のクエリでは、彼らは確かに古いパスワードが有効になっていなかったことを示した。 だから私はそれを無効にして、有効な41バイトのハッシュとしてパスワードを設定するには、再度ユーザーアカウントを更新する必要があります。

>SELECT @@session.old_passwords, @@global.old_passwords;
+-------------------------+------------------------+
| @@session.old_passwords | @@global.old_passwords |
+-------------------------+------------------------+
| 1 | 1 |
+-------------------------+------------------------+
1 row in set (0.00 sec)


>SET @@session.old_passwords = 0;
Query OK, 0 rows affected (0.00 sec)

>GRANT REPLICATION SLAVE ON *.* TO '<user>'@'<ip_address>' IDENTIFIED BY '<Password>';
Query OK, 0 rows affected (0.00 sec)

パスワードのチェックは今41byteパスワードとしてパスワードを示した。 私は、このセカンダリサーバからプライマリサーバに接続し、secure_authエラーを回避することができました。 複製が容易に接続し、問題が解決した。

今後私は、MySQL 5.6サーバにMySQL 5.0のユーザーアカウントを取得する必要がありました。 (私はセカンダリサーバ構築の一部としてそれらを飛ばさ以来)。

クライアントに関係なく、有効なパスワードのかどうか、ユーザーごとに再び金を​​設定する必要がありました。
だから私は、次のSQLを実行するためにそれらを指示した。 私はこれを行っている可能性が、私は自分のパスワードのすべてを知っている必要がありますし、そのは必要ありませんでした。

彼らのシステム内の各ユーザの。 すでに5.6システム上で有効なrootアカウントを持っているため、rootユーザーを行う必要はありません。

>SET @@session.old_passwords = 0;
>show grants for '<User>'@'<Host>';
各ユーザーが次のコマンドを実行するために必要なSQLを収集するには、次のように
SELECT CONCAT("SHOW GRANTS FOR '",User,"'@'",Host,"';") as sql_command from mysql.user;

それぞれの結果は、 "ショーの助成金"文を実行してから、与えられた文を実行与え。
文は次のようになります。

GRANT USAGE ON *.* TO 'bob'@'%.example.org' IDENTIFIED BY 'cleartext password';

レプリケーションは、その後作成とMySQL 5.6サーバ上のMySQLテーブルを移入。

もっとここで見つけることができます:
http://dev.mysql.com/doc/refman/5.6/en/password-hashing.html

2013年9月3日火曜日

MySQLの最適化ヒント - thread_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/09/mysql-optimization-tip-threadcachesize.html

最近、私は簡単にPROCESSLISTで300から600行で実行されたMySQLデータベースを検出しました。 最大接続数は、同様に、この量を容易倍以上に設定された。 これは私がただに同意しないことをセットとなりました。 それはまた、非常にうまく動作していない自分自身を証明したので、私が呼ばれた。 だからここは私が発見し、プロセス上の私の思考の一部です。

私の考えでは、使用中のMySQLデータベースの大半は、最大接続または1500以上を必要としません。 より多くの接続があなたがあなたのサーバーにもたらす多くのオーバーヘッドを可能にします。 効率的にあなたの接続を使用します。
第二に、使用された接続に対してthreads_createdの%を理解する。 このスレッドがヒット率を作成し検討するかもしれない。 ところで.. これは新しい情報はありませんが、これはいくつかの時間のためにコミュニティに理解されている情報です。 私は他人を助けようとも他の方法でこれを提示するふりをするつもりはありません。 だからあなたの現在の%を理解するために次の手順を実行します。
'Threads_created'のような状態を示し;
セット@ Threads_created = <上記のクエリからの結果>;
'接続'のような状態を示し;
セット@接続= <上記のクエリからの結果>;
"接続のThreads_created%" \ Gとして((@ Threads_created / @接続)* 100) - 100を選択



だからあなたはあなたの割合が何であるか、上記のプロセスを実行した場合? あなたは、これがほぼ100できるだけなりたい。 だから、例えば、私が最近遭遇したサーバは10%未満%を持っていた。 それでは、どのようにこの問題を解決し、あなたの%を上げるのですか?


変数thread_cache_sizeはデフォルトの0を持っています。 あなたが気づくように起動した場合、プロセスが成長しますが、クエリがデッドロックやなどでブロックされていない、あなたは上記のように、あなたの "接続のThreads_created%"をチェックする必要があります。 それは今%が低くなる可能性がある。 あなたは%を上げ、大幅にあなたのサーバ環境に合わせてスイートスポットを見つけることによって、データベースのパフォーマンスを向上させることができます。 thread_cache_sizeはライブ環境で変更することができます。 だから、これは(値を取得するために上記を参照)を使用すると、 "Threads_created"のステータス値を監視し、変数を設定することができます。 これは値の増加し続ける場合は、次に上げるために引き続きthread_cache_sizeを 。 通常私は、一度に500に移行するためのいくつかの時点で25で価値を高めることを好む。 私は頻繁に "接続のThreads_created%"をチェックして 'Threads_created'。 一度あなたが行にドロップするように開始する得るために%とPROCESSLISTに気づくでしょうスイートスポットに近づく。 通常の1以上の調整thread_cache_sizeはスイートスポットにあなたを得るでしょう。

すべてのサーバーと環境が異なっています。
一部のサーバでは、と98%かもしれないthread_cache_size他人との98%を持っていながら、50のthread_cache_size 15000に設定されています。 最大値は16384です。

だから、何もない場合... 調整を行うことを検討まずあなたの割合が何であるかを調べる。