データベースのデプロイ時間はどのくらい必要でしょうか？サービスに影響を与える可能性はありますか？
TDSQL-C for MySQLの設定変更はコンピュート仕様の調整とストレージ容量の調整に分かれます。
コンピューティング仕様の設定変更
プロビジョニング済みリソースのインスタンス形態では、コンピューティング仕様の設定変更が秒単位で処理されます。コンピューティング仕様を切り替える際、3秒～5秒の瞬断が発生する可能性があります。業務に再接続メカニズムが備わっていることをご確認いただき、この操作は業務負荷の低い時間帯に実行されることをお勧めします。
Serverlessインスタンス形態では、コンピューティング能力の上限・下限が自動調整され、瞬断が発生せず、既存の業務に影響を及ぼしません。
ストレージスペースの設定変更
ストレージスペースの設定変更において、従量課金モードでは手動でストレージスペースサイズを調整する必要はありません。システムは実際の毎時間の使用量に基づいて集計します。年/月単位サブスクリプション課金モードでは、ストレージプリペイド仕様の変更は使用済みストレージ容量より大きい必要があります。ストレージ課金モードの変更は既存の業務に影響しません。
読み取り専用インスタンスの追加には一定の時間がかかります。また、業務に影響を及ぼす可能性があります。
読み取り専用インスタンスを1つ追加するごとに30秒未満で完了し、業務に影響はありません。追加時間はインスタンスのストレージスペースが増大しても延長されません。読み取り専用インスタンスの追加方法についての詳細は、読み取り専用インスタンスの作成 を参照してください。 読み書きインスタンスと読み取り専用インスタンスの間でレプリケーション遅延が発生するかどうか。
従来のクラウドデータベースには秒単位の遅延が存在しますが、TDSQL-C for MySQLはRedoログ複製方式を採用しているため、遅延はミリ秒レベルとなり、従来のクラウドデータベースの遅延時間を大幅に短縮します。
レプリケーション遅延が増大する要因となる状況
TDSQL-C for MySQLのレプリケーション遅延は従来のデータベースよりもはるかに小さく、また遅延はインスタンス監視項目－スタンバイインスタンスのRedoレプリケーション遅延を観察することで実際のレプリケーション遅延の状況を把握できます。
以下の状況が発生した場合、レプリケーション遅延の増大を引き起こす可能性があります：
読み書きインスタンスの書き込み負荷が高いため、過剰なRedoログが生成され、読み取り専用インスタンスの適用が間に合わない状況を引き起こします。
読み取り専用インスタンスの負荷が高すぎるため、アプリケーションのRedoログに本来割り当てられるべきリソースを過剰に奪う結果となります。
I/Oにボトルネックが発生し、Redoログの読み書きが遅延しています。
フェイルオーバーの実施方法
TDSQL-C for MySQLは高可用性クラスタアーキテクチャを採用しており、システムは障害ノードを自動検出します。障害発生時には新しい計算ノードを自動起動し、障害ノードの代わりとして読み書きアクセスを提供します。
単一ノード障害の場合、RPO 0を保証できますか。
可能です。TDSQL-C for MySQLは三重レプリケーション方式【ホットデータは高速ストレージ（NVM+SSDレプリカ）、ウォームデータは低冗長ストレージ（SSD EC）、コールドデータは低速デバイス（HDD）に保存】によるストレージのインテリジェント階層化を採用し、障害復旧後のデータ損失を防止します。
オンラインでフィールドとインデックスを追加する方法。
MySQLネイティブのonline DDL、オープンソースツールpt-oscおよびgh-ostをサポートします。また、TDSQL-C for MySQLは特定のシナリオにおいてインスタントDDL操作もサポートします。詳細はインスタントDDL機能の紹介をご参照ください。 データの書き込みのみの場合、bulk insertをサポートしていますか？一回のinsertで最大いくつのvaluesをサポートしていますか？
可能です。一度にサポートされるvaluesの最大数はmax_allowed_packetパラメータ値によって決定されます。コンソールでmax_allowed_packetパラメータを変更して指定できます。このパラメータの変更範囲は1024-1073741824バイトであり、かつ1024の倍数である必要があります。詳細な操作についてはインスタンスパラメータの設定を参照してください。 WeDataで作成した同期タスクにおいて、計算ノードの切り替えによりローカルのビンログ取得が中断された場合、どう対処すればよいですか。
WeDataで作成した同期タスクにおいて、計算ノードの切り替えによりローカルのビンログ取得が中断した場合、cdc_flink_userを設定することで解決できます。
説明：
cdc_flink_user は、ユーザーが flink を通じて cdc から binlog をサブスクライブする際のユーザー名を指します。複数のユーザーが存在する場合は、#をセパレータとして使用します。