MysqlデータベースをAmazon EC2からRDSにコピーしようとしています。
私はこれを使用してデータベースのmysqldump
をルートフォルダに成功させました:
root@ip-xx-xx-xx-xx:~# mysqldump my_database -u my_username -p > my_database.sql
次に、この.sqlファイルを新しいRDSデータベースに転送しようとしました。
root@ip-xx-xx-xx-xx:~# mysql my_database -u my_username -p -h
my_new_database.xxxxxxxxx.us-east-1.rds.amazonaws.com < my_database.sql
残念ながら、次のエラーメッセージが表示されます。
You do not have the SUPER privilege and binary logging is enabled
(you *might* want to use the less safe log_bin_trust_function_creators variable)
GRANT SUPER..
をさまざまな方法で試しましたが、それをしようとするとエラーが発生します。 mysql > FLUSH privileges;
を入力しても機能しません。
私はmysqlの初心者なので、このような簡単な質問には申し訳ありません。考え?
http://getasysadmin.com/2011/06/Amazon-rds-super-privileges/ ごとに、log_bin_trust_function_creators
を1に AWSコンソール で、エラーなしでダンプファイルをロードします。
これらのエラーを無視し、残りのダンプファイルをロードする場合は、-f
オプション:
mysql -f my_database -u my_username -p -h
my_new_database.xxxxxxxxx.us-east-1.rds.amazonaws.com < my_database.sql
-f
はエラーを報告しますが、ダンプファイルの残りの処理を続行します。
ダンプファイルのトリガーとストアドプロシージャの問題は、これらの定義に、ストアドプロシージャを作成するユーザーであるDEFINERが含まれていることです。ほとんどの場合、ユーザーはRDSに存在しないため、エラーが発生します。ダンプファイルをロードできるようにするには、sedまたはPerlを使用してDEFINERを削除し、インポートを実行しているユーザーでストアドプロシージャ/トリガーを作成します。
Perl -pe 's/\sDEFINER=`[^`]+`@`[^`]+`//' < mysqldump.sql > mysqldump.fixed.sql
これで、固定ダンプファイルをロードできるはずです。
mysql my_database -u my_username -p -h rds_Host < mysqldump.fixed.sql
前の回答で述べたように、DBパラメーターを設定する必要があります。
log_bin_trust_function_creators = 1
AWSのドキュメントトリガーで定義されているように、バイナリロギングはデフォルトで有効になっているため、プロシージャと関数はデフォルトで無効になっています。基本的に無効にするとデータベースの安全性が向上しますが、ネットワークを介して適切に保護されていれば問題ありません。
以下の手順に従ってください。問題は修正されます https://aws.Amazon.com/premiumsupport/knowledge-center/rds-mysql-functions/
また、プロシージャの作成時に定義者を使用しないでください。単純なsedコマンドで削除できます。
編集に加えて
log_bin_trust_function_creators = 1
ダンプファイルからすべて[〜#〜] definer [〜#〜]を削除する必要があります、次のリンクを確認してください[〜#〜] sed [〜#〜]コマンドSQLダンプファイルのクリーニングを支援します。
私の場合、ダンプファイルにはSUPER権限が必要な2つのコマンドしかありませんでした。
SET @@GLOBAL.gtid_purged
SET @@SESSION.SQL_LOG_BIN
mysqldump docs によると、--set-gtid-purged=OFF
でこれらを無効にできます。
次に man mysqldump を見てください:
ダンプされたサーバーからのデータの一部のみを使用して新しいレプリケーションスレーブを展開する場合は、ONを使用します。トポロジ内でテーブルをコピーして修復する場合は、OFFを使用します。 OFFを使用するのは、相互に分離されたままであるレプリケーショントポロジ間でテーブルをコピーする場合です。
そこで、--set-gtid-purged=OFF
をmysqldump
コマンドに追加し、結果のダンプファイルを正常にインポートすることにしました。
Arun-rの回答を使用した後、問題が解決しない場合は、ダンプファイルを変更する必要があります。それは単純だ。
ダンプファイルには、次のような行があります。
DELIMITER ;;
CREATE DEFINER=`username_from_dumped_database`@`Host_from_dumped_database` PROCEDURE `procedure_or_function_name`()
BEGIN
交換する必要があります:
username_from_dumped_database
rdsデータベースのユーザー名。Host_from_dumped_databse
沿って %
理由はわかりませんが、このトリックは私にとってはうまくいきました。これを行うには、単純なテキストエディタで十分です。