연결하다 Google Cloud SQL 엑셀, 구글 시트, AI 및 REST로

사설 IP를 사용하는 것이 권장되는 방법이며, 가장 쉬운 방법이기도 합니다.

일반적으로 클라우드 SQL 연결은 이러한 데이터를 어디든 가져오는 데 있어 가장 어려운 부분입니다. 하지만 데이터를 읽는 주체가 이미 VPC 내부에 있다면 더 이상 어려운 문제가 아닙니다.

• 에이전트는 아웃바운드 연결만 수행하므로 VPC의 VM에 에이전트를 배치할 경우 인바운드 규칙이 필요하지 않습니다.
• 해당 인스턴스는 공용 IP 주소를 보유하지 않으며, 승인된 네트워크 목록은 비어 있습니다. — 사무실 주소가 변경되어도 업데이트할 사항이 없습니다.
• 호스트 이름이 없기 때문에 Cloud SQL은 IP 주소로 접근합니다. 이는 서비스의 특성이지 여기서의 제약 사항은 아닙니다.
• 기존에 공용 IP를 사용하고 있다면 여전히 작동합니다. 에이전트는 해당 IP가 어느 쪽에 있는지 상관하지 않습니다.

인증 프록시가 이해되었습니다.

많은 팀이 IP 주소를 직접 사용하는 대신 클라우드 SQL 인증 프록시를 통해 클라우드 SQL에 액세스하며, 카드는 이러한 방식을 감지합니다.

• 127.0.0.1 또는 localhost를 입력하면 프록시로 인식되며, 카드에는 해당 기능이 지원되는지 여부를 궁금해할 필요 없이 바로 표시되므로 안심하고 사용할 수 있습니다.
• 프록시 서버가 터널 자체를 암호화하므로 해당 경로에 대해서는 SSL 옵션을 꺼야 합니다. — 카드는 SSL 오류로 인해 혼란스러워질 수 있는 시점에 이 사실을 알려줍니다.
• IP 직접 연결의 경우 SSL 옵션을 켜야 하며, 기본적으로 켜져 있습니다.
• 프록시는 사용자가 직접 실행하고 관리해야 하는 프로세스이며, 에이전트에는 프록시 관련 내용이 전혀 포함되어 있지 않습니다.

엔진 세 개, 그리고 잘못된 엔진을 선택하지 않도록 하는 안전장치

멀티 엔진 카드를 사용할 때 한 가지 특정 실수가 발생하기 쉽습니다. 선택한 엔진과 다른 엔진에 속하는 포트를 붙여넣는 경우입니다. 이러한 조합은 연결 시 아무런 유용한 메시지 없이 실패하므로 양식에서 바로 감지됩니다.

• PostgreSQL은 5432, MySQL은 3306, SQL Server는 1433 포트에서 실행 중입니다. — 선택하신 엔진에 맞게 미리 채워져 있습니다.
• PostgreSQL이 선택된 상태에서 3306번 포트를 입력하면 카드가 해당 포트가 MySQL에 속한다고 알려주고, 포트를 통과시키는 대신 엔진을 확인하라고 요청합니다.
• 비밀번호 앞뒤에 공백이 있는 경우에도 문제가 발생합니다. 이는 거의 항상 클립보드에서 가져온 내용이며, 불투명한 인증 오류로 간주되어 실패하기 때문입니다.
• 어떤 엔진을 선택하든, 연결 정보는 해당 엔진 이름으로 저장됩니다. — 클라우드 SQL은 연결 유형이 아닌 카드에 배지로 표시됩니다.

-- 인스턴스가 실행되는 엔진에 관계없이 동일한 읽기 결과: SELECT c.name, COUNT(o.id) AS orders, SUM(o.amount) AS revenue FROM customers AS c JOIN orders AS o ON o.customer_id = c.id GROUP BY c.name ORDER BY revenue DESC;