Wondering if someone could help me with this.
I am getting some errors in Domain Manager & Domain Manager Backup log files as below:
[16/11/23 00:28:19] ID=DIRECTORY SERVICE (info) Replication connection TCP://hostname:22516 (re)established
[16/11/23 00:28:19] ID=DIRECTORY SERVICE (warning) Replication connection TCP://hostmane:22516 lost: No space in multi-connection accept queue
[16/11/23 00:28:22] ID=DIRECTORY SERVICE (info) Replication connection TCP://hostmane:2600 (re)established
[16/11/23 00:28:22] ID=DIRECTORY SERVICE (warning) Replication connection TCP://hostname:2600 lost: No space in multi-connection accept queue
[16/11/23 00:28:23] ID=DIRECTORY SERVICE (info) Replication connection TCP://hostname:22516 (re)established
[16/11/23 00:28:23] ID=DIRECTORY SERVICE (warning) Replication connection TCP://hostmane:22516 lost: No space in multi-connection accept queue
The errors are continuously appearing. How could I resolve these. I cannot find any documentation around this.
Related
all. We manage an EC2 instance (windows) that hosts our on-premises Power BI Gateway. The last few days, we have noticed that we're unable to rdp into the instance. When we check Fleet Manager, we see that "SSM Agent Ping Status" is at Connection Lost:
After an instance reboot, the issue resolves itself. This has happened daily for three days now. I have verified that the ssm agent version is not dated. The current version installed on instance is 3.1.1575, which per the releases doc (below) was released on June 6, 2022 (seems fairly recent). There is one version more recent released 7-14-2022:
https://github.com/aws/amazon-ssm-agent/releases
I looked into the "Connection Lost" status and saw the following:
If an instance fails a health check, AWS OpsWorks Stacks autoheals registered Amazon EC2 instances and changes the status of registered on-premises instances to connection lost. There's some confusion here, I don't recall registering the instance under AWS OpsWorks Stacks -- unless, this is automatic.
Is there anyway to troubleshoot and get to the bottom of this? We can temporarily reboot instance, but I'd like to understand what's causing the issue... Thank you!
Note: self-answered question, because Google didn't shed any light on the problem.
I have configured a Managed Streaming for Kafka target for AWS Data Migration Service, but the migration job fails. Looking at the logs, I see this:
2021-11-17T18:45:21 kafka_send_record (kafka_records.c:88)
2021-11-17T18:50:21 Message delivery failed with Error:[Local: Message timed out] [1026800] (kafka_records.c:16)
I have verified the following:
Both DMS replication instance and MSK cluster use the same security group, with a "self ingress" rule that allows all traffic, and an egress rule that allows all traffic.
The endpoint connection test succeeds.
I can send a message to the MSK topic using the Kafka console producer from an EC2 instance in the same VPC (and receive this message with the console consumer).
The DMS job succeeds if I change the endpoint to use a self-managed Kafka cluster, running on an EC2 instance in the same VPC.
It turned out that the problem was that I pre-created the topic, with a replication factor of 1, but the default MSK configuration specifies min.insync.replicas of 2, which is applied to all created topics.
When DMS sends a message, it requires acks from all in-sync replicas (I'm inferring this, as it's not open-source). This will never succeed if the minimum number of in-sync replicas exceeds the number of actual replicas.
The Kafka console producer, however, defaults to a single ack. This means that it's not a great verification for MSK cluster usability.
Semi-related: the MSK default default.replication.factor value is 3, which means that you over-replicate for a 2-node MSK cluster.
Using the promotionals credits (the 300$ opening account promotion), i used to connect my VM using SSH gcloud compute ssh instance_name all was fine.
End of promotional credits, i linked the project to my billing account. Then now, running the same SSH connection return this error
ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4033: 'not authorized'].
kex_exchange_identification: Connection closed by remote host
Connection closed by UNKNOWN port 65535
ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
I don t get it... the VPC is fine, the firewall got all ports open.
Do i really have to set an iap tunnel ? Why the normal SSH connection is not working anymore ?
Thanks if someone can confirm (before i change what was working well).
Accordingly to your comment the Free Trial was ended, I assume that your issue is related to the deletion process started when the Free Trial ends. Please have a look at the documentation End of the Free Trial to find more details:
The Free Trial ends when you use all of your credit, or after 90 days,
whichever happens first. At that time, the following conditions apply:
To continue using Google Cloud, you must upgrade to a paid Cloud Billing account.
All resources you created during the trial are stopped.
Any data you stored in Compute Engine is marked for deletion and might be lost. - Learn more about data deletion on Google Cloud.
Your Cloud Billing account enters a 30-day grace period, during which you can recover resources and data you stored in any Google
Cloud services during the trial period.
You might receive a message stating that your Cloud Billing account has been canceled, which indicates that your account has been
suspended to prevent charges.
I received aws billing email notification that "exceeded 85% of the usage limit for one or more AWS Free Tier-eligible services". When I check EC2 instance are running zero?
Can someone explain where to check running instances and if there is no any running instances why I received email?
As I understand it, I can use a Multi-AZ RDS deployment for HA and add Read Replicas to improve my read capacity and performance. In able to leverage Read Replicas I will need to maintain a separate connection pool with-in my Application strictly for read operations. However, from what I've read it appears that Read Replication is broken when a Multi-AZ RDS fails over to the standby instance. If this is true:
How do manage the Read Connection Pool in my Application? ie) will the dns addresses of the read replicas change and therefor require application code changes to update the Connection Pool?
Should I have read replicas already created for the standby instance or can I re-associate the existing read replicas with the standby?
Will the Read Replicas continue to function during failure and effectively serve my Application stale data until I update the connection pool?