保護中: Syniti Data Replication (DBMoto) 9.6.3.2リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

コメントを読むにはパスワードを入力してください。 -->

Webセミナー録画 『GCP Cloud SQLへのデータ移行・連携はSyniti DRにお任せ!』2020/03/26 開催

Google CloudのCloud SQL for MySQL、SQL Server、PostgreSQLといったクラウドデータベースの移行や連携手法にお悩みではありませんか?

異種間データベース連携ツール「Syniti Data Replication(旧DBMoto)」であれば、簡単に実現できます!

・オンプレミスからクラウドへデータベースを移行/連携したい
・GCP Cloud SQL、Amazon RDS、Azure SQLといったクラウドデータベース間でもデータ連携を行いたい
・異種データベース間でデータを同期したい

などなど、これらの課題への最適解を本セミナーでご案内します。

https://www.slideshare.net/climb_soft/gcp-cloud-sqlsyniti-dr
タグ: , , , ,

保護中: Syniti Data Replication (DBMoto) 9.6.1.8リリースノート

このコンテンツはパスワードで保護されています。閲覧するには以下にパスワードを入力してください。

コメントを読むにはパスワードを入力してください。 -->

Syniti(旧DBMoto)サーバーの移行方法の選択肢

Syniti(旧DBMoto)サーバー自身の移行が必要になった場合(ハードのリプレイスや検証環境から運用環境への移行など)、移行先や移行の対象などによって方法が異なってきます。
本記事では、3種類の移行方法の違いとどの移行方法を選択すべきかを説明します。

 

1. Synitiサーバーは変更せず、レプリケーション設定のみ移行する場合

レプリケーションエクスポート機能を使用して移行することが可能です。
この機能では指定したソースデータベースとターゲットデータベース間にあるレプリケーションを、同じインスタンスの別スキーマ、別インスタンス、さらには別種のデータベース間にもコピーすることができます。
Synitiサーバーは同じものを使用し続けるが、検証環境から運用環境へレプリケーション設定を移行したい場合に利用可能です。

詳細は、下記をご参照ください。
https://www.climb.co.jp/blog_dbmoto/archives/2148

 
2.異なるSynitiサーバーへ移行する場合

メタデータのバックアップ/リストアで設定情報を移行できます。これはDBの接続情報なども含みます。
レプリケーション対象のDBに変更はなく、Synitiサーバーのみを移行したい場合に利用できます。

詳細は、下記をご参照ください。
https://www.climb.co.jp/blog_dbmoto/archives/3342

 

3.異なるSynitiサーバーへ移行し、DBの接続情報も異なる場合

テーブル構成等は一緒だがDBの接続情報が異なる場合には、メタデータをカスタムリストアする必要があります。
移行先の新環境でDB接続は事前に作成し、そこにレプリケーション設定のみをリストアします。

詳細は、下記をご参照ください。
https://www.climb.co.jp/blog_dbmoto/archives/3354

タグ: ,

CAP定理の壁 ~NewSQLへの道~

前回、「ACID原理とCAP定理」という記事で、NewSQLが生まれた背景を説明しました。説明といっても、ざっくりとNoSQLデータベースが生まれた背景に触れ、でもNoSQLはACID原理に準拠できなくてOLTP(オンライン トランザクション処理)をサポートできないよね そこで、NewSQL登場! つ・づ・く… という流れでした。つづきが気になって気になって食事が喉を通らない読者が餓死してしまわないように、がんばって続きを書きたいと思います。

NewSQLはどうやってCAP定理の壁を乗り越えたのでしょうか?

前記事を読み返すと、最後にこう書いてあります。ならば、話は簡単です。はい、NewSQLはCAP定理の壁を乗り越えていません。めでたしめでたし。

というわけにはいかないので、CAP定理についてもう少しだけ解説しておきましょう。ブリュワーさんが「分散システムでConsistency(一貫性)、Availability (可用性)、Partition-tolerance (分断耐性)の3つを同時に提供できない」と断言したのだから、できないものはできないのです。ブリュワーさんも決して酔った勢いで言ったわけではなく、研究成果として発表したのだし、NoSQLとNewSQLの両者もそこを覆そうとはしていません。

覆すどころか、必死で妥協点を探っています。この3つのうちの2つしか提供できないのなら、さて、どれを捨てるか、と。1つ犠牲にしなければならないのなら、まずPartition-toleranceは捨てられません。複数ノードにまたがるサーバーが、ノード間の連絡が途絶えたらもう機能しない、なんてことは許されません。それが許されるなら、そもそも分散すべきではなかったことになります。そんなことでへこたれるなら、最初から1ノードで貫け!と星一徹に卓袱台返しされてしまいます。

だから、分散システムにPartition-toleranceは不可欠です。

では、ConsistencyとAvailabilityのどちらを捨てるのか?

それならConsistencyでしょう。だって、クラウド時代に可用性は捨てられないし、それに昨今は多様性の時代です。十人十色、複数の見解があって然るべきで、最終的に一致すればそれで良いのです。人はそれをEventual Consistency(結果整合性)と呼びます。たとえば、ソーシャルメディアなど、膨大なデータを処理するために分散システムによる拡張性は重要だし、可用性も捨てられないけど、同時進行の一貫性にはユーザーは気付きもしません。そう、結果的に一貫性が保たれていれば、途中の不備はバレないのです。

なんだ、バレないなら、いいや・・・

という問題ではなく、重要性の問題です。別にズルするのではなく、Consistencyの優先順位を他の2つより下げただけです。NoSQLを責めないであげてください。

でも、AvailabilityをConsistencyより優先したはいいけど、それでAvailabilityは完全なの?と問われたら、NoSQLは何と答えるでしょうか。優秀なNoSQLシステムは、「もちろん、ファイブ ナインズ(five nines)のHA(高可用性)さ!」と胸を張って答えるでしょう。つまり99.999%、これは一年間のダウンタイムが5分半を切る優秀さです。システムの開発者も運用者も十分満足する数字で、誰もはなから100%など期待していません。

え、今、何と・・・?

優先順位を下げられたConsistencyはきっと唖然として、耳を疑っている違いありません。100%じゃないの? じゃあ私を捨てたのは一体何のため? どうせ100%じゃないのなら、パーセンテージを少し下げて、私の100%を目指したらいいじゃない・・・

至極ごもっともです。はなから完全なAvailabilityを諦めているのなら、完全なConsistencyを目指して、どれだけAvailabilityを下げずに済むのかに挑戦したほうが理にかなっています。理にかなっているだけでなく、それでOLTP(オンライン トランザクション処理)もサポートできるのです。

はい、こうやって生まれたのがNewSQLでした。NewSQLデータベースは、スケールアウト可能な分散システムでOLTPをサポートするというニーズ面だけでなく、CAP定理の妥協をできるだけ小さくする観点からも、クラウド時代の申し子としてとして生まれるべくして生まれたデータベースなのです。めでたしめでたし。

次回は、NoSQLがどうやってConsistencyを確立したかについて書くかな? いや書かないかな? ま、ちょっと覚悟はしておけ。

 

 

タグ:

Webセミナー録画とプレゼンテーション『 Oracle コンサルいらずのチューニングことはじめ』:2020/2/6 開催

https://www.climb.co.jp/soft/webseminar/2020/0206/

続きを読む
タグ: , ,

Syniti Data Replication (旧DBMoto)でのスクリプトの書き方④:レプリケーションスクリプト

前回に引き続き、 Syniti Data Replication (旧DBMoto) でのスクリプトの書き方をご紹介、今回はその中でもレプリケーションスクリプトの基本的な使用方法をご紹介します。

レプリケーションスクリプトではレプリケーション中に発生した特定のイベントに対する動作を定義できます。。

  • Visual Basic .NETの標準関数およびMicrosoft.VisualBasic名前空間関数またはC#の
    標準関数のいずれかを使用できます。
  • グローバルスクリプトで定義されたユーザー関数
  • 特定のレプリケーションスクリプトイベント、メソッド、およびプロパティ。

レプリケーションスクリプトエディタを使用して、レプリケーション中に特定のイベントが発生したときに実行されるスクリプトを記述します。スクリプトは、エディタの上部にあるドロップダウンリストから選択した1つ以上の関数で構成する必要があります。

※使用する言語(VBまたはC#)はメタデータ内で統一されている必要があり、デフォルトはC#です。変更する場合はグローバルスクリプトのエディタにて変更します。

ドロップダウンから、以下のレプリケーションイベントを選択できます。

[table id=2 /]

例えば、レプリケーション時のターゲットテーブルに対するSQL  (INSERT, UPDATE or DELETE) 操作に合わせてスクリプトを記述するのであれば以下のように行います。

1.レプリケーションスクリプトエディタでドロップダウンからRecord、onAfterMappingを選択します。これによりイベント時の動作を上書きするための空の関数が挿入されます。

2.Record_onAfterMappingではIRecordメソッドを使用して、対応付けされたソーステーブル上レコード、ターゲットテーブル上レコードを参照できます。

using System;
using System.Data;
using DBMotoPublic;
using DBMotoScript;    
namespace DBRS
  {
   public class ReplicationScript : IReplicationScript
     {
      public override void Record_onAfterMapping(DBMotoPublic.IRecord recSource, 
	       DBMotoPublic.IRecord recTarget, ref bool AbortRecord)
         {
            switch(recTarget.OperationType)
               {
                  case enmOperationType.Insert:
                    if (recTarget.GetValueAfter("SID") == null)
                       {
                          recTarget.SetValueAfter("NAME", null);
                        }
                    else
                        { 
	                    //UpdateSTUDENTFields 
			    (recTarget);
                        }
                        break;
                 case enmOperationType.Update:
                     if (recTarget.GetValueAfter("SID") == null)
                         {
                            recTarget.SetValueAfter("NAME", null);
                         }
                     else if(recTarget.GetValueBefore("SID") == null)
                         {
                            //Field SID was null and now it has a value 
                            //UpdateSTUDENTFields 
	                     (recTarget);
			  }
                     else if(recTarget.GetValueBefore("SID") != recTarget.GetValueAfter("SID"))
                         {
			     //Field SID has changed
                            //UpdateSTUDENTFields 
	                     (recTarget);
			  }
                     break;
                 } 
              }    
        }
   }

この例では、ターゲットテーブルにInsertするときSIDフィールドがNullなら、NameをNullに変更、SIDに値が入っていればそのまま、UpdateするときにUpdate後のSIDフィールドがNullなら、NameをNullに変更、Null以外の場合にはそのまま、処理を行うようにスクリプトを記述しています。

※C#を使用している場合、グローバルスクリプトで定義済みの関数を使用するには、関数名の前にGlobalScriptを付けて下記のように関数が定義されているクラスを識別します。

GlobalScript.AddLog("The current record has been inserted: " + s, 0);

※通常スクリプト内で使用できるフィールドはマッピング設定で対応付けされたカラムのみです。対応付けされていないカラムの値を使用する場合は、レプリケーションプロパティダイアログのマッピング設定にて対象カラムに対して「未マッピング使用」を設定する必要があります。

※複数のイベントがアクセスする必要のあるオブジェクトが存在する場合には注意が必要です。ReaderとWriterのイベント(ソースDBからの読み取り関連イベントとターゲットDBへの書き込み関連イベント)両方がアクセスするオブジェクトに関してロックを行うようにスクリプトに記述する必要があります。

※関数ジェネレータを使用して関数を定義し、スクリプト内で使用することもできます。この時、一覧にはグローバルスクリプトで作成した関数も表示されます。

※ライブラリをスクリプト内のインポートのリストに追加する場合、リファレンスダイアログから追加可能です。

このようにレプリケーションごとにスクリプトを記述し、より柔軟にデータを転送することも可能です。グローバルスクリプトと同様に本ブログでもいくつかサンプルをご紹介していますので、こちらもご参照いただければ幸いです。

タグ: ,

『DBMoto』から『Syniti(スィニティ)Data Replication』へ

Syniti DRロゴ

『DBMoto』はVer9.6から名称を『Syniti(スィニティ)Data Replication(略称:Syniti DR , SDR』に変更しました。今後のサイト内の表示も順次『Syniti Data Replication』に変更してまいります。

タグ:

Oracle, SQL Server データベースをAmazon S3に低コストでバックアップ方法 [ CloudBerry Backup]

CloudBerry Backupを使用してOracle, SQL Server データベースをAmazon S3にバックアップすることが簡単にできます。

SQL Server データベースをAmazon S3にバックアップ方法はちら

Oracle データベースをAmazon S3にバックアップ方法 はこちら

●CloudBerry Backupがサポートするクラウド・サービスはAWS以外にMS Azure、Google Cloud Platformなどでそれらを利用することも可能です。

● クラウドに保存したデータベースのバックアップからのリストアもCloudBerry Backupで簡単に行うことができます。

● クラウド・サービス 以外にもNAS(Network-attached Storage), ローカル・ストレージへのバックアップ が CloudBerry Backupで可能です。

タグ: , , , ,

Syniti(旧DBMoto)レプリケーションに必要なOracleユーザ権限 Trigger使用時

Triggerを使用してレプリケーション実施時に、Oracleユーザに必要な権限は以下の通りです。

ユーザ名をDBMOTOとした場合の例となります。
※ 2024/9/30 更新

●リフレッシュ実施時に必要な権限

ユーザ作成
create user dbmoto identified by DBMOTO;

DBへ接続する権限
grant create session to DBMOTO;

参照、編集権限
grant select any table to DBMOTO;
grant insert any table, update any table, delete any table to DBMOTO;

テーブルを作成する権限
grant unlimited tablespace to DBMOTO;
grant create any table to DBMOTO;

テーブルを削除する権限
grant alter any table to DBMOTO;
grant drop any table to DBMOTO;

 

●ミラーリング実施時に必要な権限

ログテーブルのサイズを制御するための表領域を設定する場合(任意)
create tablespace DBMOTO_TBLSPACE datafile ‘dbmoto_tblspace.dat’ size 100M online;

ログテーブル作成先の表領域を操作する権限
alter user DBMOTO quota unlimited on DBMOTO_TBLSPACE;

DBへ接続する権限
grant create session to DBMOTO;

ログテーブルを作成する権限
grant create any table to DBMOTO;
grant create any index to DBMOTO;

参照、編集権限
grant select any table to DBMOTO;
grant insert any table, update any table, delete any table to DBMOTO;

テーブルを削除する権限
grant alter any table to DBMOTO;
grant drop any table to DBMOTO;

トリガーを作成、削除する権限
grant create any trigger to DBMOTO;
grant drop any trigger to DBMOTO;

シーケンスを作成、削除、参照する権限
grant create any sequence to DBMOTO;
grant drop any sequence to DBMOTO;
grant select any sequence to DBMOTO;

トランザクションログへアクセスする権限
grant select on SCOTT.”_DBM__TRG_OBJS” to DBMOTO;
※SCOTTはログテーブル作成先のスキーマ

 

■権限一覧まとめ

create user dbmoto identified by DBMOTO;
grant create session to DBMOTO;
grant select any table to DBMOTO;
grant insert any table, update any table, delete any table to DBMOTO;
grant unlimited tablespace to DBMOTO;
grant create any table to DBMOTO;
grant create any index to DBMOTO;
grant alter any table to DBMOTO;
grant drop any table to DBMOTO;
create tablespace DBMOTO_TBLSPACE datafile ‘dbmoto_tblspace.dat’ size 100M online;
alter user DBMOTO quota unlimited on DBMOTO_TBLSPACE;
grant create any trigger to DBMOTO;
grant drop any trigger to DBMOTO;
grant create any sequence to DBMOTO;
grant drop any sequence to DBMOTO;
grant select any sequence to DBMOTO;
grant select on SCOTT.”_DBM__TRG_OBJS” to DBMOTO;
※SCOTTはログテーブル作成先のスキーマ

タグ: , , ,

Syniti Data Replication 新機能ブログ③ Hadoop HDFSへのレプリケーション対応強化

Syniti Data Replication 9.6(旧DBMoto)では、Hadoop HDFSへのレプリケーションが強化されました。
元々DBMoto 9.0にてHadoop HDFSへのレプリケーションは対応しておりましたが、
全件レコード転送のリフレッシュモードしか対応しておらず、差分レコード連携は未対応となっておりました。

Syniti 9.6では差分レコード連携が追加されたため、最新の更新データをHadoopへ取り込み、
分析に繋げることができるようになりました。

●SynitiへのHadoop HDFS登録

まず、ターゲット接続にHadoop HDFSを追加します。

Hadoop HDFSのIPアドレスやユーザ名とパスワード、どのHDFSフォルダへレプリケーションを行いたいのか、またHadoopコマンドを実行する実行ファイルパスを指定します。

テストを実行すると、接続が正しく行われていることが確認できます。

●レプリケーションの実行

レプリケーションジョブ作成にも、特別必要な操作はなく、RDBMSのレプリケーションジョブと同じように作成可能です。
実際にレプリケーションジョブを実行すると、以下のHDFS Webコンソールからもデータが確認できます。

.refとついたファイルが初期リフレッシュで作成された全件レコードが格納されたものであり、.mirが差分レコード連携で生成されたファイルです。

このように、Synitiを使用することで、Hadoop HDFSへのリアルタイムデータ連携が可能になります。

タグ: , ,

ACID原理とCAP定理 ~ NewSQLへの道 ~

データベースはそもそも、なぜ作られたのでしょうか?

システム設計上の概念から言えば、変数に入るさまざまな値をプログラムから切り離して、別の場所に保管したほうが便利だったから、なのでしょう。そんな初期のデータベースは、大勢の人が一斉にアクセスするわけでもなく、パフォーマンスや可用性は二の次で、正確性と整合性が何よりも重要でした。

おそらく、パフォーマンスにこだわり出したのは、インターネットが普及してからで、可用性にこだわり出したのはクラウドが普及してからではないでしょうか。

パフォーマンスや可用性が今ほど重要でなかった時代は、データがどんどん増えて容量が足りなくなれば、「縦方向に拡張する」のみでした(Scale UP vs. Scale Outの記事参照)。クーラーの利いたサーバー室にデータベース専用ホストがあって、バックアップのスクリプトを夜中に自動実行されるように設定して、「週7日24時間稼働!」なんてプレッシャーもなく、古き良きのんびりした時代でした…(遠い目でつぶやく)。

インターネット時代は、オンライン トランザクション処理(OLTP)をサポートすることが最重要課題になりました。いつどこで誰がデータを更新するかわからないし、AさんとBさんが同時にアクセスするかもしれません。トランザクションは一度始めたら、誰にも邪魔されずに完結してもらわなければならないし、もし途中で失敗したらロールバックして、元の状態に戻さなければなりません。何事も中途半端はいけません。できないことはできないとはっきり言うのが、データベースでも人間関係でも「整合性」を保ついちばんの秘訣です。

少し話が逸れましたが、つまりACIDがデータベース設計の基本原理です。ACIDとは、「Scale UP vs. Scale Out」の記事でも触れたとおり、A(atomicity=原子性/不可分性)C(consistency=一貫性/整合性)I(isolation=独立性/隔離性)D(durability=耐久性/永続性)のことです。

クラウドが普及すると、パフォーマンスと可用性が重視されるのはもちろんのこと、データの量も桁違いに増加して、ビッグデータ時代に入りました。データの急増には縦方向の拡張(Scale Up)では対応しきれず、横方向の拡張(Scale Out)が必要になります。

横方向の拡張とは、すなわちシステムの分散のことで、そこではCAP定理が考慮されなければなりません。CAP定理とは、

『ノード間のデータ複製に関しては、Consistency(一貫性)、Availability (可用性)、Partition-tolerance (分断耐性)の3つの保証を提供することは不可能である』

とブリュワーさんが言い出したから、「ブリュワーの定理」とも呼ばれます。

仮に、データベースが2つのノードにまたがる場合、ノードAとノードBのデータを常に一致させるのがConsistency、ノードAがダウンしてもノードBがサービスを提供し続けるのがAvailability、ノードAとノードBが分断されてもサービスを提供するのがPartition-toleranceです。

ビッグデータの用途はOLTPではなく、OLAP(オンライン アナリティクス処理)が中心で、リレーショナル データベースのような整合性を重視する必要がなかったためにスケールアウトが実現したのであり、ブリュワーさんが言うところの「Consistency」を犠牲にしています。リレーショナル データベース=SQLデータベースとすれば、スケールアウトの実現はNoSQLデータベースだからこそ達成されたAP (CAP定理のCを外した)システムです。

ちなみに、ブリュワーさんは、昔、日ハムにいた外人助っ人のブリューワさんとは別人です。カタカナは異なりますが、どちらもBrewerで、ビール醸造職人という意味です。だから、ブリュワーの定理(Brewer’s Theorem)は一見したらビールの作り方の法則みたいで、それだったら、もっと便利な気が…

また話が逸れましたが、要するに、スケールアウトされた分散型データベースはACID原理に準拠しておらず、OLTPはサポートできない、ということになります。

では、OLTPをサポートして、なおかつ分散するにはどうすればよいのでしょうか?

そこで考え出されたのがNewSQLデータベースで、リレーショナル データベースを水平パーティションで分割(sharding)して、レプリケーションと二次インデックスで複数ノードに分散するしくみです。クラウド時代がクラウド ネイティブ時代に進化して、何でもコンテナに箱詰めしなきゃ気が済まない、いや、コンテナ化できる便利な時代になったので、OLTPサポートのリレーショナル  データベースも複数ノードに分散するのは自然な流れと言えます。

では一体、このNewSQLはどうやってCAP定理の壁を乗り越えたのでしょうか?少し話が長くなってしまったので、次回につづきます。

タグ: ,

Webセミナー録画 『多種DBからKafka、Hadoop、S3への対応 データ統合/分析基盤へ簡単連携!』2019/12/10 開催

異種間データベース連携ツール「DBMoto」の名前が「Syniti Data Replication」へ変更されました。

製品名変更だけでなく、データ分析の基盤となるHadoop HDFSやAmazon S3、Apache Kafkaを始め、多くのデータプラットフォームがサポートに追加され、リアルタイムにデータ連携が可能となります。

Syniti Data Replicationを使うことで、エージェントレスに、
各種分析したいデータをデータプラットフォームへ連携し、
ビジネスの次の一歩に繋げていくことが可能です。

本セミナーでは、これらのデータプラットフォーム対応を中心に、
Syniti Data Replicationを使用して簡単にデータ連携ができることをご紹介します。

『多種DBからKafka、Hadoop、S3への対応 データ統合/分析基盤へ簡単連携!』 from Climb, Inc.

タグ: , , , ,

Syniti Data Replication 新機能ブログ② Amazon S3へのレプリケーション対応

昨今、各企業で蓄積したデータを次のビジネスに活かすために、様々なBIツールや分析ツールが
オンプレミスでも、仮想環境でも、更にはクラウドでも多く提供されています。

特にこれまではWindowsやLinuxマシンにインストールし、動かしていたBIツールや分析ツールも、
ベンダー各社 サービスとして提供されるようになり、管理の容易さから見ても これから導入しようという企業も多いと思います。
その中で各種サービスでは、データソースとして多くのデータベースやファイル形式をサポートしておりますが、やはり今後主流となってくるのはAmazon S3などのクラウドストレージ上にデータを配置し、分析する手法になると想定されます。

このようなAmazon S3に対しても、Syniti Data Replicationであればコーディングすることなく、
すべてGUIベースでオンプレ/仮想/クラウドに展開されているデータベースからレコードを連携することができます。

それでは早速Syniti Data ReplicationでAmazon S3を登録する方法をご紹介します。

  • 事前準備
    Syniti Data Replication(旧DBMoto)をインストールしたWindowsマシンに、AWS Toolkit for .NETが必要となります。
    こちらのAWS公式サイトより、インストーラを取得してインストールします。
    デフォルトのインストールでは、以下のフォルダパスへ展開されます。
    C:\Program Files (x86)\AWS SDK for .NET\bin


    • Syniti Data Replicationへの登録
      まず、ターゲット接続追加ウィザードにて、 Amazon S3を選択します。
      次に、各種パラメータを追加していきます。

      入力が必要となる項目は、以下の6つとなります。
      Output Folder : レプリケーションで生成する一時ファイルをエクスポート先を指定します。
      S3 Access Key : AWSアカウントのアクセスキーを指定します。
      S3 Secret Key : AWSアカウントのシークレットキーを指定します。
      S3 Bucket Name : レプリケーション先のS3バケット名を指定します。
      AWS SDK S3 Assembly Path (AWSSDK.S3.dll) : AWSSDK.S3.dllのパスを指定します。
      AWS SDK Core Assembly Path (AWSSDK.Core.dll) : AWSSDK.Core.dllのパスを指定します。

      ここまで入力し、テストを実行することで、Amazon S3と正しく接続が行えていることが確認できます。

    • レプリケーションジョブ作成と実行
      Amazon S3へのレプリケーションジョブも、他のデータベースと同じようにGUIから作成することができます。
      レプリケーションが成功すると、ターゲットのAmazon S3バケット内にフラットファイルが確認できます。
      「.ref」という拡張子がついているファイルが初期リフレッシュで生成されたファイル、
      「.mir」という拡張子がついているファイルがミラーリングで生成された差分のデータとなります。
      フラットファイルの中身を確認すると、以下のようにレコードデータが確認できます。

このように、Syniti Data Replicationを使用することで、プログラム開発することなくGUIからの操作のみで、データベースに格納されているテーブルデータをAmazon S3へレプリケーションし、別アプリケーション(BIや分析ツール/サービス)から利用することが可能です。

タグ: , , ,

[Syniti(DBMoto)][スクリプト] 特定カラムの値が変更となった場合、ターゲットのレコードを削除するサンプルスクリプト

Syniti Data Replication (DBMoto)では、レプリケーションジョブにスクリプトを組み込むことによって、ある程度レコードに操作を加えて、ターゲットデータベースにレプリケーションができます。

例えば、以下のスクリプトを組み込むことで、ソーステーブルに削除フラグを格納するカラムが存在し、そのカラムに対して削除フラグがたった場合、ターゲットテーブルのレコードを削除することが可能です。

“DFLUG” というカラムに格納されている値が1とUpdateされた場合、ターゲットレコードを削除するためのサンプルスクリプトです。

Imports System
Imports System.Data
Imports Microsoft.VisualBasic
Imports DBMotoPublic
Imports DBMotoScript
Imports DBRS.GlobalScript

Namespace DBRS
    Public Class ReplicationScript : Inherits IReplicationScript
		Public Overrides Sub Record_onAfterMapping( recSource As DBMotoPublic.IRecord,  recTarget As DBMotoPublic.IRecord, ByRef AbortRecord As Boolean, ByRef DisableReplication As Boolean)
	' ソーステーブルカラム名の変数
        Dim strField As String
        ' ソース側へUpdateクエリが実行された時
        If (recSource.OperationType = enmOperationType.Update) Then
        ' "DFLUG"というカラム名を指定し、値を取得
        strField = CType(recSource.GetValueAfter("DFLUG").ToString(), Integer)
        End If
        ' "DFLUG"の値が"1"だった場合、ターゲットのレコードにDeleteクエリを発行
        If (strField = "1") Then
            recTarget.OperationType = enmOperationType.Delete
        End If
		End Sub

    End Class
End Namespace

コメントする -->