데이터를 대상으로 스트리밍할 수 있도록 소스 MySQL 데이터베이스를 설정하는 방법의 개요
동작
이 섹션에서는 Datastream을 사용하여 데이터를 복제할 때 MySQL 소스의 동작을 설명합니다. MySQL 데이터베이스에서 데이터를 수집할 때 binlog 기반 복제 또는 전역 트랜잭션 식별자 (GTID) 기반 복제를 사용할 수 있습니다. 스트림을 만들 때 CDC 메서드를 선택합니다.
바이너리 로그 기반 복제
Datastream은 바이너리 로그 파일을 사용하여 MySQL 데이터베이스의 데이터 변경사항을 기록할 수 있습니다. 이러한 로그 파일에 포함된 정보는 소스에서 이루어진 변경사항을 재현하기 위해 대상에 복제됩니다.
Datastream의 binlog 기반 복제의 주요 특징은 다음과 같습니다.
제공된 MySQL 소스의 모든 데이터베이스나 특정 데이터베이스는 물론 데이터베이스의 모든 테이블 또는 특정 테이블을 선택할 수 있습니다.
모든 이전 데이터가 복제됩니다.
지정된 데이터베이스 및 테이블의 삽입, 업데이트, 삭제와 같은 모든 데이터 조작 언어 (DML) 변경사항이 복제됩니다.
커밋된 변경사항만 복제됩니다.
전역 트랜잭션 식별자 (GTID) 기반 복제
Datastream은 전역 식별자 (GTID) 기반 복제도 지원합니다.
전역 트랜잭션 식별자 (GTID)는 MySQL 소스에서 커밋된 각 트랜잭션과 연결되어 생성되는 고유 식별자입니다. 이 식별자는 데이터베이스 클러스터의 각 노드가 자체 번호가 매겨진 자체 binlog 파일을 유지하는 바이너리 로그 기반 복제와 달리, 시작된 소스뿐만 아니라 지정된 복제 토폴로지의 모든 서버에서도 고유합니다. 실패 또는 계획된 다운타임이 발생하면 바이너리 로그 연속성이 깨지고 바이너리 로그 기반 복제가 실패하므로 별도의 바이너리 로그 파일을 유지하고 번호를 매기는 것이 문제가 될 수 있습니다.
GTID 기반 복제는 장애 조치, 자체 관리형 데이터베이스 클러스터를 지원하며 데이터베이스 클러스터의 변경사항과 관계없이 계속 작동합니다.
Datastream의 GTID 기반 복제의 주요 특징은 다음과 같습니다.
제공된 MySQL 소스의 모든 데이터베이스나 특정 데이터베이스는 물론 데이터베이스의 모든 테이블 또는 특정 테이블을 선택할 수 있습니다.
모든 이전 데이터가 복제됩니다.
지정된 데이터베이스 및 테이블의 삽입, 업데이트, 삭제와 같은 모든 데이터 조작 언어 (DML) 변경사항이 복제됩니다.
커밋된 변경사항만 복제됩니다.
장애 조치를 원활하게 지원합니다.
바이너리 로그 기반 복제에서 GTID 기반 복제로 전환
스트림을 업데이트하고 백필을 수행하지 않고 binlog 기반 복제에서 GTID 기반 복제로 전환하려면 다음 단계를 실행하세요.
Datastream은 이벤트가 처리될 때 소스에서 최신 스키마를 주기적으로 가져옵니다. 스키마가 변경되면 Datastream이 스키마 변경사항을 감지하고 스키마 가져오기를 트리거합니다. 그러나 일부 이벤트가 잘못 처리되거나 스키마 가져오기 사이에 삭제되어 데이터가 불일치할 수 있습니다.
소스 스키마에 대한 모든 변경사항이 올바르게 검색되지 않아서 데이터 손상이 발생할 수 있습니다. 다음 스키마 변경으로 인해 데이터가 손상되거나 이벤트 다운스트림을 처리하지 못할 수 있습니다.
열 삭제
테이블 중간에 열 추가
열의 데이터 유형 변경
열 재정렬
테이블 삭제(새 데이터를 추가한 후 같은 테이블을 다시 만드는 경우에 해당)
테이블 자르기
DataStream은 뷰 복제를 지원하지 않습니다.
Datastream은 공간 데이터 유형의 열을 지원하지 않습니다. 이러한 열의 값은 NULL 값으로 바뀝니다.
Datastream은 DATETIME, DATE, TIMESTAMP 데이터 유형의 열에서 0 값(0000-00-00 00:00:00)을 지원하지 않습니다. 0 값은 NULL 값으로 바뀝니다.
DataStream은 JSON 열에 DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP, TIMESTAMP2 값을 포함하는 행의 복제를 지원하지 않습니다. 이러한 값을 포함하는 이벤트는 삭제됩니다.
Datastream은 소스 MySQL 연결 프로필에서 SSL 인증서 체인을 지원하지 않습니다. 단일 x509 PEM 인코딩 인증서만 지원됩니다.
Datastream은 연쇄 삭제를 지원하지 않습니다. 이러한 이벤트는 바이너리 로그에 기록되지 않으며, 따라서 대상에 전파되지 않습니다.
Datastream은 DROP PARTITION 작업을 지원하지 않습니다. 이러한 작업은 메타데이터 전용 작업이며 복제되지 않습니다. 다른 이벤트는 영향을 받지 않으며 스트림이 정상적으로 실행됩니다.
Datastream은 바이너리 로그 기반 복제를 사용할 때 복제본으로의 장애 조치를 지원하지 않으므로 MySQL용 Cloud SQL Enterprise Plus 소스에는 GTID 기반 복제를 사용하는 것이 좋습니다. Cloud SQL Enterprise Plus 인스턴스는 다운타임이 0에 가까운 유지보수가 적용되며 유지보수 중에 복제본으로 장애 조치됩니다.
GTID 기반 복제의 추가 제한사항
GTID 기반 복제를 사용하는 스트림 복구는 Datastream API를 사용하는 경우에만 가능합니다.
CREATE TABLE ... SELECT 문을 사용하여 다른 테이블에서 테이블을 만드는 작업은 지원되지 않습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eDatastream replicates data from MySQL sources using either binlog-based or GTID-based replication, supporting historical data and DML changes for selected databases and tables.\u003c/p\u003e\n"],["\u003cp\u003eSupported MySQL versions include 5.6, 5.7, 8.0, and 8.4 (GTID-based only), with compatibility for self-hosted, Cloud SQL, Amazon RDS, Amazon Aurora, MariaDB, Alibaba Cloud PolarDB, and Percona Server.\u003c/p\u003e\n"],["\u003cp\u003eLimitations exist, including a 10,000-table limit, restrictions on tables with invisible primary keys or more than 500 million rows, and potential data discrepancies from schema changes.\u003c/p\u003e\n"],["\u003cp\u003eSpecific data types like spatial data and zero values in \u003ccode\u003eDATETIME\u003c/code\u003e, \u003ccode\u003eDATE\u003c/code\u003e, or \u003ccode\u003eTIMESTAMP\u003c/code\u003e columns, and certain JSON values are not supported, and are thus replaced with null or discarded.\u003c/p\u003e\n"],["\u003cp\u003eGTID-based replication, currently in preview, offers failover support, but has additional limitations like only being recoverable through the Datastream API and not supporting \u003ccode\u003eCREATE TABLE ... SELECT\u003c/code\u003e statements.\u003c/p\u003e\n"]]],[],null,["# Source MySQL database\n\nThis section contains information about:\n\n- The behavior of how Datastream handles data that's being pulled from a source MySQL database\n- The versions of MySQL database that Datastream supports\n- Known limitations for using MySQL database as a source\n- An overview of how to setup a source MySQL database so that data can be streamed from it to a destination\n\nBehavior\n--------\n\nThis section describes the behavior of MySQL sources when you replicate data\nusing Datastream. When you ingest data from MySQL databases, you can\nuse binlog-based replication or global transaction identifier (GTID)-based\nreplication. You select your CDC method when you\n[create a stream](/datastream/docs/create-a-stream).\n\n### Binlog-based replication\n\nDatastream can use\n[binary log](https://dev.mysql.com/doc/refman/5.6/en/binary-log.html) files to\nkeep a record of data changes in MySQL databases. The information contained in\nthese log files is then replicated to the destination to reproduce the changes\nmade on the source.\n\nThe key characteristics of binlog-based replication in Datastream are:\n\n- All databases or specific databases from a given MySQL source, as well as all tables from the databases or specific tables, can be selected.\n- All historical data is replicated.\n- All data manipulation language (DML) changes, such as inserts, updates, and deletes from the specified databases and tables, are replicated.\n- Only committed changes are replicated.\n\n### Global transaction identifier (GTID)-based replication\n\nDatastream also supports global identifier (GTID)-based replication.\n\nGlobal transaction identifier (GTID) is a unique identifier created and\nassociated with each transaction committed on a MySQL source. This identifier is\nunique not only to the source on which it originated, but also across all servers\nin a given replication topology, as opposed to the binary log-based\nreplication where each node in the database cluster maintains its own binlog\nfiles, with its own numbering. Maintaining separate binlog files and numbering\nmight become an issue in the event of a failure or planned downtime, because the\nbinlog continuity is broken and the binlog-based replication fails.\n\nGTID-based replication supports failovers, self-managed database clusters, and\ncontinues to work irrespective of changes in the database cluster.\n\nThe key characteristics of GTID-based replication in Datastream are:\n\n- All databases or specific databases from a given MySQL source, as well as all tables from the databases or specific tables, can be selected.\n- All historical data is replicated.\n- All data manipulation language (DML) changes, such as inserts, updates, and deletes from the specified databases and tables, are replicated.\n- Only committed changes are replicated.\n- Seamless support for failovers.\n\n### Switch from binlog-based to GTID-based replication\n\nIf you want to update your stream and switch from binlog-based to GTID-based\nreplication without the need to do a backfill, perform the following steps:\n| **Note:** These steps require database downtime. Similar steps might also be useful when you want to upgrade the major version of your MySQL source.\n\n1. Ensure that all requirements for GTID-based replication are satisfied. For more information, see [Configure a source MySQL database](/datastream/docs/configure-your-source-mysql-database).\n2. Optionally, create and run a *test* GTID-based stream. For more information, see [Create a stream](/datastream/docs/create-a-stream#expandable-2).\n3. Create a GTID-based stream. Don't start it yet.\n4. Stop application traffic to the source database.\n5. Pause the existing binlog-based stream. For more information, see [Pause the stream](/datastream/docs/run-a-stream#pauseastream).\n6. Wait for a few minutes to ensure that Datastream has caught up with the database. You can check this using the metrics in the **Monitoring** tab, on the **Stream details** page for your stream. The values for *Data freshness* and *Throughput* need to be `0`.\n7. Start the GTID-based stream. For more information, see [Start the stream](/datastream/docs/run-a-stream#startstream).\n8. Resume traffic to the source database.\n\nIf performing a backfill isn't an issue, you can truncate your tables in\nBigQuery, delete the old stream, and start a new one with backfill. For\nmore information about managing backfill, see\n[Manage backfill for the objects of a stream](/datastream/docs/manage-backfill-for-the-objects-of-a-stream).\n\nVersions\n--------\n\nDatastream supports the following versions of MySQL database:\n\n- MySQL 5.6\n- MySQL 5.7\n- MySQL 8.0\n- MySQL 8.4 (supported only for GTID-based replication)\n\n | Global transaction identifier (GTID)-based replication is only supported for versions 5.7 and later.\n\nDatastream supports the following types of MySQL database:\n\n- [Self-hosted MySQL](/datastream/docs/configure-self-managed-mysql)\n- [Cloud SQL for MySQL](/datastream/docs/configure-cloudsql-mysql) Cloud SQL for MySQL Enterprise Plus sources are supported when using the GTID-based replication.\n- [Amazon RDS for MySQL](/datastream/docs/configure-amazon-rds-mysql)\n- [Amazon Aurora MySQL](/datastream/docs/configure-amazon-aurora-mysql)\n- [MariaDB](/datastream/docs/configure-self-managed-mysql)\n- [Alibaba Cloud PolarDB](/datastream/docs/configure-self-managed-mysql)\n- [Percona Server for MySQL](/datastream/docs/configure-self-managed-mysql)\n\nKnown limitations\n-----------------\n\nKnown limitations for using MySQL database as a source include:\n\n- Streams are limited to 10,000 tables.\n- Tables that have a primary key defined as `INVISIBLE` can't be backfilled.\n- A table that has more than 500 million rows can't be backfilled unless the following conditions are met:\n 1. The table has a unique index.\n 2. None of the columns of the index are nullable.\n 3. The index isn't [descending](https://dev.mysql.com/doc/refman/8.0/en/descending-indexes.html).\n 4. All columns of the index are included in the stream.\n- Datastream periodically fetches the latest schema from the source as events are processed. If a schema changes, Datastream detects the schema change and triggers a schema fetch. However, some events might get processed incorrectly or get dropped between the schema fetches, which can cause data discrepancies.\n- Not all changes to the source schema can be detected automatically, in which case data corruption may occur. The following schema changes may cause data corruption or failure to process the events downstream:\n - Dropping columns\n - Adding columns to the middle of a table\n - Changing the data type of a column\n - Reordering columns\n - Dropping tables (relevant if the same table is then recreated with new data added)\n - Truncating tables\n- Datastream doesn't support replicating views.\n- Datastream doesn't support columns of [spatial data types](https://dev.mysql.com/doc/refman/8.0/en/spatial-type-overview.html). The values in these columns are replaced with `NULL` values.\n- Datastream doesn't support the zero value (`0000-00-00 00:00:00`) in columns of the `DATETIME`, `DATE`, or `TIMESTAMP` data types. The zero value is replaced with the `NULL` value.\n- Datastream doesn't support replicating rows which include the following values in `JSON` columns: `DECIMAL`, `NEWDECIMAL`, `TIME`, `TIME2` `DATETIME`, `DATETIME2`, `DATE`, `TIMESTAMP` or `TIMESTAMP2`. Events containing such values are discarded.\n- Datastream doesn't support [binary log transaction compression](https://dev.mysql.com/doc/refman/8.0/en/binary-log-transaction-compression.html).\n- Datastream doesn't support SSL certificate chains in the source MySQL connection profiles. Only single, x509 PEM-encoded certificates are supported.\n- Datastream doesn't support cascading deletes. Such events aren't written to the binary log, and as a result, aren't propagated to the destination.\n- Datastream doesn't support `DROP PARTITION` operations. Such operations are metadata only operations and aren't replicated. Other events aren't affected and the stream runs successfully.\n- Because Datastream doesn't support failovers to replicas when using the binary log-based replication, we recommend using GTID-based replication for Cloud SQL for MySQL Enterprise Plus sources. Cloud SQL Enterprise Plus instances are subject to [near-zero downtime maintenance](/sql/docs/mysql/maintenance#nearzero) and fail over to a replica during maintenance.\n\nAdditional limitations for the GTID-based replication\n-----------------------------------------------------\n\n- Recovering streams that use GTID-based replication is only available when using the Datastream API.\n- Creating tables from other tables using the `CREATE TABLE ... SELECT` statements isn't supported.\n- Datastream doesn't support tagged GTIDs.\n- For MySQL restrictions that apply to GTID-based replication, see [MySQL documentation](https://dev.mysql.com/doc/mysql-replication-excerpt/5.7/en/replication-gtids-restrictions.html).\n\nWhat's next\n-----------\n\n- Learn how to [configure a MySQL source](/datastream/docs/configure-your-source-mysql-database) for use with Datastream."]]
