別のMySQL DBA: 6月 2013

2013年6月29日土曜日

だから面白いを共有しなければならなかった...

MySQLのバグ＃20786は、ケーキを取得！

http://www.youtube.com/watch?v=oAiVsbXVP6k

最後に笑いは最良の部分です。

MySQL Bug #20786 gets cake !

http://www.youtube.com/watch?v=oAiVsbXVP6k

The laugh at the end is the best part.
http://bugs.mysql.com/bug.php?id=20786

2013年6月16日日曜日

PerconaのinnobackupとXtrabackupを使用してMySQLのバックアップとリカバリのスクリプト

Original post: http://anothermysqldba.blogspot.com/2013/06/backup-and-recovery-script-for-mysql.html

だからPerconaはXtrabackup広く使用されているバックアップツールを持っており、彼らは、誰もが多くの場合、いくつかの種類のスクリプトで、このツールを使用して実現しています。これについて語っているページがあります：

以来、私は最近、以前のバックアップを使用する方法の例を与えたポストを。私は同様にどのようにスクリプトバックアッププロセスをへ示してスクリプトを書くかもしれない考え出した。私も少し練習を取得したいので、私はPythonで書いたので、それに加えて年が経ちました。

だから、コードへの導入は以下の通りですが、私は上のスクリプトを配置しているgithubの。
これは、より多くのテストを必要としますが、コードベースをチェックアウトして更新して編集して自由に感じる。

コードはもっとテストしたら、私は例を更新することができますが、私は最初からこのプロジェクトにオープンになりたかった。

このコードが何を計画してものを見ると、おそらく、これらのコマンドを試してみることができるようにshowcommands = 1オプション - それは初期段階にあるので、私が使用することをお勧めします。もちろん、それは、まだ生産システムでは使用しないでください。

それへの最初の紹介：


# ./backup_restore.py --help
Usage: backup_restore.py --process=[fullbackup,incremental,prepare,restore] --help --version --showcommands=1

This program enables you to backup full and incremental backups then prepare
and restore them using Percona's Xtrabackup

Options:
--version show program's version number and exit
-h, --help show this help message and exit
--process=PROCESS What would you like to do --process=
[fullbackup,incremental,prepare,restore]
--debug=DEBUG TURN DEBUG ON 1 OR OFF 0 OR VERBOSE 3
--showcommands=SHOWCOMMANDS
Shows the commands instead of executing them except
for the restore section because we go through that
step by step
--backup_root_directory=BACKUP_ROOT_DIRECTORY
THE ROOT DIRECTORY OF ALL YOUR BACKUPS, You can set
DEFAULT at start of the script
--percona_xtrabackup_location=PERCONA_XTRABACKUP_LOCATION
THE LOCATION OF YOUR xtrabackup FILE, You can set
DEFAULT at start of the script
--datadir=DATADIR MYSQL DATA DIR LOCATION, You can set DEFAULT at start
of the script
--username=DB_USERNAME
MySQL Username, You can set DEFAULT at start of the
script
--password=DB_PASSWORD
MySQL Password, You can set DEFAULT at start of the
script
--default_file=DEFAULT_FILE
MySQL my.cnf file location, You can set DEFAULT at
start of the script
--options=PERCONA_OPTIONS
Additional Options for innobackupex

2013年6月14日金曜日

max_binlog_cache_size

Original post: http://anothermysqldba.blogspot.com/2013/06/maxbinlogcachesize.html

あなたは、データベースのパフォーマンスと安定性を評価するように、それはあなたの変数を確認するには開始されることは非常に可能性があります。

一目で以下の変数への典型的な最初の反応である。何かが私のボックスには、MAXは以下のとおり制限する満たすために、その多くのRAM、あるいはディスク·スペースを持っていない間違っているWAIT ....


MariaDB [(none)]> select @@max_write_lock_count, @@max_binlog_cache_size, @@max_seeks_for_key, @@myisam_max_sort_file_size\G
*************************** 1. row ***************************
@@max_write_lock_count: 4294967295                     -- 4 GB
@@max_binlog_cache_size: 1844674407370954752          --1.6 EB
@@max_seeks_for_key: 429496729                         -- 4 GB
@@myisam_max_sort_file_size: 9223372036853727232        --8 EB

いくつかのバグは、長年にわたって、これらの変数については記載されているように、これらの変数との懸念には一人ではありません。以下は、いくつかのレガシーなもののほんの一部です。

" MySQLは現在4GBより大きいバイナリログの位置で作業することはできません。 "
これらは単なるDEFAULTとMAXの設定であることに留意してください。あなたがより快適に感じさせるためにそれらを調整することができます。


MariaDB [(none)]> SET GLOBAL max_binlog_cache_size = 4294967296;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SELECT @@max_binlog_cache_size;
+-------------------------+
| @@max_binlog_cache_size |
+-------------------------+
| 4294967296 | -- 4GB
+-------------------------+
1 row in set (0.00 sec)

なぜあなたはしたいと思う... それは全く別の話題です。これはただの上限許容と取引はとにかく4ギガバイトに分割取得することです。 " 推奨される最大値は4GBです "ので、そう余りに選択した場合はそれを更新することができます。

MySQLのドキュメントにこれであなたのオプションについて詳しく読む：
http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html#sysvar_max_binlog_cache_size

2013年6月13日木曜日

のFedora 17 x86_64の上でMariaDB 10.0.3アルファインストール

Original post: http://anothermysqldba.blogspot.com/2013/06/mariadb-1003-alpha-install-on-fedora-17.html
MariaDB 10.0.3アルファがリリースされたばかり。
だから、私の前のことを思い出してあなたのそれらのためにMariaDB 5.5インストールポストを、私はそれが10.0.3でどのように動作するかを確認することを決めた。

私がに行っている機能のいくつか好きMariaDBとPerconaリリース。あなたの大きなサポーターであってもMySQLは、機能は背面に移植されていないこれらのリリースで利用可能になったときのMySQLリリースDBAはそれらのオプションを確認し、選択を行う必要があります。

だからインストール....

私は以前の記事から前に言ったように私は、これがインストールされています。だから、僕は最初のアップグレードになります。


 [root@Fedora64 10]# rpm -qa | grep maria 
 mariadb-5.5.31-1.fc17.x86_64 
 mariadb-server-5.5.31-1.fc17.x86_64 
 mariadb-libs-5.5.31-1.fc17.x86_64 
 mariadb-bench-5.5.31-1.fc17.x86_64 
 mariadb-devel-5.5.31-1.fc17.x86_64

だからパッケージは、開始時に矛盾。


 MariaDB-10.0.3-fedora17-x86_64-client.rpm 
 MariaDB-10.0.3-fedora17-x86_64-common.rpm 
 MariaDB-10.0.3-fedora17-x86_64-compat.rpm 
 MariaDB-10.0.3-fedora17-x86_64-connect-engine.rpm 
 MariaDB-10.0.3-fedora17-x86_64-devel.rpm 
 MariaDB-10.0.3-fedora17-x86_64-server.rpm 
 MariaDB-10.0.3-fedora17-x86_64-shared.rpm 
 MariaDB-10.0.3-fedora17-x86_64-test.rpm

[root@Fedora64 10]# rpm -Uhv *.rpm 
 warning: MariaDB-10.0.3-fedora17-x86_64-client.rpm: Header V3 DSA/SHA1 Signature, key ID 1bb943db: NOKEY 
 error: Failed dependencies: 
 libodbc.so.2()(64bit) is needed by MariaDB-connect-engine-10.0.3-1.x86_64 
 MySQL-devel conflicts with (installed) mariadb-devel-5.5.31-1.fc17.x86_64

MariaDB-server-10.0.3-1.x86_64 conflicts with file from package mariadb-server-5.5.31-1.fc17.x86_64
[root@Fedora64 10]#

だから、これはただのVirtualBoxインスタンスで,デモや評価のために、私はちょうど私ができることをすべてを削除し、アンインストールする必要がありました。私は、アップグレードがうまくいくことを期待していたが、これはまだアルファコードです。
すなわち：


 [root@Fedora64 10]# rpm -e mariadb mariadb-server mariadb-bench 
 [root@Fedora64 10]# rpm -e mariadb-libs perl-DBD-MySQL percona-xtrabackup

だから今過去が一掃されていることを...


 [root@Fedora64 10]# rpm -ihv *.rpm 
 Preparing...                ########################################### [100%] 
 1:MariaDB-common         ########################################### [ 11%] 
 2:MariaDB-server         ########################################### [ 22%] 
 3:MariaDB-cassandra-engin########################################### [ 33%] 
 4:MariaDB-client         ########################################### [ 44%] 
 5:MariaDB-devel          ########################################### [ 56%] 
 6:MariaDB-shared         ########################################### [ 67%] 
 7:MariaDB-test           ########################################### [ 78%] 
 8:MariaDB-compat         ########################################### [ 89%] 
 9:galera                 ########################################### [100%]

あなたが過去リコール場合はポストを、私はinit.dのスクリプトにこの時間を持って..


 [root@Fedora64 10]# /etc/init.d/mysql start 
 Starting MySQL..... SUCCESS! 
 [root@Fedora64 10]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 2 
 Server version: 10.0.3-MariaDB MariaDB Server

彼らはパフォーマンスにひどいされていない場合、これらはデフォルトでオンになっていない理由は、私は表示されません：


 vi /etc/my.cnf 
 [mysqld]

userstat=1
# http://www.percona.com/doc/percona-server/5.5/diagnostics/user_stats.html?id=percona-server:features:userstatv2
# https://kb.askmonty.org/en/user-statistics/

feedback=ON 
 # https://kb.askmonty.org/en/user-feedback-plugin/ 
 MariaDB [(none)]> show variables like '%feedback%'; 
 +--------------------------+------------------------------------------+ 
 | Variable_name            | Value                                    | 
 +--------------------------+------------------------------------------+ 
 | feedback_send_retry_wait | 60                                       | 
 | feedback_send_timeout    | 60                                       | 
 ... 
 | feedback_url             | https://mariadb.org/feedback_plugin/post | 
 | feedback_user_info       |                                          | 
 +--------------------------+------------------------------------------+

MariaDB [(none)]> show variables like '%userstat%'; 
 +---------------+-------+ 
 | Variable_name | Value | 
 +---------------+-------+ 
 | userstat      | ON    | 
 +---------------+-------+

問題は私がインストールした後、30秒を見つけました...：


 MariaDB [(none)]> show variables; 
 ERROR 1946 (HY000): Failed to load replication slave GTID position from table mysql.gtid_slave_pos

それはこれまでのところ、それは... 私はそれがインストールされていて、今では確認することができます...

UPDATE：
私は、これを提出しているバグ。 MariaDBチームは私にすぐに戻ったと私はmysql_upgradeを実行し、再起動に失敗したことを指摘した。それは、上記のエラーを修正しました。それが持つすべてのものを表示する必要がありますように、まだ変数が感じているが、これは私の一部に有効な修正と間違いです。 MariaDBチームに感謝します。

もっと知るには：

2013年6月12日水曜日

MySQL < 5.5 replication to MySQL 5.6

Original post: http://anothermysqldba.blogspot.com/2013/06/mysql-55-replication-to-mysql-56.html

フラストレーションの時間後..... あなたはそのMySQLを5.5以下いずれかのバージョンを実行している場合、MySQLは5.6にアップグレードしないように私は単純にそれを配置します。

あなたの正気とタクトにデータを保持するためのMySQL 5.5最初にアップグレードする必要があります。

ブログの記事や情報の多くは、MySQL 5.6でのパスワード変更について利用可能であり、私はそれらをサポートしています。私もMySQLは5.6のパスワードを更新し、ボックスがあったとうまく実行されている。問題は複製だった。私はMySQLのバージョンからMySQL 5.5未満を複製するために持っていたし、それは単に実行されませんでした。私はレプリケーションでまだない運secure_authを無効にしないと接続することもできますが、。

私はアップグレードパスとして、レプリケーションをサポートしていますが、最初にMySQLを5.5時間とスティックを取る。

私は、MySQL 5.5にダウングレードすることになったし、すべてが今、うまく実行されます。ダウングレードにあなたのMySQLバージョンを持っている場合私は私でやったと同じ手順の多くがフォローしなければならなかったマリア双星ポストバックアップボックスを取得します。

2013年6月10日月曜日

Percona Xtrabackup / innobackupexバックアップと復元プロセス

Original post: http://anothermysqldba.blogspot.com/2013/06/percona-xtrabackupinnobackupex-backup.html

これはPercona Xtrabackup / innobackupexを使用する方法の非常に単純な例です。

このMariaDBはただ持って世界データベース例データとして、その中に。
これは、すべてのスクリプトかもしれないけど、今のところ、それはデモを目的としています。

フルバックアップを作成します：

MariaDB [(none)]> create database Start_Of_Demo; -- Just here for the demo
Query OK, 1 row affected (0.00 sec)


[root@Fedora64 src]# innobackupex --no-lock --parallel=4 --user=root --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ --no-timestamp /usr/local/src/fullbackup/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/fullbackup'
130609 15:41:39 innobackupex: Connection to database server closed
130609 15:41:39 innobackupex: completed OK!

[root@Fedora64 src]# ls -al fullbackup/
total 18472
drwxr-xr-x. 6 root root 4096 Jun 9 15:41 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:41 backup-my.cnf
-rw-r-----. 1 root root 18874368 Jun 9 15:41 ibdata1
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:41 world
-rw-r--r--. 1 root root 13 Jun 9 15:41 xtrabackup_binary
-rw-r-----. 1 root root 89 Jun 9 15:41 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:41 xtrabackup_logfile

増分バックアップを作成します。

MariaDB [(none)]> create database incremental_1; -- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]#innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental'
130609 15:47:20 innobackupex: Connection to database server closed
130609 15:47:20 innobackupex: completed OK!

[root@Fedora64 src]# ls -al incremental
total 64
drwxr-xr-x. 7 root root 4096 Jun 9 15:47 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:47 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:47 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:47 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:47 world
-rw-r--r--. 1 root root 13 Jun 9 15:47 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:47 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:47 xtrabackup_logfile

別の増分バックアップを作成します。

MariaDB [(none)]> create database incremental_2;-- Just here for the demo

Query OK, 1 row affected (0.00 sec)

[root@Fedora64 src]# innobackupex --incremental --no-lock --parallel=4 --no-timestamp --user=root --incremental-basedir=/usr/local/src/incremental_last_checkpoint/ --extra-lsndir=/usr/local/src/incremental_last_checkpoint/ /usr/local/src/incremental_2/

xtrabackup: Transaction log of lsn (1597964) to (1597964) was copied.

innobackupex: Backup created in directory '/usr/local/src/incremental_2'
130609 15:49:49 innobackupex: Connection to database server closed
130609 15:49:49 innobackupex: completed OK!
[root@Fedora64 src]# ls -al incremental_2
total 68
drwxr-xr-x. 8 root root 4096 Jun 9 15:49 .
drwxr-xr-x. 6 root root 4096 Jun 9 15:49 ..
-rw-r--r--. 1 root root 260 Jun 9 15:49 backup-my.cnf
-rw-r-----. 1 root root 16384 Jun 9 15:49 ibdata1.delta
-rw-r-----. 1 root root 44 Jun 9 15:49 ibdata1.meta
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_1
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 incremental_2
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 mysql
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 performance_schema
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 Start_Of_Demo
drwxr-xr-x. 2 root root 4096 Jun 9 15:49 world
-rw-r--r--. 1 root root 13 Jun 9 15:49 xtrabackup_binary
-rw-r-----. 1 root root 93 Jun 9 15:49 xtrabackup_checkpoints
-rw-r-----. 1 root root 2560 Jun 9 15:49 xtrabackup_logfile

今、あなたは、これを覚えておく必要があります。

もちろんのデータベースをシャットダウンしなければならない。

あなたはそれがとにかくクラッシュ可能性があり、復元を行っている場合

データディレクトリは空でなければなりません。

サーバは当社のデータディレクトリをクリアし、その後オフになっていることを確認してください。

[root@Fedora64 src]# ps -ef | grep mysql

root 4538 1940 0 15:54 pts/2 00:00:00 grep --color=auto mysql

[root@Fedora64 src]# ls -al /var/lib/mysql/

total 28724

drwxr-xr-x. 8 mysql mysql 4096 Jun 9 15:53 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-rw----. 1 mysql mysql 16384 Jun 9 15:53 aria_log.00000001

-rw-rw----. 1 mysql mysql 52 Jun 9 15:53 aria_log_control

-rw-r--r--. 1 mysql mysql 18874368 Jun 9 15:53 ibdata1

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:53 ib_logfile0

-rw-rw----. 1 mysql mysql 5242880 Jun 9 15:17 ib_logfile1

drwx------. 2 mysql mysql 4096 Jun 9 15:43 incremental_1

drwx------. 2 mysql mysql 4096 Jun 9 15:48 incremental_2

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 mysql

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 performance_schema

drwx------. 2 mysql mysql 4096 Jun 9 15:40 Start_Of_Demo

drwxr-xr-x. 2 mysql mysql 4096 Jun 9 15:16 world

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

今、あなたは、これを覚えておく必要があります。あなたはバックアップと次の増分バックアップを作成するときは、最初の完全バックアップを復元してから、すべての増分バックアップを適用する必要があります。ですから、後でただ最後の増分からリストアフルバックアップを行うことができるとは思わない。別のフルバックアップが必要となる前に、維持する余裕ができますどのように多くの増分バックアップは、常に心に留めておく。

ただ、完全バックアップを復元するには：

innobackupex --copy-back /usr/local/src/fullbackup/

innobackupex: Starting to copy InnoDB log files

innobackupex: in '/usr/local/src/fullbackup'

innobackupex: back to original InnoDB log directory '/var/lib/mysql'

innobackupex: Finished copying back files.

130609 15:54:57 innobackupex: completed OK!

[root@Fedora64 src]# ls -al /var/lib/mysql/

total 18456

drwxr-xr-x. 6 mysql mysql 4096 Jun 9 15:54 .

drwxr-xr-x. 43 root root 4096 Jun 8 19:41 ..

-rw-r--r--. 1 root root 18874368 Jun 9 15:54 ibdata1

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 mysql

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 performance_schema

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 Start_Of_Demo

drwxr-xr-x. 2 root root 4096 Jun 9 15:54 world

[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server

それは、フルバックアップを行いますが、私はその後の増分バックアップを行いました。だから、シャットダウンと一掃データディレクトリなければならないでしょう。なぜですか？あなたはそれを復元し完全に増分バックアップを適用する必要があります。それは、次の例に示すように行われます。

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/

xtrabackup: starting shutdown with innodb_fast_shutdown = 1

130609 15:57:59 InnoDB: Starting shutdown...

130609 15:58:00 InnoDB: Shutdown completed; log sequence number 1597964

130609 15:58:00 innobackupex: completed OK!

今私たちは最初の増分ディレクトリを適用できます。あなたがincremental_1ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。これは、以前のケースではなかった。

innobackupex --apply-log --redo-only /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental/

130609 15:58:42 innobackupex: completed OK!

[ルート@ Fedora64 SRC]＃LS-アルfullbackup /

合計20520

をdrwxr-xr - xに。 7ルートルート4096 6月9日午後3時58分。

をdrwxr-xr - xに。 6ルートルート4096 6月9日15時49分..

-RW-R - rを - 。 1ルートルート260 6月9日15時41分バックアップのmy.cnf

-RW-R -----。 1ルートルート18874368 6月9日15時58分ibdata1を

をdrwxr-xr - xに。 2ルートルート4096 6月9日15時58 incremental_1

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後03時41分のmysql

をdrwxr-xr - xに。 2ルートルートperformance_schema 4096 6月9日午前15時41分

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分Start_Of_Demo

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分の世界

-RW-R - rを - 。 1ルートルート13 6月9日夜03時41 xtrabackup_binary

-RW-R -----。 1ルートルート89 6月9日午前15時58 xtrabackup_checkpoints

-RW-R -----。 1ルートルート2097152 6月9日午後3時58 xtrabackup_logfile

今私たちは第二インクリメンタルディレクトリを適用してみましょう。あなたがincremental_2ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。これは、以前のケースではなかった。

innobackupex --apply-log /usr/local/src/fullbackup/ --incremental-dir=/usr/local/src/incremental_2/

innobackupex：コピー '/ usr/local/src/incremental_2/Start_Of_Demo/db.opt'は/ usr / local / srcに/ fullbackup / Start_Of_Demo / db.opt 'へ

130609夜04時00分09秒innobackupex：完成したOK！

[ルート@ Fedora64 SRC]＃LS-アルfullbackup /

合計20524

をdrwxr-xr - xに。 8ルートルート4096 6月9日16時00分。

をdrwxr-xr - xに。 6ルートルート4096 6月9日15時49分..

-RW-R - rを - 。 1ルートルート260 6月9日15時41分バックアップのmy.cnf

-RW-R -----。 1ルートルート18874368 6月9日午前16時00分ibdata1を

をdrwxr-xr - xに。 2ルートルート4096 6月9日15時58 incremental_1

をdrwxr-xr - xに。 2ルートルート4096 6月9日16時00分incremental_2

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後03時41分のmysql

をdrwxr-xr - xに。 2ルートルートperformance_schema 4096 6月9日午前15時41分

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分Start_Of_Demo

をdrwxr-xr - xに。 2ルートルート4096 6月9日午後3時41分の世界

-RW-R - rを - 。 1ルートルート13 6月9日夜03時41 xtrabackup_binary

-RW-R -----。 1ルートルート89 6月9日午前16時00 xtrabackup_checkpoints

-RW-R -----。 1ルートルート2097152 6月9日午後3時58 xtrabackup_logfile

今私たちはフルバックアップディレクトリを適用してみましょう。あなたがincremental_2ディレクトリが今fullbackupディレクトリに適用されていることを以下の例に見ることができます。これは、以前のケースではなかった。

[root@Fedora64 src]# rm -Rf /var/lib/mysql/*

[ルート@ Fedora64 SRC]＃innobackupex - コピーバックは/ usr / local / srcに/ fullbackup /

[ルート@ Fedora64 SRC]＃chownは-Rのmysql：mysqlのは/ var / libに/ mysqlの

すべてが今復元され、提供されています：

[root@Fedora64 mysql]# mysql

Welcome to the MariaDB monitor. Commands end with ; or \g.

Your MariaDB connection id is 1

Server version: 5.5.31-MariaDB MariaDB Server

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;

+--------------------+

| Database |

+--------------------+

| information_schema |

| Start_Of_Demo |

| incremental_1 |

| incremental_2 |

| mysql |

| performance_schema |

| world |

+--------------------+

参考のために利用可能なリンク。

http://www.percona.com/doc/percona-xtrabackup/2.1/innobackupex/preparing_a_backup_ibk.html

2013年6月9日日曜日

変換エラー最近

それは最近、本ウェブサイト上の変換エラーが発生したことが表示されます。
このような理由から、私は本当に申し訳ありませんが、私はそれが再び起こらないように努めていきます。
それでも問題がある場合は私に知らせてください。

yumをインストールMariaDB / MySQLの災害が、固定

Original post: http://anothermysqldba.blogspot.com/2013/06/yum-install-mariadbmysql-disaster-but.html

だから、これはMariaDB / MySQLを簡単にインストールする必要があります。私は、これがマリアの問題だったと思うが、ちょうど全体のバグではありません。ここで何が起こったのかで、どのように私はそれを修正しました。

yumをインストールmariadbサーバ
その後、私はあなたが以下を参照してください何を持って残りの部分を追加しました。

[root@Fedora64 log]# rpm -qa | grep maria 
 mariadb-5.5.31-1.fc17.x86_64 
 mariadb-server-5.5.31-1.fc17.x86_64 
 mariadb-libs-5.5.31-1.fc17.x86_64 
 mariadb-devel-5.5.31-1.fc17.x86_64

私はそれが私は、/ etc / init.dディレクトリ/ mysqlのファイルを取得しなかったことを奇妙だと思ったが、私はそれと一緒に行った、私は何が起こったのか見てみたかった。

[root@Fedora64 log]# mysqld_safe 
 130608 19:54:36 mysqld_safe Logging to '/var/log/mysqld.log'. 
 130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 
 130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended 
 
 130608 19:54:37 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 
 130608 19:54:37 InnoDB: The InnoDB memory heap is disabled 
 130608 19:54:37 InnoDB: Mutexes and rw_locks use GCC atomic builtins 
 130608 19:54:37 InnoDB: Compressed tables use zlib 1.2.5 
 130608 19:54:37 InnoDB: Using Linux native AIO 
 130608 19:54:37 InnoDB: Initializing buffer pool, size = 128.0M 
 130608 19:54:37 InnoDB: Completed initialization of buffer pool 
 130608 19:54:37 InnoDB: highest supported file format is Barracuda. 
 130608 19:54:38  InnoDB: Waiting for the background threads to start 
 130608 19:54:39 Percona XtraDB (http://www.percona.com) 5.5.31-MariaDB-30.2 started; log sequence number 1597945 
 130608 19:54:39 [Note] Plugin 'FEEDBACK' is disabled. 
 130608 19:54:39 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 
 130608 19:54:39 [Note] Server socket created on IP: '0.0.0.0'. 
 130608 19:54:39 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist 
 130608 19:54:39 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

うわー... 最初の実行と失敗は良い兆候ではありません。これは、新規インストールmysqlディレクトリがインストールされているはずです。私は箱に入って見て回ることができるようにスキップ助成-テーブル - だから私は始めています。

[root@Fedora64 mysql]# ls -la 
 total 28700 
 drwxr-xr-x.  2 mysql mysql     4096 Jun  8 19:58 . 
 drwxr-xr-x. 43 root  root      4096 Jun  8 19:41 .. 
 -rw-rw----.  1 mysql mysql    16384 Jun  8 19:50 aria_log.00000001 
 -rw-rw----.  1 mysql mysql       52 Jun  8 19:50 aria_log_control 
 -rw-rw----.  1 mysql mysql 18874368 Jun  8 19:50 ibdata1 
 -rw-rw----.  1 mysql mysql  5242880 Jun  8 19:58 ib_logfile0 
 -rw-rw----.  1 mysql mysql  5242880 Jun  8 19:45 ib_logfile1 
 [root@Fedora64 mysql]# 
 
 [root@Fedora64 mysql]# mysqld_safe --skip-grant-tables 
 130608 20:02:45 mysqld_safe Logging to '/var/log/mysqld.log'. 
 130608 20:02:45 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql

[OK]をので、始め... と実行それでも大きな問題まだない MySQLテーブルん！

[root@Fedora64 /]# mysql_upgrade 
 Phase 1/3: Fixing table and database names 
 Phase 2/3: Checking and upgrading tables 
 Processing databases 
 information_schema 
 Phase 3/3: Running 'mysql_fix_privilege_tables'... 
 ERROR 1049 (42000): Unknown database 'mysql' 
 FATAL ERROR: Upgrade failed

これは、依然として固定することができます....

[root@Fedora64 /]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 10 
 Server version: 5.5.31-MariaDB MariaDB Server 
 
 Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. 
 
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
 
 MariaDB [(none)]> show databases; 
 +--------------------+ 
 | Database           | 
 +--------------------+ 
 | information_schema | 
 +--------------------+ 
 1 row in set (0.01 sec) 
 
 MariaDB [(none)]> create database mysql ; 
 Query OK, 1 row affected (0.13 sec) 
 
 MariaDB [(none)]> exit 
 Bye

OK今それは私がそれをアップグレードすることができるはずですMySQLテーブルを持っている

[root@Fedora64 /]# mysql_upgrade 
 Phase 1/3: Fixing table and database names 
 Phase 2/3: Checking and upgrading tables 
 Processing databases 
 information_schema 
 mysql 
 Phase 3/3: Running 'mysql_fix_privilege_tables'... 
 OK 
 [root@Fedora64 /]#

OKだから私は、mysqldを停止しなくても、それを始めた - スキップ·助成金、それはちょうどそれをインストールし、結局、私はまだパスワードを設定していない。

[root@Fedora64 mysql]# mysqld_safe 
 [root@Fedora64 /]# mysql 
 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

[OK]をので、私は再びそれを試してみましょう...

[root@Fedora64 mysql]# mysqld_safe --skip-grant-tables 
 
 MariaDB [mysql]> show tables; 
 +---------------------------+ 
 | Tables_in_mysql           | 
 +---------------------------+ 
 | columns_priv              | 
 | db                        | 
 | event                     | 
 | func                      | 
 | general_log               | 
 | help_category             | 
 | help_keyword              | 
 | help_relation             | 
 | help_topic                | 
 | host                      | 
 | ndb_binlog_index          | 
 | plugin                    | 
 | proc                      | 
 | procs_priv                | 
 | proxies_priv              | 
 | servers                   | 
 | slow_log                  | 
 | tables_priv               | 
 | time_zone                 | 
 | time_zone_leap_second     | 
 | time_zone_name            | 
 | time_zone_transition      | 
 | time_zone_transition_type | 
 | user                      | 
 +---------------------------+ 
 24 rows in set (0.01 sec) 
 
 MariaDB [mysql]> select * from user; 
 Empty set (0.00 sec) 
 
 MariaDB [(none)]>  create user root ;

でスキップ助成テーブルが有効になって - ので、私は、次のコマンドを使用することはできません。
''で識別されるユーザーのルートを作成します。

それがゼロの権限を持っているので、だから今、私は名前だけで、rootユーザを持っている。

MariaDB [(none)]> show databases; 
 +--------------------+ 
 | Database           | 
 +--------------------+ 
 | information_schema | 
 +--------------------+ 
 1 row in set (0.00 sec)

だから私は、再び箱に行かなければならない - スキップ·助成金の表は、有効になっており、rootアカウントを更新する

UPDATE user 
 SET Select_priv = 'Y', 
 Insert_priv='Y', 
 Update_priv='Y', 
 Delete_priv='Y', 
 Create_priv='Y', 
 Drop_priv='Y', 
 Reload_priv='Y', 
 Shutdown_priv='Y', 
 Process_priv='Y', 
 File_priv='Y', 
 Grant_priv='Y', 
 References_priv='Y', 
 Index_priv='Y', 
 Alter_priv='Y', 
 Show_db_priv='Y', 
 Super_priv='Y', 
 Create_tmp_table_priv='Y', 
 Lock_tables_priv='Y', 
 Execute_priv='Y', 
 Repl_slave_priv='Y', 
 Repl_client_priv='Y', 
 Create_view_priv='Y', 
 Show_view_priv='Y', 
 Create_routine_priv='Y', 
 Alter_routine_priv='Y', 
 Create_user_priv='Y', 
 Event_priv='Y', 
 Trigger_priv='Y', 
 Create_tablespace_priv='Y' 
 WHERE user = 'root';

今すぐ再起動することなく - スキップ·助成金の表は、有効になっており、私はrootでいます！

[root@Fedora64 /]# ps -ef | grep mysql 
 root      4522  1513  0 20:26 pts/0    00:00:00 /bin/sh /bin/mysqld_safe 

 mysql     4650  4522  0 20:27 pts/0    00:00:03 /usr/libexec/mysqld 
--basedir=/usr --datadir=/var/lib/mysql 
--plugin-dir=/usr/lib64/mysql/plugin --user=mysql 
--log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid 
--socket=/var/lib/mysql/mysql.sock 
 root      8348  3178  0 20:47 pts/1    00:00:00 grep --color=auto mysql 
 [root@Fedora64 /]# mysql 
 Welcome to the MariaDB monitor.  Commands end with ; or \g. 
 Your MariaDB connection id is 2 
 Server version: 5.5.31-MariaDB MariaDB Server 
 
 Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. 
 
 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 
 
 MariaDB [(none)]>

やれやれ。これは、物事がうまくいかないけど、私はまだます。/ etc / init.d / mysqlのファイルが欲しかったときにそれを修正する方法の例の詳細です

2013年6月8日土曜日

ピボットテーブル]または[いいえピボットテーブル

Original post: http://anothermysqldba.blogspot.com/2013/06/piviot-table-or-no-pivot-table.html

このトピックでは、最近になって上に来forums.mysql.comサイト。

表明意見はピボットテーブルが拡大するのは非常に困難であり、それは代わりにピボットテーブルのスキーマの再設計の価値があるでしょう維持するということでした。これは有効なポイントで有効な意見です。

私は私の視点を表現し、他人のためにそれを用意して助けるためにここにトピックを追加したいと思います。

これは、すべてのピボット·テーブルかどうかを使用する必要がある場合に収集されたデータに依存します。で与えられた例の以前の記事私が、彼らがどのように動作するかのほんの一例であった。

あなたが知られているユーザー情報（最初と最後の名前、アドレス情報、電話番号）を収集している場合は、yesとピボットテーブルは、あなたが必要となるかという、より複雑です。あなただけの、コア情報の外にそれらを結ぶために、いくつかのデータ·ポイントを持っている場合は、yesを別のテーブルには、ソリューションであり、単純な結合で結ば。

それはあなたが収集している事業体あたりのデータの動的な量のためのものであるときに、ピボットテーブルのコンセプトは有効です。
あなたは、100人のユーザーのために10個のデータポイントが必要になる場合があります。あなたは次の100ユーザーに500のデータポイントが必要になる場合があります。スキーマは簡単にそれを扱うことができますか？

で与えられた例以前の記事私は同意は、ピボット·テーブルを必要としません。しかし、私はちょうど聞かれる質問に答えるフォーラムで私に与えられた概念を使用していました。

理想的には、自分のスキーマの両方のソリューションを使用することができます。コアデータポイント列に保つ。動的データは、ピボットテーブルに保つ。

それが正しく構築されている場合、それは非常にスケーラブルであり、私はピボット·テーブルに格納されたデータの十億は簡単に私にこれを証明した。それはそれはいくつかの作業を必要としないという意味ではありません。あなたは非常によく他の人がデータを収集するために、ピボットテーブルに見えるいくつかのビューまたはサマリー表を作成することは容易になるだろうことを見つけるかもしれない。これは、データが最初の場所でそのように保存されていませんでした、なぜ質問を頼む？再度、それはあなたのデータとデータを使用するアプリケーションの動的な性質に依存します。

メモリとテンポラリテーブル

Original post: http://anothermysqldba.blogspot.com/2013/06/memory-and-temporary-tables.html

私はブログで答えforum.mysql.comの質問を支援するための要求を受けているので、私はここにいくつかの拡張の例を投稿していきます。

私は、この記事に気づい： http://forums.mysql.com/read.php?10、588192,588192＃MSG-588192を、私は最初の状況を処理する別の方法を考えた。

あなたは一時的な情報を処理するためのテーブルが必要な場合は2つの方法でそれについて移動することができます。それはセッション処理あたりであれば一つは、あなたは唯一の一時テーブルを作成する必要があります。

CREATE TEMPORARY TABLE `temporary_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ;

これはNO。FRMファイルになりますし、離れて行くとセッション閉じます。

あなたが長く、それが利用できる必要があると高速であるためにそれが必要な場合は、MEMORYテーブルを使用することができます。は、データベースを再起動するまで、これは滞在するなど、テーブルを削除..

CREATE TABLE `memory_table` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`date_updated` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE=MEMORY;

これが再びNO。FRMファイルを意味します。

あなたはあなたが、次のリストを見つけることができますので、多くのか何かを持っているので、メモリテーブルをクリーンアップに行きたいのであれば...

SELECT TABLE_SCHEMA, ENGINE, COUNT(*) AS count_tables,
SUM(DATA_LENGTH+INDEX_LENGTH) AS size,
SUM(INDEX_LENGTH) AS index_size FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('mysql', 'INFORMATION_SCHEMA')
AND ENGINE = "MEMORY" GROUP BY TABLE_SCHEMA, ENGINE;

いつものように... あなたとあなたのアプリケーションのために最適なものをあなたのニーズやベンチマークを見直す。

登録: 投稿 (Atom)

Pages

2013年6月29日土曜日

2013年6月16日日曜日

2013年6月14日金曜日

2013年6月13日木曜日

2013年6月12日水曜日

2013年6月10日月曜日

2013年6月9日日曜日

2013年6月8日土曜日